draft-ietf-nemo-requirements-00.txt

この文書はインターネットドラフトの日本語訳（和訳）です。翻訳者はこの文書の翻訳の正確さを保障しません。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。翻訳者はこの翻訳の配布に制限をしません。

NEMO Working Group Thierry Ernst, Editor
Internet-Draft INRIA and WIDE
February, 2003

"Network Mobility Support Requirements"
「ネットワーク移動性支持必要条件」
<draft-ietf-nemo-requirements-00.txt>

Status of This Memo
このメモの状態

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
この文書はインターネットドラフトであって、そしてＲＦＣ２０２６の１０
章のすべての条項に完全適合です。

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
インターネットドラフトはインターネット技術タスクフォース（ＩＥＴＦ）
とそのエリアとその作業グループの作業文書です。他のグループがインター
ネットドラフトとして同じく作業文書を配るかもしれないことに注意してく
ださい。

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
インターネットドラフトは最大６カ月間有効なドラフト文書で、いつでも他
の文書によって、更新か、置換えか、時代遅れにされるかもしれません。イ
ンターネットドラフトは、「進行中の仕事」として以外に、参照材料あるい
は引用として用いることは不適当です。

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
現在のインターネットドラフトのリストは
http://www.ietf.org/ietf/1id-abstracts.txt でアクセスできます。

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
インターネットドラフトの影ディレクトリのリストは
http://www.ietf.org/shadow.html でアクセスできます。

Abstract
概要

Network mobility arises when an entire network changes its point of
attachment to the Internet and thus its reachability in the topology.
The mobile network is viewed as a unit and is connected to the global
Internet by one or more mobile routers. In contrast with host
mobility support which aims at providing continuous Internet
connectivity to mobile hosts only, network mobility support is to
provide continuous Internet sessions not only to the mobile router
connecting the mobile network to the global Internet, but also to
nodes behind the mobile router. The purpose of this document is to
list the requirements that must be met by network mobility support
solutions in IPv6.
ネットワーク移動性は、ネットワークがインターネットとの接続点を変え、
トポロジーでの可到達性に変える時に、生じます。移動ネットワークは単位
と見なされ、そして１つ以上の移動ルータによってグローバルインターネッ
トと接続されます。移動ホストのみに常時インターネット接続性を供給する
ことを目指すホスト移動サポートと対照して、ネットワーク移動サポートが
グローバルインターネットに移動ネットワークを結ぶ移動ルータにだけでは
なく、移動ルータの後ろのノードに常時インターネットセッションを供給す
るはずです。この文書の目的はＩＰｖ６でネットワーク移動サポート解決に
よって満たされなくてはならない必要条件をリストアップすることです。

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 03

2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 04

3. Network Mobility Goals and Methodology . . . . . . . . . . . 04

4. General Purpose Guidelines for the Solutions . . . . . . . . 05

5. One-liner Requirements for Basic NEMO Support. . . . . . . . 09

A. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 11

B. References . . . . . . . . . . . . . . . . . . . . . . . . . 11

C. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 12

D. Full Copyright Statement . . . . . . . . . . . . . . . . . . 12

Conventions used in this document
この文書で使う協定

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[RFC2119]で記述されるように解釈されます。

1. Introduction
1. はじめに

Network mobility support is concerned with managing the mobility of
an entire network, viewed as a single unit, which changes its point
of attachment to the Internet and thus its reachability in the
Internet topology. Such kind of network is referred to as a mobile
network and includes one or more mobile routers (MRs) which connect
it to the global Internet. Nodes behind the MR(s) (MNNs) are both
fixed (keeping the same address on the mobile network at all times),
and mobile (entering and leaving the mobile network as they roam with
respect to it). In most cases, the internal structure of the mobile
network will in effect be relatively stable (no dynamic change of the
topology), but this is not a general assumption.
ネットワーク移動性サポートは１つの単位とみなされたネットワークの移動
の管理、インターネットの接続点の変更とそれによるインターネットトポロ
ジーでの到達性の変化に関わります。このような種類のネットワークが移動
ネットワークでと述べられ、そして１つ以上の移動ルータ（MR)を含み、移動
ルータでグローバルインターネットと接続します。ＭＲの背後にあるノード
は固定（いつも移動ネットワーク上の同じアドレスを維持する）か移動（ロー
ミングするように移動ネットワークに入ったりでたりする）です。たいてい
の場合で、移動ネットワークの内部の構造体は実際比較的安定しているでしょ
う（トポロジーの動的変更がない）、しかしこれは一般的な仮定ではありま
せん。

Cases of mobile networks include for instance:
移動ネットワークが以下の例を含みます：

- networks attached to people (Personal Area Networks or PANs): a
cell-phone with one cellular interface and one Bluetooth interface
together with a Bluetooth-enabled PDA constitute a very simple
instance of a mobile network. The cell-phone is the mobile router
while the PDA is used for web browsing or runs a personal web
server.
- ネットワークが人々（個人的なエリアネットワークあるいはＰＡＮ）に
付随します：１つの携帯インタフェースを持っている携帯電話と１つのブ
ルートゥースインタフェースとブルートゥースが使用可能なＰＤＡで移動
ネットワークの非常に単純な例を形成します。ＰＤＡがウェブブラウザや
個人ウェブサーバとして動く間に、携帯電話は移動ルータです。

- networks of sensors and computers deployed in vehicles: vehicles
are more and more embedded with a number of processing units for
safety and ease of driving reasons, as advocated by ITS
(Intelligent Transportation Systems) applications.
- 車内に配置されたセンサーとコンピュータのネットワーク：ＩＴＳ（イ
ンテリジェント輸送システム）アプリケーションで提唱されるように、車
は安全性と運転の容易さのための多くの処理ユニットが埋め込まれていま
す。

- access networks deployed in public transportation (buses,
trains, taxis, aircrafts): they provide Internet access to IP
devices carried by passengers (laptop, camera, mobile phone: host
mobility within network mobility or PANs: network mobility within
network mobility, i.e. nested mobility).
- 公共輸送機関（バス、列車、タクシー、航空機）で展開されたアクセス
ネットワーク：それらは乗客によって運ばれたＩＰ装置（ラップトップや
カメラやネットワーク移動中の移動電話：ネットワーク移動の中のホスト
移動あるいはＰＡＮ：ネットワーク移動内のネットワーク移動、すなわち
入れ子の移動）にインターネット・アクセスを供給します。

- ad-hoc networks connected to the Internet via a MR: for instance
students in a train that both need to set up an ad-hoc network
among themselves and to get Internet connectivity through the MR
connecting the train to the Internet.
- ＭＲでインターネットに接続したアドホックネットワーク：例えば列車
内の学生で、彼ら自身の間でアドホックネットワークを設立し、そしてイ
ンターネットへ向かって列車と接続するＭＲを通してインターネット接続
性を得るために。

Traditional work conducted so far on mobility support was to provide
continuous Internet connectivity to mobile hosts only (host mobility
support). In contrast with host mobility support, network mobility
support is to provide continuous Internet sessions not only to the
mobile router connecting the mobile network to the global Internet,
but also to nodes behind the mobile router.
移動サポートのこれまで行われた伝統的な仕事はただ移動ホストに常時イン
ターネット接続を供給する事でした（ホスト移動サポート）。ホスト移動サ
ポートと対照して、ネットワーク移動サポートがグローバルインターネット
と移動ネットワークを結ぶ移動ルータにだけではなく、移動ルータの後ろの
ノードに常時インターネットセッションを供給します。

Mobility of networks does not cause MNNs to change their own physical
point of attachment, however they happen to change their topological
location with respect to the global Internet which results in lack of
Internet access and broken sessions if no supporting mechanisms are
deployed. In addition, communication between a MNN and an arbitrary
Correspondent Node (CN) may result in extremely suboptimal paths,
particularly when mobile networks are nested or when the CN is itself
mobile.
ネットワークの移動性はＭＮＮ自身の物理的な接続点を変えさせず、グロー
バルインターネットに関するトポロジカルな場所を変える事になり、もし補
助のメカニズムが実装されないなら、インターネットアクセスをなくしとセッ
ションを破壊します。加えて、ＭＮＮと任意の取引先ノード間の通信が、特
に移動ネットワークが入れ子になるとき、あるいはＣＮ自身が移動である時、
非常に最適でないパスをもたらすかもしれません。

The mechanisms required for handling such mobility issues are
currently lacking within the IETF standards. The NEMO working group
has therefore been set up to deal with those. The purpose of this
document is thus to detail the methodology that will be followed by
the NEMO working group and to list requirements for network mobility
support.
このような移動性問題を扱うのに必要なメカニズムはＩＥＴＦ標準の中で現
在欠けています。従ってＮＥＭＯ作業グループはそれらを扱うために準備さ
れました。この文書の目的はＮＥＭＯ作業グループが従う方法論の詳述と、
ネットワーク移動性サポートの必要条件をリストアップすることです。

This document is structured as follows: first, section 2 introduces
the terminology for network mobility. In section 3, we define the
goals and methodology of the working group and we emphasize the
stepwise approach the working group has decided to follow. A number
of guidelines are listed in section 4 and are used in section 5 to
edict the requirements for basic network mobility support.
この文書は次のように構造化されています：最初に、２章がネットワーク移
動性の用語を導入します。３章で、我々は作業グループの目標と方法論を定
義し、そして我々は作業グループが従うことに決めた段階的手段を強調しま
す。多くのガイドラインが４章でリストアップされて、そして基本的なネッ
トワーク移動性のサポートの要求条件の布告に使われます。

2. Terminology
2. 専門用語

Terms used in this document are taken from [MIPv6] and [MOBILITY-
TERMS]. Additional terms pertaining to network mobility specifically
are defined in [NEMO-TERMS].
この文書で使われた用語が[MIPv6]とから、そして[MOBILITY-TERMS]とられ
ます。追加の用語が特にネットワーク移動性に関して[NEMO-TERMS]で定義
されます。

[NOTE FROM THE EDITOR: parts from draft [NEMO-TERMS] will probably be
moved to [MOBILITY-TERMS] whereas the remaining terms would then be
pasted in this present document. THIS IS TO BE DISCUSSED]
［著者のメモ：ドラフト[NEMO-TERMS]からの部分が恐らく[MOBILITY-TERMS]
に動かされるでしょう、残りの用語がそれからこの文書に貼り付けられるで
しょう。これは論じられるはずです］

3. Network Mobility Goals and Methodology
3. ネットワーク移動目標と方法論

The primary goal of the NEMO work is to specify a solution which
allows mobile network nodes (MNNs) to remain connected to the
Internet and continuously reachable at all times while the mobile
network they are attached to changes its point of attachment.
Secondary goals of the work is to investigate the effects of network
mobility on various aspects of internet communication such as routing
protocol changes, implications of realtime traffic and fast
handovers, optimizations. These should all support the primary goal
of reachability for mobile network nodes. Security is an important
consideration too, and efforts should be made to use existing
solutions if they are appropriate. Although a well-designed solution
may include security inherent in other protocols, mobile networks
also introduce new challenges.
ＮＥＭＯの仕事の主要な目標は移動ネットワークノード（ＭＮＮ）が接続す
る移動ネットワークが接続点を変える時に、常にインターネットに連続的に
到達可能なままでいることを許す解決を指定することです。仕事の第２の目
標は、ネットワーク移動性の効果、経路プロトコル変更等のインターネット
通信の様々な局面、リアルタイムトラヒックやファーストハンドオーバー、
に対するを調査です。これらはすべて移動ネットワークノードの到達可能性
の主要な目標を支援するべきです。セキュリティは同じく重要な考慮です、
そしてもし適切であるなら既存の解決を使う努力がされるべきです。よく設
計された解決が他のプロトコルに固有のセキュリティを含むかもしれないけ
れども、移動ネットワークが同じく新しい挑戦を導入します。

For doing so, the NEMO working group has decided to take a stepwise
approach by standardizing a basic solution to preserve session
continuity (basic network mobility support), and at the same time
study the possible approaches and issues with providing more optimal
routing with potentially nested mobile networks (extended network
mobility support). However, the working group is not chartered to
actually standardize a solution to such route optimization at this
point in time.
そうすることに対して、ＮＥＭＯワーキンググループはセッション連続性を
維持する基本的な解決（基本的なネットワーク移動性サポート）を標準化す
ることによって段階的手段をとって、そして潜在的に入れ子の移動ネットワー
ク（拡張ネットワーク移動性サポート）でのより最適なルーティングに提供
することが同時に可能な方法と問題を研究することに決めました。しかしな
がら、作業グループは今現在実際にこのような経路最適化に対する解決を標
準化するために公認されません。

For basic NEMO support, the working group will assume that none of
the nodes behind the MR will be aware of the network's mobility, thus
the network's movement needs to be completely transparent to the
nodes inside the mobile network. This assumption will be made to
accommodate nodes inside the network that are not generally aware of
mobility.
基本的なＮＥＭＯサポートのために、作業グループはＭＲの背後のノードが
ネットワークの移動性に気付かないと想定し、そしてネットワークの動きは
移動ネットワークの中のノードに完全に透過である必要があります。この仮
定は一般にネットワークの中の移動に気付かないノードを受け入れるために
されるでしょう。

The efforts of the Mobile IP working group have resulted in the
Mobile IPv4 [7] and Mobile IPv6 [6] protocols, which have already
solved the issue of host mobility support. Since challenges to
enabling mobile networks are vastly reduced by this work, basic
network mobility support will adopt the methods for host mobility
support used in Mobile IP, and extend them in the simplest way
possible to achieve its goals. The basic support solution is for each
MR to have a Home Agent, and use bidirectional tunneling between the
MR and HA to preserve session continuity while the MR moves. The MR
will acquire a Care-of-address from its attachment point much like
what is done for mobile nodes (MN) using Mobile IP. This approach
allows nested mobile networks, since each MR will appear to its
attachment point as a single node.
モバイルＩＰ作業グループの取り組みはモバイルＩＰｖ４[7]とモバイルＩＰ
ｖ６[6]プロトコルをもたらし、そしてそれはすでにホスト移動性サポートの
問題を解きました。移動ネットワークを可能にすることへの挑戦が非常にこ
の仕事によって減らされるので、基本的なネットワーク移動性サポートはモ
バイルＩＰで使った移動性サポートの方法を採用し、そしてその目標を成し
遂げる可能な最も単純な方法でそれらを拡張するでしょう。基本的なサポー
ト解決はそれぞれのＭＲがホームエージェントを持ち、そしてＭＲが動く間
のセッション連続性を維持するためにＭＲとＨＡの間の双方向性のトンネル
を使う事です。ＭＲは移動ノードがモバイルＩＰでするのと同様にその接続
点から立ち寄りアドレスを得るでしょう。この方法は、それぞれのＭＲがそ
の接続点にひとつのノードとして現われるので、入れ子の移動ネットワーク
を許します。

4. General Purpose Guidelines for the Solutions
4. 解決のための汎用のガイドライン

This section lists a number of guidelines which are used to edict the
requirements that MUST or SHOULD be met by forthcoming network
mobility support solutions, for both basic NEMO support and extended
NEMO support.
この章は来たるべきネットワーク移動性解決で満たされなくてはならない
(MUST)、あるいはそうするべき(SHOULD)必要条件を支援する布告で、基本的
なＮＥＭＯ支持と拡張されたＮＥＭＯ支持両方で使われる多くのガイドライ
ンをリストアップします。

- Migration Transparency: a permanent connectivity to the Internet
MUST be provided to all MNNs while continuous sessions MUST be
maintained as the mobile router changes its point of attachment.
For doing so, MNNs will be reachable via their permanent IP
addresses.
- 移動透明度：移動ルータがその接続点を変える時にインターネットへの
永久の接続性が、すべてのＭＮＮにセッションが継続されたまま(MUST)、
供給されなくてはなりません(MUST)。そうすることにより、ＭＮＮは永久
のＩＰアドレスによって到達可能であるでしょう。

- Performance Transparency (Seamless Mobility): NEMO support
SHOULD provide limited signaling overhead and ideally SHOULD
minimize the impact of handover on applications, in terms of
packet loss or delay. Variable delays of transmission and losses
between MNNs and their respective CNs as the network is moving are
not considered lack of performance transparency.
- 性能透明度（スムーズな移動性）：ＮＥＭＯサポートが限定されたシグ
ナリングオーバーヘッドを供給するべきであり(SHOULD)、そして理想的に
は、アプリケーション上でハンドオーバーによるパケット損失や遅延の影
響を最小にするべきです(SHOULD)。ＭＮＮとそのＣＮ間での伝達と損失の
可変的な遅延はネットワークが動いているから性能透明度の欠如であると
思われません。

- Network Mobility Support Transparency: MNNs behind the MR(s)
don't change their own point of attachment as a result of the
mobile network's displacement in the Internet topology.
Consequently, NEMO support is better performed by the sole MR(s)
and specific support functions on any other nodes than the MR(s)
SHOULD be avoided.
- ネットワーク移動性サポート透明度：ＭＲの背後のＭＮＮはインターネッ
トトポロジーでの移動ネットワークの移転の結果としてそれら自身の接続
点を変えません。従って、ＮＥＭＯサポートがＭＲだけで実行され、ＭＲ
以外のノードの特殊な機能は避けられるべきです(SHOULD)。

- Operational Transparency: NEMO support MUST be implemented at
the IP layer level. It MUST be transparent to any upper layer so
that any upper layer protocol can run unchanged on top of an IP
layer extended with NEMO support.
- 操作上の透明度：ＮＥＭＯサポートがＩＰ層レベルで実行されなくては
なりません(MUST)。これはＮＥＭＯサポートで拡張されたＩＰレイヤの上
で上位レイヤプロトコルが変更なく実行できるように、上位レイヤに透明
に違いありません(MUST)。

- Arbitrary Configurations: The formation of a mobile network can
exist in various levels of complexity. In the simplest case, a
mobile network contains just a mobile router and a host. In the
most complicated case, a mobile network is multi-homed and is
itself a multi-level aggregation of mobile networks with
collectively thousands of mobile routers and hosts. While the list
of potential configurations of mobile networks cannot be limited,
at least the following configurations are desirable:
- 任意の設定：移動ネットワークの形成は複雑さの様々なレベルで存在す
ることができます。最も単純な場合、移動ネットワークが移動ルータとホ
ストだけを含んでいます。最も複雑な場合で、移動ネットワークがマルチ
ホームであり、そしてそれ自身が何段階もの移動ネットワークのの集合体
で何千という移動ルータとホストを含みます。移動ネットワークの可能性
がある形状のリストが限定されているはずがないが、少なくとも次の形状
が望ましいです：

o mobile networks of any size, ranging from a sole subnet with
a few IP devices to a collection of subnets with a large
number of IP devices,
o 少数のＩＰ装置を持っている唯一のサブネットから、多数のＩＰ装
置のサブネットの集合までに及ぶ、任意の大きさの移動ネットワー
ク。

o multi-homed mobile network (see definition in [NEMO-TERMS].
o マルチホーム移動ネットワーク（[NEMO-TERMS]の定義を参照）。

o foreign mobile nodes that attach to the mobile network.
o 移動ネットワークに接続する外の移動ノード。

o nodes that change their point of attachment within the mobile
network.
o 移動ネットワーク内で接続点を変えるノード。

o nested mobile networks (see definition in [NEMO-TERMS].
o 入れ子の移動ネットワーク（[NEMO-TERMS]の定義を参照）。

o mobile networks displaced within a domain boundary (local
mobility) or between domain boundaries (global mobility).
o ドメイン境界線内での移動（ローカル移動性）のあるいはドメイン
境界線を超えた移動（グローバル移動性）。

o distinct mobility frequencies.
o 別の移動周波数。

o distinct access medium.
o 別のアクセスメディア。

In order to keep complexity minimal, transit networks are excluded
from this list. A transit network is one in which data would be
forwarded between two endpoints outside of the network, so that
the network itself simply serves as a transitional conduit for
packet forwarding. A stub network (leaf network), on the other
hand, does not serve as a data forwarding path. Data on a stub
network is either sent by or addressed to a node located within
that network.
複雑さを最小にしておくために、中継ネットワークがこのリストから除外
されます。中継ネットワークは、このネットワーク外の２つの終端間のデー
タを転送するものです、それでネットワーク自身はパケット転送のための
過渡的な土管の役をします。末端ネットワーク（葉ネットワーク）が、他
方、データ転送パスの役をしません。末端ネットワーク上のデータがその
ネットワークの中に位置しているノードにから送られてるか、あるいはそ
れ宛です。

- Administration: the solution MUST not prevent mobile networks
and mobile nodes owned by administratively different entities to
attach to any part of the Internet topology for any other
considerations than administrative and security policies (both
global mobility and local-mobility are desirable).
- 管理：この解決策は管理上かセキュリティポリシー以外の理由で管理上
異なる者に所有される移動ネットワークと移動ノードがインターネットト
ポロジーの任意の場所に接続するのを妨げてはなりません(MUST)（グロー
バル移動性とローカルな移動性両方が望ましい）。

- Scalability: NEMO support signaling and processing MUST scale to
a potentially large number of mobile networks irrespective of
their configuration, mobility frequency, and number of CNs.
- 拡大縮小可能性：ＮＥＭＯサポート信号と処理が、設定や移動頻度やＣ
Ｎ数にかかわらず潜在的に大きい移動ネットワークに対応なくてはなりま
せん(MUST)。

- Backward Compatibility: NEMO support MUST be able to co-exist
and not interfere with existing IPv6 standards. The solution MUST
reuse standards defined in other IETF working groups and MAY only
extend them if deemed necessary. For instance, the following
mechanisms defined by other working groups MUST still function:
- 後方互換性：ＮＥＭＯサポートは既存のＩＰｖ６標準と共存し妨害しな
いことができなければなりません(MUST)。解決は他のＩＥＴＦ作業グルー
プで定義された標準を再利用しなくてはならならず(MUST)、そしてもし必
要とみなされるなら、それらを拡張するだけでもよいです。例えば、次の
他の作業グループによって定義された以下のメカニズムは機能しなくては
なりません(MUST)：

o Address allocation and configuration mechanism.
o アドレス配分と設定メカニズム。

o Host mobility support: the solution MUST not prevent mobile
nodes and correspondent nodes, either located within or
outside the mobile network, to keep operating protocols
defined by the Mobile IP working group.
o ホスト移動性サポート：解決策は、モバイルＩＰ作業グループが定
義する運用プロトコルを維持し、移動ネットワークの中や外に位置
している移動ノードや取引先ノードを妨げてはなりません(MUST)。

o Multicast support: the solution MUST maintain ongoing
multicast sessions of MNNs as the mobile router changes its
point of attachment. Group membership is currently gathered
by MLD.
o マルチキャストサポート：解決策は、移動ルータがその接続点を変
える時、ＭＮＮの進行中のマルチキャストセッションを維持しなく
てはなりません(MUST)。グループ加入者が現在ＭＬＤで集められま
す。

o Access control protocols and mechanisms: NEMO support MUST
not disallow protocols and mechanisms used by visiting mobile
hosts and routers to be authenticated and authorized to gain
access to the Internet via the mobile network infrastructure
(MRs).
o アクセス制御プロトコルとメカニズム：ＮＥＭＯサポートが訪問し
ている移動ホストとルータによって使われた移動ネットワーク基盤
を通したインターネットアクセスの認証と認可のためのプロトコル
と機構を拒絶してはなりません(MUST)。

o Security protocols and mechanisms
o セキュリティプロトコルとメカニズム。

o Routing protocols and mechanisms: routers deployed in mobile
networks may be routers like the others and therefrom are
expected to run in some situations a number of protocols such
as a routing protocol, Neighbor Discovery, ICMP, Router
Renumbering and others. NEMO support MUST thus not prevent
usual routing protocols and mechanisms to keep working within
the mobile network and to interact with the global Internet
(home network only in the case of basic NEMO support) when
necessary.
o ルーティングプロトコルとメカニズム：移動ネットワークに配置さ
れるルータは他のルータと同じようなものかもしれず、そしてある
状態で多くのルーティングプロトコルや近隣探索やＩＣＭＰやルー
タリナンバリングなどのプロトコルを動かすことを期待されます。
ＮＥＭＯサポートが移動ネットワークの中で、そして必要な時グロー
バルインターネット （基本的なＮＥＭＯサポートの場合、ホームネッ
トワーク）で、働き続ける通常のルーティングプロトコルと機構を
妨げてはなりません。

o Seamless Mobility: the solutions MUST be compatible with
FMIPv6
o スムーズな移動性：解決策はＤＭＩＰｖ６と互換性がなくてはなり
ません(MUST)。

- Security: NEMO support MUST comply with usual IETF security
policies and recommendations and MUST have its specific security
issues fully addressed. In practice, all NEMO support control
messages transmitted in the network MUST ensure an acceptable
level of security to prevent intruders to usurp identities.
Specifically, the following issues have to be addressed:
- セキュリティ：ＮＥＭＯサポートが通常のＩＥＴＦセキュリティポリシ
と推薦に従わなくてはならなくて(MUST)、そしてその特定のセキュリティ
問題が完全に扱われるようにしなくてはなりません(MUST)。実際は、ネッ
トワークで伝達した全てのＮＥＭＯサポート制御メッセージが、固体認識
を奪うための侵入者を妨ぐために受容できるレベルのセキュリティを保証
しなくてはなりません(MUST)。特に、次の問題は扱われなければなりませ
ん：

o Authentication of the sender to prevent identity usurpation.
o 固体認識の侵害を妨ぐための送信者の認証。

o Authorization, to make sure the sender is granted permission
to perform the operation as indicated in the control message.
o 送信者が制御装置メッセージで示される操作を行う許可を確かめる
ための認可。

o Confidentiality of the data contained in the control message.
o 制御メッセージ内のデータの機密性。

o Location Privacy: means to hide the actual location of MNNS
to third parties other than the HA if desired.
o 場所プライバシー：もし望むなら、ＨＡ以外の第三者にＭＮＮＳの
実際の場所を隠す手段。

5. One-liner Requirements for Basic NEMO Support
5. 基本的なＮＥＭＯサポートの必要条件の寸評

The NEMO WG will specify a unified and unique solution for "Basic
Network Mobility Support". The solution will allow all nodes in the
mobile network to be reachable via permanent IP addresses, as well as
maintain ongoing sessions as the MR changes its point of attachment
to the Internet topology. This will be done by maintaining a
bidirectional tunnel between the MR and its Home Agent. The Working
Group will investigate reusing the existing Mobile IPv6 mechanisms
for the tunnel management, or extend it if deemed necessary.
ＮＥＭＯ ＷＧは「基本的なネットワーク移動性サポート」の統一された、そ
してユニークな解決策を指定するでしょう。解決策はＭＲがインターネット
トポロジの接続点を変える時、移動ネットワークですべてのノードが永久の
ＩＰアドレスによって到達可能で、進行中のセッションを持続することを許
すでしょう。これはＭＲとそのホームエージェントの間に双方向性のトンネ
ルを持続することによってされるでしょう。作業グループはトンネル管理の
ために既存のモバイルＩＰｖ６メカニズムの再利用して調査するか、あるい
は、もし必要ならそれを拡張するでしょう。

The following requirements are placed on the Basic NEMO support
solution, hereafter referred to as "the solution":
次の必要条件は基本的なＮＥＭＯサポート解決策で置かれ、今後「解決策」
と述べられます：

R01: The solution MUST be implemented at the IP layer level.
R01: 解決策はＩＰ層レベルで実行されなくてはなりません(MUST)。

R02: The solution MUST set up a bi-directional tunnel between
MR and MR's Home Agent.
R02: 解決策はＭＲとＭＲのホームエージェント間に双方向性のトンネルを
組み立てなくてはなりません。

R03: All traffic exchanged between a MNN and a CN in the global
Internet MUST transit through the bidirectional tunnel.
R03: ＭＮＮとグローバルインターネットのＣＮ間で交換する全トラフィッ
クが双方向性のトンネルを通過しなければなりません(MUST)。

R04: MNNs MUST be reachable at a permanent IP address and name.
R04: ＭＮＮは永久のＩＰアドレスと名前で到達可能であるに違いありませ
ん(MUST)。

R05: The solution MUST maintain continuous sessions (both unicast
and multicast) between MNNs and arbitrary CNs after IP
handover of (one of) the MR.
R05: 解決策はＭＲ（の１つ）のハンドオーバー後にＭＮＮと任意のＣＮ間
の（ユニキャストとマルチキャストの）セッションを継続しなくては
なりません(MUST)。

R06: The solution MUST not require modifications to any node other
than MRs and HAs.
R06: 解決策はＭＲとＨＡ以外のノードに修正を必要としてはなりません
(MUST)。

R07: The solution MUST support fixed nodes, mobile hosts and mobile
routers in the mobile network.
R07: 解決策は移動ネットワークの固定ノードと移動ホストと移動ルータをサ
ポートしなくてはなりません(MUST)。

R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile
network link as either a home link or a foreign link.
R08: 解決策はＭＩＰｖ６ＭＮＮが移動ネットワークリンクをホームリンクあ
るいは外のリンクとして用いることを許さなくてはなりません(MUST)。

R09: The solution MUST not prevent the proper operation of Mobile
IPv6 (i.e. the solution MUST support MIPv6-enabled MNNs and
MUST also allow MNNs to receive and process Binding Updates
from arbitrary Mobile Nodes.)
R09: 解決策はモバイルＩＰｖ６の適切な運用を妨げてはなりません(MUST)
（すなわち解決策はＭＩＰｖ６対応ＭＮＮをサポートしなくてはならず
(MUST)、そして同じくＭＮＮに任意の移動ノードから結合更新を受け取っ
て、処理することを許さなくてはなりません）。

R10: The solution MUST treat all the potential configurations the
same way (whatever the number of subnets, MNNs, nested levels
of MRs, egress interfaces, ...)
R10: 解決策はすべての可能な設定を同様に扱わなくてはなりません（サブ
ネットの数、ＭＮＮ、ＭＲの入れ子のレベル、出口インタフェース、
・・・）。

R11: The solution MUST support mobile networks attaching to other
mobile networks (nested mobile networks). Although it is not
fully clear how many layers of topology MUST be supported, or
the complexity requirements of those nested networks, the goal
is to support arbitrary levels of recursive networks, and only
in the case where this is impractical and protocol concerns
preclude this support should the solution impose restrictions on
nesting (e.g. path MTU).
R11: 解決策は他の移動ネットワーク（入れ子移動ネットワーク）に接続し
ている移動ネットワークをサポートしなくてはなりません。もちろん、
トポロジーのいくつのレイヤをサポートしなければならない(MUST)か、
入れ子のネットワークの複雑性をどこまで扱うか、は完全に明確では
ないけれども、目標は任意のレベルの再帰的なネットワークのサポー
トで、そしてこれが非実用的でプロトコルの問題がこのサポートを妨
げる場合だけ、解決策が入れ子に制限を課す（例えばパスＭＴＵ）べ
きです。

R12: The solution MUST function for multi-homed mobile networks.
More precisely:
R12: 解決策はマルチホーム移動ネットワークで動作しなくてはなりません
(MUST)。より正確に：

R13.1: The solution MUST support mobile networks with
multiple MRs,
R13.1: 解決策は多数のMRの移動ネットワークをサポートしなくては
なりません。

R13.2: The solution MUST support MR with multiple interfaces,
R13.2: 解決策は、多数のインタフェースのＭＲをサポートしなくて
はなりません。

R13.3: The solution must support MR with multiple global
addresses on an egress interface.
R13.3: 解決策は出口インタフェース上の多数のグローバルアドレス
のＭＲをサポートしなくてはなりません。

R14: Signaling messages between the HA and the MR MUST be secured:
R14: ＨＡとＭＲ間での信号メッセージは安全に保たれなくてはなりませ
ん(MUST)：

R14.1: The receiver MUST be able to authenticate the sender
R14.1: 受信者は送信者を認証することができなければなりません
(MUST)。

R14.2: The function performed by the sender MUST be authorized
for the content carried
R14.2: 送信者によって実行された機能は運ばれた内容ので認証され
なくてはなりません(MUST)。

R14.3: Anti-replay MUST be provided
R14.3: 再生攻撃の対策が供給されなくてはなりません(MUST)。

R14.4: The signaling messages SHOULD be encrypted
R14.4: 信号メッセージは暗号化されるべきです(SHOULD)。

R15: The solution MUST ensure transparent continuation of routing and
management operations over the bi-directional tunnel when the MR
is away from home. (this includes e.g. routing protocols, router
renumbering, DHCPv6, etc)
R15: 解決策は、ＭＲがホームを出ている時、双方向性のトンネル上のルー
ティングと管理運用の透過的な継続を保証しなくてはなりません(MUST)。
（これは例えばルーティングプロトコルやルータリナンバリングやＤＨ
ＣＰｖ６などを含みます）。

R16: The solution MUST not impact on the routing fabric neither on
the Internet addressing architecture
R16: 解決策はインターネットアドレス体系上のルーティング構造に影響を与
えてはなりません(MUST)。

R17: The solution MUST ensure backward compatibility with other
standards defined by the IETF.
R17: 解決策はＩＥＴＦによって定義された他の標準との後方互換性を保証し
なくてはなりません(MUST)。

A. Acknowledgments
A. 謝辞

The material presented in this document takes most of its text from
discussions and previous documents submitted to the NEMO working
group. This includes initial contributions from Motorola, INRIA,
Ericsson and Nokia. We are particularly grateful to Hesham Soliman
(Ericsson) and the IETF ADs (Erik Nordmark and Thomas Narten) who
highly helped to set up the NEMO working group. We are also grateful
to all the following people whose comments highly contributed to the
present document: TJ Kniveton (Nokia), Alexandru Petrescu (Motorola),
Christophe Janneteau (Motorola), Pascal Thubert (CISCO), Hong-Yon
Lach (Motorola), Mattias Petterson (Ericsson) and all the others
people who have expressed their opinions on the NEMO (formely MONET)
mailing list. Thierry Ernst wish to personally grant support to its
previous employers, INRIA, and Motorola for their support and
direction in bringing this topic up to the IETF, particularly Claude
Castelluccia (INRIA) and Hong-Yon Lach (Motorola).
この文章の材料は、ＮＥＭＯ作業グループに提出された議論と以前の文書か
らテキストの大部分を得ました。これはモトローラとINRIAとエリクソンとノ
キアからの最初の貢献を含みます。我々はHesham Soliman（エリクソン）と、
ＮＥＭＯ作業グループを設立するのを手伝ったＩＥＴＦ ＡＤ達（Erik
NordmarkとThomas Narten）に特にありがたく思っています。我々は同じくそ
のコメントが大いに現在の文書に貢献した次の人々に感謝しています：TJ
Kniveton (Nokia)とAlexandru Petrescu (Motorola)とChristophe Janneteau
(Motorola)とPascal Thubert (CISCO)とHong-Yon Lach (Motorola)とMattias
Petterson (Ericsson)とすべてＮＥＭＯ（公式にはＭＯＮＥＴ）メーリング
リスト上で意見を表現した人々。Thierry Ernstは前の雇用者のINRIAとモト
ローラ、特にClaude Castelluccia（INRIA）とHong-Yon Lach（モトローラ）
に、このトピックをＩＥＴＦに持ち出すことのサポートと指示に個人的に支
持を与えることを望みます。

B. References
B. 参考文献

[IPv6-NODE] John Loughney
"IPv6 Node Requirements"
draft-ietf-ipv6-node-requirements-01.txt
July 2002, Work in progress.

[MIPv6] David B. Johnson and C. Perkins.
"Mobility Support in IPv6"
draft-ietf-mobileip-ipv6-20.txt,
January 2002. Work in progress.

[MOBILITY-TERMS] J. Manner
"Mobility Related Terminology
<draft-ietf-seamoby-mobility-terminology-00.txt>
August 2002. Work in progress

[NEMO-TERMS] Thierry Ernst and Hong-Yon Lach
"Terminology for Network Mobility Support",
draft-ernst-nemo-terminology.txt.
Work in progress.

[RFC1122] R. Braden (editor).
"Requirements for Internet Hosts - Communication
Layers". IETF RFC 1122, October 1989.

[RFC2119] S. Bradner
"Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, IETF, March 1997.

[RFC2460] S. Deering and R. Hinden.
"Internet Protocol Version 6 (IPv6) Specification"
IETF RFC 2460, December 1998.

C. Editors's Addresses
C. 著者のアドレス

Questions about this document can be directed to the NEMO working
group chairs:
この文書についての質問がＮＥＭＯ作業グループ議長に向けられることが
できます：

Thierry Ernst,
Keio University.
5322 Endo, Fujisawa-shi,
Kanagawa 252-8520, Japan.
Phone : +81-466-49-1100
Fax : +81-466-49-1395
Email : ernst@sfc.wide.ad.jp

T. J. Kniveton
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043, USA
Phone : +1 650 625-2025
Fax : +1 650 625-2502
EMail : Timothy.Kniveton@Nokia.com

D. Full Copyright Statement
D. 著作権表示全文

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。

Funding for the RFC editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。

Japanese translation by Ishida So