Network Working Group R. Wakikawa, Ed.
Request for Comments: 5648 Toyota ITC
Category: Standards Track V. Devarapalli
Wichorus
G. Tsirtsis
Qualcomm
T. Ernst
INRIA
K. Nagami
INTEC NetCore
October 2009
Multiple Care-of Addresses Registration
Abstract
抽象
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well.
現在のモバイルIPv6の仕様によれば、移動ノードは、複数の気付アドレスを持っているかもしれませんが、一つだけ、気付アドレスの主、そのホームエージェントとコレスポンデントノードに登録することができますと呼ばれます。複数が同時にアクセスして、モバイルノードは、インターネットへのアクセスを取得するためしかし、等コスト、帯域幅、遅延、の問題のために、それは有用であるが、その場合には、移動ノードは、複数のアクティブのIPv6気付アドレスで構成されます。この文書では、複数の気付アドレスを登録し、使用するモバイルIPv6プロトコルへの拡張を提案しています。この文書で提案されている拡張は、同様NEMO（ネットワークモビリティ）ベーシックサポートプロトコルを使用して、モバイルルータによって使用することができます。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンスに関するお知らせ
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Overview ...............................................4
4. Mobile IPv6 Extensions .........................................10
4.1. Binding Cache Structure and Binding Update List ...........10
4.2. Binding Update Message ....................................10
4.3. Binding Identifier Mobility Option ........................11
4.4. New Status Values for Binding Acknowledgement .............13
5. Mobile Node Operation ..........................................14
5.1. Management of Care-of Address(es) and Binding
Identifier(s) .............................................14
5.2. Binding Registration ......................................15
5.3. Bulk Registration .........................................16
5.4. Binding De-Registration ...................................16
5.5. Returning Home with Complete Binding
De-Registration: Using a Single Interface .................17
5.5.1. Using Only the Interface Attached to the
Home Link ..........................................17
5.5.2. Using Only the Interface Attached to the
Visited Link .......................................17
5.6. Returning Home: Simultaneous Home and Visited Link
Operation .................................................18
5.6.1. Problems of Simultaneous Home and Foreign
Attachments ........................................18
5.6.2. Overview and Approach ..............................18
5.6.3. Home Binding Support ...............................19
5.6.4. Sending Packets from the Home Link .................20
5.6.5. Leaving from the Home Link .........................20
5.7. Receiving Binding Acknowledgement .........................21
5.8. Receiving Binding Refresh Request .........................22
5.9. Bootstrapping .............................................22
6. Home Agent and Correspondent Node Operation ....................22
6.1. Searching Binding Cache with Binding Identifier ...........22
6.2. Processing Binding Update .................................23
6.3. Sending a Binding Acknowledgement for Home Link
Registration ..............................................25
6.4. Sending Binding Refresh Request ...........................27
6.5. Receiving Packets from Mobile Node ........................27
7. Network Mobility Applicability .................................27
8. DSMIPv6 Applicability ..........................................27
8.1. IPv4 Care-of Address Registration .........................28
8.2. IPv4 Home Address Management ..............................29
9. IPsec and IKEv2 Interaction ....................................30
9.1. Use of Care-of Address in the IKEv2 Exchange ..............31
9.2. Transport Mode IPsec-Protected Messages ...................31
9.3. Tunnel Mode IPsec-Protected Messages ......................31
9.3.1. Tunneled Home Test Init and Home Test Messages .....31
9.3.2. Tunneled Payload Traffic ...........................32
10. Security Considerations .......................................33
11. IANA Considerations ...........................................34
12. Acknowledgements ..............................................35
13. References ....................................................35
13.1. Normative References .....................................35
13.2. Informative References ...................................35
A mobile node may use various types of network interfaces to obtain durable and wide area network connectivity. This has increasingly become true with mobile nodes having multiple interfaces, such as 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and benefits of using multiple points of attachment are discussed in [MOTIVATION]. When a mobile node with multiple interfaces uses Mobile IPv6 [RFC3775] for mobility management, it cannot use its multiple interfaces to send and receive packets while taking advantage of session continuity provided by Mobile IPv6. This is because Mobile IPv6 allows the mobile node to bind only one care-of address at a time with its home address. See [MIP6ANALYSIS] for a further analysis of using multiple interfaces and addresses with Mobile IPv6.
モバイルノードは、耐久性とワイドエリアネットワーク接続性を得るために、ネットワークインタフェースの様々なタイプを使用することができます。これは、ますますモバイルノードが複数のインタフェース等、など802.2、802.11、802.16、携帯ラジオ、動機及びアタッチメントの複数の点を使用する利点[動機]に記載されているを有する真となっています。複数のインタフェースを有するモバイルノードがモビリティ管理にモバイルIPv6 [RFC3775]を使用する場合、それはモバイルIPv6によって提供されるセッションの継続性を利用しながらパケットを送信および受信するために、その複数のインタフェースを使用することはできません。モバイルIPv6は、モバイルノードがそのホームアドレスで同時に複数の気付けアドレスをバインドすることを可能にするためです。モバイルIPv6を用いて複数のインターフェースおよびアドレスを使用してのさらなる分析のために[MIP6ANALYSIS]参照。
This document proposes extensions to Mobile IPv6 to allow a mobile node to register multiple care-of addresses for a home address and create multiple binding cache entries. A new Binding Identification (BID) number is created for each binding the mobile node wants to create and is sent in the Binding Update. The home agent that receives this Binding Update creates a separate binding for each BID. The BID information is stored in the corresponding binding cache entry. The BID information can now be used to identify individual bindings. The same extensions can also be used in Binding Updates sent to the correspondent nodes.
この文書では、モバイルIPv6への拡張は、モバイルノードがホームアドレスに対して複数の気付アドレスを登録し、複数のバインディングキャッシュエントリを作成することを許可することを提案しています。新しいバインディング識別（BID）番号は、モバイルノードが作成したいとバインディング更新で送信されるバインディングごとに作成されます。このバインディングアップデートを受けたホームエージェントは、各BIDに別々の結合が作成されます。入札情報は、対応するバインディングキャッシュエントリに格納されています。 BID情報は現在、個々のバインディングを識別するために使用することができます。同じ拡張子にも対応ノードに送信されたバインディングアップデートに使用することができます。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Terms used in this document are defined in [RFC3775], [RFC3753], and [RFC4885]. In addition to or as a replacement of these, the following terms are defined or redefined:
このドキュメントで使用される用語は、[RFC3775]、[RFC3753]、および[RFC4885]で定義されています。これらの代替のかなどの他に、以下の用語を定義または再定義されています。
Binding Identification Number (BID)
結合識別番号（BID）
The BID is an identification number used to distinguish multiple bindings registered by the mobile node. Assignment of distinct BIDs allows a mobile node to register multiple binding cache entries for a given home address. BIDs assigned to the same home address must not be duplicated at the same time. The value zero is reserved for future extensions. Each BID is generated and managed by a mobile node. The BID is stored in the Binding Update List and is sent by the mobile node in the Binding Update. A mobile node may change the value of a BID at any time according to its administrative policy -- for instance, to protect its privacy. An implementation must carefully assign the BID so as to keep using the same BID for the same binding even when the status of the binding is changed. More details can be found in Section 5.1.
BIDは、モバイルノードによって登録された複数のバインディングを識別するための識別番号です。個別の入札の割り当ては、モバイルノードが与えられたホームアドレスに対して複数のバインディングキャッシュエントリを登録することができます。同じホームアドレスに割り当てられた入札が同時に重複してはいけません。値ゼロは、将来の拡張のために予約されています。各BIDが生成され、モバイルノードによって管理されています。 BIDバインディング更新リストに格納され、結合更新で移動ノードによって送信されます。モバイルノードは、その管理ポリシーに従って随時BIDの値を変更してもよい - 例えば、そのプライバシーを保護します。結合の状態が変わっても同じ結合のために同じBIDを使用して維持するように実装は慎重にBIDを割り当てる必要があります。詳細は、セクション5.1に記載されています。
Binding Identifier Mobility Option
バインディング識別子モビリティオプション
The Binding Identifier mobility option is used to carry the BID information.
バインディング識別子モビリティオプションは、BIDの情報を運ぶために使用されています。
Bulk Registration
一括登録
A mobile node can register multiple bindings at once by sending a single Binding Update. A mobile node can also replace some or all of the bindings available at the home agent with the new bindings by using the bulk registration. Bulk registration is supported only for home registration (i.e., with the home agent) as explained in Section 5.3. A mobile node must not perform the bulk registration mechanism described in this specification with a correspondent node.
モバイルノードは、単一の結合更新を送信することにより、一度に複数のバインディングを登録することができます。モバイルノードは、バルク登録を使用して、新しいバインディングとホームエージェントで入手可能なバインディングの一部またはすべてを置き換えることができます。セクション5.3で説明したように、バルク登録のみホーム登録（すなわち、ホームエージェントを有する）のためにサポートされています。モバイルノードは、コレスポンデントノードと本明細書に記載のバルク登録メカニズムを実行してはなりません。
A new extension called the Binding Identification number (BID) is introduced to distinguish between multiple bindings pertaining to the same home address. If a mobile node configures several IPv6 global addresses on one or more of its interfaces, it can register these addresses with its home agent as care-of addresses. If the mobile node wants to register multiple bindings, it MUST generate a BID for each care-of address and store the BID in the Binding Update List. A mobile node can manipulate each binding independently by using the BIDs. The mobile node then registers its care-of addresses by sending a Binding Update with a Binding Identifier mobility option.
新しい拡張機能は、バインディング識別番号（BID）が同じホームアドレスに関連する複数のバインディングを区別するために導入されると呼ばれます。モバイルノードは、そのインターフェースの一つ以上に複数のIPv6グローバルアドレスを設定した場合、それは気付アドレスとしてそのホームエージェントにこれらのアドレスを登録することができます。モバイルノードが複数のバインディングを登録したい場合は、各気付アドレスのBIDを生成し、バインディング更新リスト中にBIDを保存しなければなりません。モバイルノードは、それぞれのBIDを用いて独立に、結合操作することができます。モバイルノードは、バインディング識別子モビリティオプションとバインディングアップデートを送信することにより、その気付アドレスを登録します。
The BID is included in the Binding Identifier mobility option. After receiving the Binding Update with a Binding Identifier mobility option, the home agent MUST copy the BID from the Binding Identifier mobility option to the corresponding field in the binding cache entry. If there is an existing binding cache entry for the mobile node, and if the BID in the Binding Update does not match the one with the existing entry, the home agent MUST create a new binding cache entry for the new care-of address and BID. The mobile node can either register multiple care-of addresses at once in a single Binding Update or independently in individual Binding Updates.
BIDは、バインディング識別子モビリティオプションに含まれています。バインディング識別子モビリティオプションとバインディングアップデートを受け取った後、ホームエージェントはバインディングキャッシュエントリに対応するフィールドにバインド識別子モビリティオプションからBIDをコピーしなければなりません。そこに、移動ノードのための既存のバインディングキャッシュエントリで、バインディング更新中BIDは、既存のエントリを1と一致しない場合は、ホームエージェントは、新たな気付アドレスとBIDのための新しいバインディングキャッシュエントリを作成する必要がある場合。モバイルノードは、単一の結合更新中または独立して個々の結合のアップデートで一度に複数の気付けアドレスを登録することができます。
If the mobile host wishes to register its binding with a correspondent node, it must perform return routability operations as described in [RFC3775]. This includes managing a Care-of Keygen token per care-of address and exchanging Care-of Test Init and Care-of Test messages with the correspondent node for each care-of address. The mobile node MAY use the same BID that it used with the home agent for a particular care-of address. For protocol simplicity, bulk registration to correspondent nodes is not supported in this document. This is because the return routability mechanism introduced in [RFC3775] cannot be easily extended to verify multiple care-of addresses stored in a single Binding Update.
モバイルホストががコレスポンデントノードとの結合を登録したい場合は、[RFC3775]に記載されているように、リターン・ルータビリティ・オペレーションを実行しなければなりません。これは、気付アドレスあたりkeygenのケア - のトークンを管理し、各気付アドレスのためのコレスポンデントノードと気付試験開始と気付テストメッセージを交換する含まれています。モバイルノードは、それが特定の気付アドレスをホームエージェントに使用したのと同じBIDを使用するかもしれません。プロトコル簡単にするために、コレスポンデントノードへの一括登録は、このドキュメントではサポートされていません。 [RFC3775]で導入され、リターン・ルータビリティ機構が簡単に複数の気付単結合更新に格納されたアドレスを確認するように拡張することができないからです。
Figure 1 illustrates the configuration where the mobile node obtains multiple care-of addresses at foreign links. The mobile node can utilize all the care-of addresses. In Figure 1, the home address of the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 different interfaces and possibly acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2, and BID3 to each care-of address.
図1は、モバイルノードが外部リンクに複数の気付アドレスを取得する構成を示しています。モバイルノードは、すべての気付アドレスを利用することができます。図1では、モバイルノード（MN）のホームアドレスが2001：DB8 :: EUI。モバイルノードは、3つの異なるインターフェイスを有しており、おそらくは気付アドレス1-3（CoA1を、CoA2の、CoA3）を取得します。モバイルノードは、各気付アドレスにBID1、BID2、及びBID3を割り当てます。
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +--------+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
Binding Cache Database: home agent's binding (Proxy neighbor advertisement is active) binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] binding [2001:db8::EUI BID3 care-of address3] correspondent node's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] binding [2001:db8::EUI BID3 care-of address3]
バインディングキャッシュデータベース：ホームエージェントのバインディングバインディング（プロキシ近隣広告がアクティブである）[2001：アドレス1 DB8 :: EUI BID1の-のケア]結合[2001：DB8 :: EUI BID2気付アドレス2] 2001 [結合：DB8 :: EUI ]アドレス3 BID3の-のケアコレスポンデント・ノードのバインディングバインディング[2001：DB8 :: EUI BID1気付アドレス1] 2001 [結合：DB8 :: EUI BID2アドレス2]結合[2001気付：DB8 :: EUI BID3アドレス3気付け]
Figure 1: Multiple Care-of Addresses Registration
図1：複数の気付アドレスの登録
If the mobile node decides to act as a regular mobile node compliant with [RFC3775], it sends a Binding Update without any Binding Identifier mobility options. The receiver of the Binding Update deletes all the bindings registered with a BID and registers only a single binding for the mobile node. Note that the mobile node can continue using the BID even if it has only a single binding that is active.
モバイルノードは、[RFC3775]に準拠し、通常のモバイルノードとして動作することを決定した場合、それはどのバインディング識別子モビリティオプションを指定せずにバインディングアップデートを送信します。バインディング更新の受信機は、BIDに登録されているすべてのバインディングを削除し、モバイルノードのバインディング単一登録します。モバイルノードは、それがアクティブであることのみが単一結合であってもBIDを使用し続けることができることに留意されたいです。
Binding cache lookup is done based on the home address and BID information if a BID is available. This is different from RFC 3775, where only the home address is used for binding cache lookup. Binding cache lookup is operated for either protocol signaling or data packets. For protocol signaling such as a Binding Update, BID should be always carried by a BID sub-option in a protocol signaling. Therefore, a correspondent binding cache that matches the specified BID MUST be found from the binding cache database. On the other hand, for the data packets, no BID information is carried in a packet. The binding cache lookup may involve policy or flow filters to retrieve a correspondent BID per packet in cases where some policy or flow filters are used to direct a certain packet or flow to a particular care-of address. However, the binding cache lookup using policy or flow filters is out of scope for this document. If no such mechanism is available and no BID is found for a packet, a node SHOULD use the binding that was last verified by receiving data packets or signaling from the mobile node. In case the binding cache lookup for data packets, using the combination of home address and BID, does not return a valid binding cache entry, the home agent SHOULD perform the lookup based on only the home address as described in [RFC3775].
バインディングキャッシュ検索はBIDが利用可能な場合ホームアドレスとBID情報に基づいて行われます。これは、ホームアドレスがキャッシュ・ルックアップを結合するために使用されているRFC 3775、異なっています。バインディングキャッシュルックアップは、プロトコルシグナリングまたはデータパケットのいずれかのために操作されます。結合更新のようなシグナリングプロトコルのために、BIDは常にプロトコルシグナリングにおけるBIDサブオプションで実施すべきです。したがって、指定されたBIDと一致する特派バインディングキャッシュがバインディングキャッシュデータベースから見つけられなければなりません。一方、データパケットのために、何の入札情報は、パケットで搬送されていません。バインディングキャッシュ検索は、いくつかのポリシーまたはフローフィルタは、特定のパケットを指示したり、特定の気付アドレスに流れるように使用されている場合は、パケットあたりの特派BIDを取得するために、ポリシーまたはフローフィルタを含むことができます。ただし、ポリシーまたはフローフィルタを使用してバインディングキャッシュルックアップはこの文書の範囲外です。そのような機構が利用可能でないとNO BIDは、パケットのため見つからない場合、ノードは、データパケットを受信するか、モバイルノードからのシグナリングによって確認最後結合を使用すべきです。場合は、データパケットのためのバインディングキャッシュ検索、ホームアドレスとBIDの組み合わせを使用して、有効なバインディングキャッシュエントリを返しません[RFC3775]で説明したように、ホームエージェントのみがホームアドレスに基づいて検索を実行する必要があります。
In any case, to avoid problems with upper-layer protocols and TCP in particular, a single packet flow as identified by the 5-tuple SHOULD only be sent to a single care-of address at a time.
いずれの場合においても、特に上位層プロトコルおよびTCPの問題を回避するために、5タプルによって識別される単一のパケットフローは、一度に単一の気付けアドレスに送信する必要があります。
The mobile node may return to the home link through one of its interfaces. There are two options possible for the mobile node when it returns home. Sections 5.5.1 and 5.6 describe the returning-home procedures in more detail.
モバイルノードは、そのインターフェースの1つを介してホームリンクに戻ることができます。それは家に戻ったときに、移動ノードのための可能な2つのオプションがあります。セクション5.5.1と5.6は、より詳細に戻って、自宅の手順を説明します。
1. The mobile node uses only the interface with which it attaches to the home link and takes back full ownership of its HoA (home address) on the home link. This is illustrated in Figure 2. It de-registers all bindings with the home agent related to all care-of addresses. The interfaces still attached to the visited link(s) are no longer going to be receiving any encapsulated traffic from the home agent. On the other hand, the mobile node can continue communicating with the correspondent nodes from the other interfaces attached to foreign links by using route optimization. Even if the mobile node is attached to the home link, it can still send Binding Updates for other active care-of addresses (CoA1 and CoA2) to correspondent nodes. Since the correspondent node has bindings, packets are routed from and to each care-of address directly.
1.モバイルノードは、それがホームリンクに接続すると、ホームリンク上のHoAを（ホームアドレス）の完全な所有権を取り戻したとのインタフェースのみを使用しています。これは、すべての気付アドレスに関連したホームエージェントに図2.デレジスタにすべてのバインディングを示しています。まだ訪れたリンク（複数可）に接続インタフェースは、ホームエージェントから任意のカプセル化されたトラフィックを受信することになるだろうされなくなりました。一方、モバイルノードは、ルート最適化を使用して、外国のリンクに取り付けられた他のインターフェースからコレスポンデントノードとの通信を継続することができます。モバイルノードがホームリンクに接続されている場合でも、それはまだ他のアクティブな気付アドレス（CoA1をしてCoA2の）への対応ノードのバインディングアップデートを送信することができます。コレスポンデントノードは、バインディングを持っているので、パケットから、それぞれの気付アドレスに直接ルーティングされます。
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database: home agent's binding none correspondent node's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2]
キャッシュデータベースをバインド：ホームエージェントの結合なし相手ノードのバインディングバインディング[2001：DB8 :: EUI BID1気付アドレス1] [2001：DB8 :: EUI BID2の気付アドレス2]結合
Figure 2: Using Only an Interface Attached to the Home Link
図2：ホームリンクに接続されたインタフェースのみを使用します
2. The mobile node may simultaneously use both the interface attached to the home link and the interfaces still attached to the visited link(s) as shown in Figure 3. There are two possible topologies, depending on whether or not the home agent is the only router on the home link. The operation of Neighbor Discovery [RFC4861] is different in the two topologies. More details can be found in Section 5.6. The home agent and the correspondent node have the binding entries listed in Figure 3 in their binding cache database in both topologies. The home agent also knows that the mobile node is attached to the home link. All the traffic from the Internet is intercepted by the home agent first and routed to either the interface attached to the home link or to one of the foreign links. How the home agent decides to route a particular flow to the interface attached to the home link or foreign link is out of scope for this document.
図3に示すように、前記モバイルノードが同時にホームエージェントであるか否かに応じて、2つの可能なトポロジがあり、ホームリンクに接続されたインターフェイスと、まだ訪問リンク（単数または複数）に取り付けられたインターフェイスの両方を使用することができますホームリンク上のルータだけ。近隣探索[RFC4861]の操作は、2つのトポロジが異なります。詳細は、セクション5.6に記載されています。ホームエージェントとコレスポンデントノードは、両方のトポロジでは、それらの結合キャッシュデータベースに、図3に記載されているバインディングエントリを持っています。ホームエージェントは、モバイルノードがホームリンクに接続されていることを知っています。インターネットからのすべてのトラフィックは、まず、ホームエージェントによって傍受され、ホームリンクにまたは外国のリンクのいずれかに接続されたインターフェイスのいずれかにルーティングされます。ホームエージェントは、ルーティングすることを決定どのようにホームリンクや外部リンクに接続されたインターフェイスに、特定のフローは、この文書の範囲外です。
Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database: home agent's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] correspondent node's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2]
バインディングキャッシュデータベース：結合結合ホームエージェントの[2001：DB8 :: EUI BID1の気付アドレス1]結合[2001：DB8 :: EUI BID2の気付アドレス2]相手ノードのバインディングバインディング[2001：DB8 :: EUI BID1気付アドレス1] [2001バインディング：DB8 :: EUI BID2の気付アドレス2]は
Figure 3: Simultaneous Home and Visited Link Operation
図3：同時ホーム及び訪問リンクの動作
This specification keeps backwards compatibility with [RFC3775]. If a receiver (either home agent or correspondent node) does not support this specification, it does not understand the Binding Identifier mobility option. The receiver skips the unknown mobility option (i.e., the Binding Identifier mobility option) and processes the Binding Update as defined in [RFC3775]. In order to keep backwards compatibility with [RFC3775], when a mobile node sends a Binding
この仕様は、[RFC3775]との下位互換性を保持します。受信機（ホームエージェントやコレスポンデントノードのいずれか）がこの仕様をサポートしていない場合は、バインディング識別子モビリティオプションを理解していません。受信機は、未知のモビリティオプション（すなわち、バインディング識別子モビリティオプション）をスキップして、[RFC3775]で定義されるようにバインディング更新を処理します。モバイルノードがバインディングを送信するときに、[RFC3775]との下位互換性を保つために
Update message with extensions described in this document, the receiver needs to reflect the Binding Identifier mobility option in the Binding Acknowledgement. If the mobile node finds no Binding Identifier mobility options in the received Binding Acknowledgement, it assumes the other end node does not support this specification. In such case, the mobile node needs to fall back to the legacy [RFC3775]-compliant mobile node. If it is the home registration, the mobile node MAY try to discover another home agent that supports the Binding Identifier mobility option for the home registration.
この文書で説明した拡張子を持つメッセージを更新し、受信機は、結合確認でバインディング識別子モビリティオプションを反映する必要があります。モバイルノードが受信結合確認にはバインディング識別子モビリティオプションが見つからない場合は、他のエンド・ノードは、この仕様をサポートしていません想定しています。このような場合には、モバイルノードは、バックレガシー[RFC3775]準拠のモバイルノードに落ちる必要があります。それはホーム登録である場合は、モバイルノードは、ホーム登録のためのバインディング識別子モビリティオプションをサポートする別のホームエージェントを発見しようとするかもしれません。
This section summarizes the extensions to Mobile IPv6 that are necessary to manage multiple bindings.
このセクションでは、複数のバインディングを管理するために必要なモバイルIPv6への拡張をまとめました。
The BID is required to be stored in the binding cache and Binding Update List structure.
BIDは、キャッシュを結合し、結合更新リスト構造に格納する必要があります。
The sequence number value MUST be shared among all the Binding Update List entries related to Binding Updates sent to a particular home agent or correspondent node. Whenever a mobile node sends either an individual or a bulk Binding Update, the sequence number is incremented. When a home agent receives an individual Binding Update, it should update the sequence number for all the bindings for a particular mobile node, with the sequence number in the received Binding Update.
シーケンス番号値は、特定のホームエージェントやコレスポンデントノードに送られた結合更新に関連するすべての結合更新リストエントリの間で共有されなければなりません。モバイルノードは、個々または一括バインディング更新のいずれかを送信するたびに、シーケンス番号がインクリメントされます。ホームエージェントは、個々の結合更新を受信すると、受信したバインディング更新のシーケンス番号と、特定のモバイルノードに関するすべてのバインディングのシーケンス番号を更新しなければなりません。
This specification extends the Binding Update message with a new flag. The flag is shown and described below.
この仕様は、新しいフラグをBinding Updateメッセージを拡張します。フラグが示され、以下に説明します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Update Message
図4：バインディング更新メッセージ
Overwrite (O) flag
上書き（O）フラグ
When this flag is set, all the binding cache entries for a mobile node are replaced by new entries registering with this Binding Update message. This flag is only used when the BID mobility option is carried with the Binding Update.
このフラグが設定されている場合、モバイルノードのすべてのバインディングキャッシュエントリは、このBinding Updateメッセージを登録し、新しいエントリに置き換えられます。 BIDのモビリティオプションは、バインディングアップデートを行った場合、このフラグは使用されています。
Reserved
予約済み
6-bit Reserved field.
6ビットの予約フィールド。
The Binding Identifier mobility option is included in the Binding Update, Binding Acknowledgement, Binding Refresh Request, and Care-of Test Init and Care-of Test messages. The Binding Identifier mobility option has an alignment requirement of 2n if the Care-of Address field is not present. Otherwise, it has the alignment requirement of 8n + 2.
バインディング識別子モビリティオプションは、リフレッシュ要求、および気付試験開始と気付テストメッセージをバインディング、謝辞をバインディング、バインディングアップデートに含まれています。気付アドレスのフィールドが存在しない場合はバインディング識別子モビリティオプションは、2Nの整列要求があります。それ以外の場合は、8N + 2の整列要求を有しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 care-of address (CoA) :
+ +
+---------------------------------------------------------------+
Figure 5: BID Mobility Option
図5：BIDモビリティオプション
Type
タイプ
Type value for Binding Identifier is 35.
識別子を結合するためのタイプ値は35です。
Length
長さ
8-bit unsigned integer. Length of the option, in octets, excluding the Type and Length fields. It MUST be set to either 4, 8, or 20 depending on the Care-of Address field. When the care-of address is not carried by this option, the length value MUST be set to 4. If the IPv4 care-of address is stored in the Care-of Address field, the length MUST be 8. Otherwise, the length value MUST be set to 20 for IPv6 care-of addresses.
8ビットの符号なし整数。タイプと長さフィールドを除くオクテット内のオプションの長さ、、。これは、気付アドレスフィールドに応じて、4、8、または20のいずれかに設定しなければなりません。気付アドレスは、このオプションによって運ばれていない場合は、長さの値は、長さの値はIPv4気付アドレスは気付アドレスフィールドに格納されている場合は、長さがそれ以外の場合は8でなければならない4に設定しなければなりません。 IPv6気付アドレスを20に設定しなければなりません。
Binding ID (BID)
結合ID（BID）
The BID that is assigned to the binding indicated by the care-of address in the Binding Update or the Binding Identifier mobility option. The BID is a 16-bit unsigned integer. The value of zero is reserved and SHOULD NOT be used.
結合結合更新または結合識別子モビリティオプションで気付アドレスによって示さに割り当てられているBID。 BIDは、16ビットの符号なし整数です。ゼロの値は予約され、使用してはなりません。
Status
状態
The Status field is an 8-bit unsigned integer. When the Binding Identifier mobility option is included in a Binding Acknowledgement, this field overwrites the Status field in the Binding Acknowledgement only for this BID. If this field is set to zero, the receiver ignores this field and uses the registration status stored in the Binding Acknowledgement message. The receiver MUST ignore this field if the Binding Identifier mobility option is not carried within either the Binding Acknowledgement or the Care-of Test messages. The possible status codes are the same as the status codes of the Binding Acknowledgement. This Status field is also used to carry error information related to the care-of address test in the Care-of Test message.
Statusフィールドは、8ビットの符号なし整数です。バインディング識別子モビリティオプションは結合確認に含まれている場合、このフィールドは、このBIDのための結合確認のStatusフィールドを上書きします。このフィールドがゼロに設定されている場合、受信側はこのフィールドを無視し、Binding Acknowledgementメッセージに格納された登録状態を使用します。バインディング識別子モビリティオプションがバインディング確認や気付テストメッセージのいずれかの中に運ばれていない場合、受信機は、このフィールドを無視しなければなりません。可能なステータスコードは、結合確認のステータスコードと同じです。このステータスフィールドは、気付テストメッセージにおける気付アドレスのテストに関連するエラー情報を運ぶために使用されています。
Simultaneous Home and Foreign Binding (H) flag
同時ホーム及び外国バインディング（H）フラグ
This flag indicates that the mobile node registers multiple bindings to the home agent while it is attached to the home link. This flag is valid only for a Binding Update sent to the home agent.
このフラグは、それがホームリンクに接続されている間、移動ノードがホームエージェントに複数のバインディングを登録することを示しています。このフラグは、ホームエージェントに送信されたバインディング更新のために有効です。
Reserved
予約済み
7-bit Reserved field. The value MUST be initialized to zero by the sender, and SHOULD be ignored by the receiver.
7ビットの予約フィールド。値は送信者によってゼロに初期化されなければならない、そして受信機によって無視されるべきです。
Care-of Address
気付アドレス
If a Binding Identifier mobility option is included in a Binding Update for the home registration, either IPv4 or IPv6 care-of addresses for the corresponding BID can be stored in this field. For the binding registration to correspondent nodes (i.e., route optimization), only IPv6 care-of addresses can be stored in this field. If no address is specified in this field, the length of this field MUST be zero (i.e., not appear in the option). If the option is included in any messages other than a Binding Update, the length of this field MUST also be zero.
バインディング識別子モビリティ・オプションはホーム登録のためのバインディングアップデートに含まれている場合は、IPv4またはIPv6の気付対応するBIDのためのアドレスのいずれかがこのフィールドに格納することができます。コレスポンデントノード（すなわち、ルート最適化）への結合を登録するための、唯一のIPv6気付アドレスは、このフィールドに格納することができます。何アドレスがこのフィールドに指定されていない場合、このフィールドの長さ（すなわち、オプションで表示されていない）ゼロでなければなりません。オプションは、結合更新以外のすべてのメッセージに含まれている場合、このフィールドの長さもゼロでなければなりません。
New status values for the Status field in a Binding Acknowledgement are defined for handling the multiple care-of addresses registration:
結合確認のStatusフィールドのための新しいステータス値は、複数の気付アドレスの登録を処理するために定義されています。
MCOA NOTCOMPLETE (4)
MCOA NOTCOMPLETE（4）
In bulk registration, not all the Binding Identifier mobility options were successfully registered. Some of them were rejected. The error status value of the failed mobility option is individually stored in the Status field of the Binding Identifier mobility option.
一括登録ではなく、すべてのバインディング識別子モビリティオプションが正常に登録されました。それらのいくつかが拒否されました。失敗したモビリティオプションのエラーステータスの値が個別にバインディング識別子モビリティオプションのStatusフィールドに格納されます。
MCOA RETURNHOME WO/NDP (5)
MCOAはRETURNHOME / NDPを持っている（5）
When a mobile node returns home, it MUST NOT use the Neighbor Discovery Protocol (NDP) for the home address on the home link. This is explained in more detail in Section 5.6.
モバイルノードが帰宅すると、それがホームリンク上のホームアドレスの近隣探索プロトコル（NDP）を使用してはなりません。これは、5.6節で詳しく説明されています。
MCOA MALFORMED (164)
MCOA MALFORMED（164）
Registration failed because the Binding Identifier mobility option was not formatted correctly. This value is used in the following cases:
バインディング識別子モビリティオプションが正しくフォーマットされていなかったため登録に失敗しました。この値は、次の場合に使用されます。
* when the wrong length value is specified (neither 4, 8, nor 20) in the Length field of the Binding Identifier mobility option.
*間違った長さの値は、結合識別子モビリティオプションの長さフィールド（4、8、また20も）を指定します。
* when a unicast routable address is not specified in the Care-of Address field of the Binding Identifier mobility option.
*ユニキャストルーティング可能なアドレスが気付バインディング識別子モビリティオプションのアドレスフィールドに指定されていません。
* when a care-of address does not appear in the Care-of Address field of the Binding Identifier mobility option stored in an IPsec Encapsulating Security Payload (ESP)-protected Binding Update.
気付けアドレスは、IPsecのカプセル化セキュリティペイロード（ESP）に保存されているバインディング識別子モビリティオプションの気付アドレスフィールドに表示されないとき*バインディング更新で保護さ。
MCOA NON-MCOA BINDING EXISTS (165)
MCOA NON-MCOA結合（165）が存在します
Indicates that a bootstrapping multiple care-of addresses registration was performed without the 'O' flag set.
複数のアドレス登録気付けブートストラップが「O」フラグを設定せずに行われたことを示します。
MCOA UNKOWN COA (167)
MCOA UNKOWN COA（167）
Indicates that a Binding Identifier mobility option did not include a Care-of Address field and that the receiver has no record for the Binding ID indicated in the same option.
バインディング識別子モビリティオプションは、気付アドレスフィールドを含めると受信機バインディングIDが同じオプションで示されたためにレコードがないことをしなかったことを示します。
MCOA PROHIBITED (166)
MCOA禁止（166）
Implies that the multiple care-of addresses registration is administratively prohibited.
複数の気付アドレスの登録が管理上禁止されていることを意味します。
MCOA BULK REGISTRATION PROHIBITED (168)
禁止MCOAのBULK登録（168）
Bulk binding registration is either not permitted or not supported. Note that the bulk registration is an optional procedure and might not be available on a home agent.
バルク結合登録が許可されていないか、またはサポートされていませんか。一括登録はオプションの手順で、ホームエージェントに利用できない場合がありますので注意してください。
MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
MCOA同時ホームとFOREIGN禁止（169）
Simultaneous home and foreign attachment is neither supported nor permitted.
同時家と外国添付ファイルがサポートされていないにも許可もされていません。
There are two cases when a mobile node might acquire several care-of addresses. A mixture of the two cases is also possible. Note that a mobile node can use BID regardless of the number of interfaces and care-of addresses. Whether or not a mobile node uses BID is determined by a local configuration.
モバイルノードが複数の気付アドレスを取得可能性がある2つのケースがあります。 2例の混合物も可能です。モバイルノードは、インターフェースの数にかかわらず、BIDを使用して、気付アドレスすることができることに留意されたいです。モバイルノードがBIDを使用するかどうかは、ローカルの構成によって決定されます。
1. A mobile node is using several physical network interfaces and acquires a care-of address on each of its interfaces.
1.モバイルノードは、複数の物理ネットワーク・インターフェースを使用して、そのインターフェイスの各々に気付アドレスを取得します。
2. A mobile node uses a single physical network interface but receives advertisements for multiple prefixes on the link to which the interface is attached. This will result in the mobile node configuring several global addresses on the interface from each of the announced prefixes.
前記モバイルノードは、単一の物理ネットワーク・インターフェースを使用するが、インタフェースが接続されているリンク上で複数のプレフィックスの広告を受信します。これは、発表されたプレフィックスのそれぞれからのインターフェイス上のいくつかのグローバルアドレスを設定するモバイルノードになります。
The difference between the above two cases is only in the number of physical network interfaces and is therefore irrelevant in this document. What is of significance is the fact that the mobile node has several addresses it can use as care-of addresses.
上記2例との違いは、物理ネットワークインタフェースの数であり、本書ではそれ故無関係です。何に重要であることは、モバイルノードが気付アドレスとして使用できるいくつかのアドレスを持っているという事実です。
A mobile node assigns a BID to each care-of address when it wants to register them simultaneously with its home address. The BID MUST be unique for a given home address. The value is an integer between 1 and 65535. A zero value SHOULD NOT be used as a BID. If a mobile node has only one care-of address, the assignment of a BID is not needed until it has multiple care-of addresses with which to register, at which time all of the care-of addresses MUST be mapped to BIDs.
それはそのホームアドレスと同時に、それらを登録したい場合、移動ノードは、それぞれの気付アドレスにBIDを割り当てます。 BIDは、与えられたホームアドレスに対して一意でなければなりません。値がゼロ値はBIDとして使用することはできません1〜65535の整数です。モバイルノードが一つだけ気付アドレスを持っている場合、それは、複数の気付け登録するとアドレス、気付アドレスのすべてがのBIDにマップする必要があり、その時点でを持ってまで、BIDの割り当ては必要ありません。
When a mobile node registers a given BID for the first time, it MUST include the Care-of Address field in the Binding Identifier mobility option. For any subsequent registrations that either re-register or de-register the same BID, the MN need not include the Care-of Address field in the Binding Identifier mobility option.
モバイルノードが最初に与えられたBIDを登録する際には、バインディング識別子モビリティオプションで気付アドレスフィールドを含まなければなりません。いずれかの再登録または同じBIDを登録解除、その後の登録のために、MNは、バインディング識別子モビリティオプションで気付アドレスフィールドを含める必要はありません。
For the multiple care-of addresses registration, the mobile node MUST include a Binding Identifier mobility option(s) in the Binding Update as shown in Figure 6.
図6に示すように、複数の気付アドレスの登録のために、モバイルノードは、バインディング更新中の結合識別子モビリティオプション（単数または複数）を含まなければなりません。
When IPsec ESP is used for protecting the Binding Update, a care-of address MUST be carried in an alternate Care-of Address mobility option as described in [RFC4877]. However, in this specification, the care-of address MUST be carried in the Care-of Address field of the Binding Identifier mobility option. In order to save bits of the Binding Update, the alternate Care-of Address option MUST NOT be included.
IPsec ESPがバインディング更新を保護するために使用される場合、[RFC4877]に記載されているように、気付アドレスは、代替気付アドレスモビリティオプションで実行されなければなりません。しかし、この仕様では、気付アドレスは、ケアのバインディング識別子モビリティオプションのアドレスフィールドに運ばれなければなりません。バインディング更新のビットを節約するために、代替気付アドレスオプションを含んではいけません。
For binding registration to a correspondent node, the mobile node MUST have both active Home and Care-of Keygen tokens for Kbm (binding management key; see Section 5.2.5 of [RFC3775]) before sending the Binding Update. The care-of Keygen tokens MUST be maintained for each care-of address that the mobile node wants to register to the correspondent node. The Binding Update to the correspondent node is protected by the Binding Authorization Data mobility option that is placed after the Binding Identifier mobility option.
コレスポンデントノードへの登録を結合するために、モバイルノードは、Kbmを積極的なホームとケアのkeygenの両方のトークン持っている必要があります（管理キーを結合する; [RFC3775]のセクション5.2.5を参照）バインディングアップデートを送信する前に。気付keygenのトークンは、各気付アドレスモバイルノードがコレスポンデントノードに登録したいのために維持されなければなりません。コレスポンデントノードへのバインディングアップデートはバインディング識別子モビリティオプションの後に置かれる結合認証データ移動オプションによって保護されています。
IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 Home Address Option ESP Header* Mobility header Binding Update Mobility Options Binding Identifier mobility option Binding Authorization mobility option+ (*) if necessary, for home registration (+) if necessary, for route optimization
IPv6ヘッダ（SRC =気付アドレス、DST =ホームエージェントアドレス）ホーム登録（+）の場合の認可モビリティオプション+（*）必要に応じて、バインディング識別子モビリティオプションを、バインディングアップデートモビリティオプションバインディングのIPv6ホームアドレスオプションESPヘッダ*モビリティヘッダルート最適化のために、必要な
Figure 6: Binding Update for Binding Registration
図6：バインディング登録のためのバインディングアップデート
If the mobile node wants to replace existing registered bindings on the home agent with the single binding in the sent Binding Update, it sets the 'O' flag. If the 'O' flag is not set, then the binding will be added to existing bindings in the home agent. The single binding will be registered with the assigned BID. Section 6.2 describes this registration procedure in detail.
モバイルノードが送信されたバインディングアップデートで単一の結合を持つホームエージェントに既存の登録済みバインディングを交換したい場合、それは「O」フラグを設定します。 「O」フラグが設定されていない場合、バインディングは、ホームエージェントの既存のバインディングに追加されます。単一の結合は、割り当てられたBIDに登録されます。 6.2節では詳細に、この登録手順を説明します。
Bulk registration is an optimization for binding multiple care-of addresses to a home address using a single Binding Update. This is very useful if the mobile node, for instance, does not want to send a lot of signaling messages through an interface where the bandwidth is scarce. This document specifies bulk registration only for the mobile node's home registration. A mobile node performing bulk registration with a correspondent node is out of scope.
一括登録は、単一のバインディングアップデートを使用してホームアドレスに対して複数の気付アドレスを結合するための最適化です。モバイルノードは、例えば、帯域幅が不足しているインタフェースを介してシグナリングメッセージの多くを送信したくない場合、これは非常に便利です。この文書では、唯一のモバイルノードのホーム登録のための一括登録を指定します。コレスポンデントノードとバルク登録を行う移動ノードが範囲外です。
To use bulk registration, the mobile node includes a Binding Identifier mobility option for each BID it wants to register in the same Binding Update message. As with single registrations (see Section 5.1), the Care-of Address field is included for each BID registered for the first time. This is shown in Figure 7. The rest of the fields and options in the Binding Update (such as Lifetime, Sequence Number, and the flags in the Binding Update) are common across all care-of addresses.
一括登録を使用するには、モバイルノードは、同じBinding Updateメッセージに登録したい各BIDのためのバインディング識別子モビリティオプションが含まれています。単一の登録（セクション5.1を参照）と同様に、気付アドレスフィールドが初めて登録された各BIDのために含まれています。これは、（例えば、ライフタイム、シーケンス番号、及びバインディング更新中フラグなど）バインディング更新のフィールドとオプションの残りは全て気付アドレス間で共通である図7に示されています。
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header
Mobility header
Binding Update
Mobility Options
Binding Identifier1 (including Care-of Address)
Binding Identifier2 (including Care-of Address)
Binding Identifier3 (no Care-of Address)
Binding IdentifierN (no Care-of Address)
:
：
Figure 7: Binding Update for Bulk Registration
図7：一括登録のためのバインディングアップデート
As with regular registrations, if the mobile node wants to replace existing registered bindings on the home agent with the multiple bindings in the sent Binding Update, it sets the 'O' flag in the Binding Update; otherwise, the bindings are added to the existing bindings in the home agent.
モバイルノードが送信されたバインディングアップデートで複数のバインディングを持つホームエージェントに既存の登録済みバインディングを交換したい場合は、正規の登録と同じように、それは、バインディングアップデートで「O」フラグを設定します。それ以外の場合は、バインディングは、ホームエージェントの既存のバインディングに追加されます。
When a mobile node decides to delete all the bindings for its home address, it sends a regular de-registration Binding Update with lifetime set to zero as defined in [RFC3775]. The Binding Identifier mobility option is not required.
モバイルノードがそのホームアドレスのすべてのバインディングを削除することを決定した場合は、[RFC3775]で定義され、それがゼロに設定寿命との定期的な登録解除バインディングアップデートを送信します。バインディング識別子モビリティオプションは必須ではありません。
If a mobile node wants to delete a particular binding(s) from its home agent and correspondent nodes, the mobile node sends a Binding Update with lifetime set to zero and includes a Binding Identifier mobility option(s) with the BID(s) it wants to de-register. The receiver will remove only the care-of address(es) that match(es) the specified BID(s). Since de-registration attempts to remove a BID that already exists, the Care-of Address field in each Binding Identifier option can be omitted by the sender as defined in Section 5.1.
モバイルノードがそのホームエージェントとコレスポンデントノードから（S）特定のバインディングを削除したい場合は、モバイルノードは、ゼロに設定寿命との結合更新を送信し、それをBID（S）との結合識別子モビリティオプション（s）などがあります登録解除したいと考えています。受信機は、気付アドレス（複数可）に一致（ES）指定されたBID（複数可）を削除します。登録解除が既に存在するBIDを除去しようとしているので、セクション5.1で定義されるように、各結合識別子オプションで気付アドレスのフィールドは送信者によって省略することができます。
5.5. Returning Home with Complete Binding De-Registration: Using a Single Interface
5.5. 完全な結合登録解除してホーム戻る：シングルインタフェースの使用
The mobile node may return to the home link by attaching to the home link through one of its interfaces. When the mobile node wants to return home, it should be configured with information on what interface it needs to use.
モバイルノードは、そのインターフェースの1つを介してホームリンクに取り付けることにより、ホームリンクに戻ることができます。モバイルノードが帰宅しようとすると、それが使用するために必要なもののインターフェイスに関する情報を設定する必要があります。
The mobile node returns home and de-registers all the bindings it has with the home agent, as shown in Figure 2 and as defined in [RFC3775]. After the de-registration step, all the packets routed by the home agent are only forwarded to the interface attached to the home link, even if there are other active interfaces attached to the visited link(s). While the mobile node de-registers all the bindings from the home agent, it may continue registering, to the correspondent node, bindings for interfaces attached to visited links as shown in Figure 2.
モバイルノードは、ホーム戻り、解除レジスタ全て図2に示されるように、それは、ホームエージェントにバインディング有すると[RFC3775]で定義されます。登録解除工程後、ホームエージェントによってルーティングされたすべてのパケットは、訪問リンク（単数または複数）に取り付けられた他のアクティブなインタフェースがある場合でも、ホーム・リンクに接続されたインターフェイスに転送されます。モバイルノードのホームエージェントから登録解除すべてのバインディングが、それは、コレスポンデントノードに、図2に示すように、訪問リンクに接続インターフェイスのバインディングを登録し続けることができます。
The mobile node returns home physically but shuts down the interface attached to the home link. As a result, a mobile node does not return home even though it attaches to the home link by one of the interfaces. Before shutting down the interface, any binding for the care-of address previously associated with the interface should be deleted as defined in Section 5.4.
モバイルノードは、物理的に自宅を返しますが、ホームリンクに接続されたインターフェイスをシャットダウンします。その結果、モバイルノードは、それがインタフェースのいずれかにより、ホームリンクにアタッチしていても家に戻りません。セクション5.4で定義されたインターフェイスをシャットダウンする前に、任意のは、以前のインターフェイスに関連付けられている気付アドレスのバインディングを削除する必要があります。
In this scenario, despite the fact that the mobile node is connected to its home link, all of its traffic is sent and received via the home agent and its foreign links.
このシナリオでは、モバイルノードがホームリンクに接続されているという事実にもかかわらず、そのトラフィックのすべては、ホームエージェントとその外国人のリンクを介して送受信されます。
The mobile node returns home and continues using all the interfaces attached to both foreign and home links as shown in Figure 3.
モバイルノードは、ホーム戻り、図3に示すように、外国人及び家庭の両方のリンクに接続されたすべてのインターフェイスを使用して継続します。
In [RFC3775], the home agent intercepts packets meant for the mobile node using proxy Neighbor Discovery [RFC4861] while the mobile node is away from the home link. When the mobile node returns home, the home agent deletes the binding cache and stops proxying for the home address so that a mobile node can configure its home address on the interface attached to the home link. In this specification, a mobile node may return home and configure the home address on the interface attached to the home link, but still use the interfaces attached to the foreign links. In this case, a possible conflict arises when both the home agent and the mobile node try to defend the home address. If the home agent stops proxying for the home address, the packets are always routed to the interface attached to the home link and are never routed to the interfaces attached to the visited links. Deployments making use of multiple care-of addresses are required to avoid configuration conflict between the home agent and the mobile node, while still allowing the simultaneous use of home and foreign links. The following describes the mechanism for achieving this.
[RFC3775]において、ホームエージェントは、モバイルノードが離れてホームリンクからであるパケットは、プロキシ近隣探索[RFC4861]を使用して、モバイルノードのためのものインターセプト。モバイルノードが帰宅すると、ホームエージェントはバインディングキャッシュを削除し、モバイルノードがホームリンクに接続されたインターフェイス上でそのホームアドレスを設定することができるようにホームアドレスのためのプロキシを停止します。本明細書では、モバイルノードが家に帰ると、ホームリンクに接続されたインターフェイス上のホームアドレスを設定するが、それでも外国リンクに接続インターフェースを使用することができます。ホームエージェントとモバイルノードの両方がホームアドレスを守るためにしようとすると、この場合には、可能な競合が発生します。ホームエージェントがホームアドレスのためのプロキシを停止した場合、パケットは、常にホームリンクに接続されたインターフェイスにルーティングされ、訪れたリンクに接続インターフェイスにルーティングされることはありません。まだ家と外国のリンクの同時使用を可能にしながら、複数の気付アドレスを利用しての展開は、ホームエージェントとモバイルノード間の構成の競合を避けるために必要とされます。以下は、これを達成するためのメカニズムについて説明します。
The home agent MUST intercept all the packets meant for the mobile node, whether or not the mobile node is attached to the home link, and decide whether to send the traffic directly to the home address on the link or tunnel to the care-of address.
ホームエージェントは、モバイルノードがホームリンクに接続されているかどうかにかかわらず、モバイルノードのためのもの、すべてのパケットを傍受し、気付アドレスへのリンクまたはトンネル上のホームアドレスに直接トラフィックを送信するかどうかを決定しなければなりません。
Two scenarios are illustrated in Figure 3, depending on whether or not the home agent is the only router at the home link. The difference is on who defends the home address by (Proxy) Neighbor Discovery on the home link.
2つのシナリオは、ホームエージェントはホームリンクで唯一のルータであるか否かに応じて、図3に示されています。違いは、ホームリンク上の（プロキシ）近隣探索によって、ホームアドレスを守る人です。
1. Mobile node defends the home address by the regular Neighbor Discovery protocol (illustrated as topology-a in Figure 3). The home agent is the only router on the home link. Therefore, the home agent is capable of intercepting packets without relying on the proxy Neighbor Discovery protocol, and the mobile node can manage the neighbor cache entry of the home address on the home link as a regular IPv6 node. However, there is one limitation of this scenario. If a correspondent node is located at the home link, the home agent may not intercept the packets destined to the mobile node. These packets are routed only via the home link, but this is the most optimal path for the mobile node to communicate with nodes on the home link.
1.モバイルノードは（図3のトポロジー-Aとして示す）正規近隣探索プロトコルによってホームアドレスを守ります。ホームエージェントはホームリンク上のルータだけです。したがって、ホームエージェントは、プロキシ近隣探索プロトコルに依存せずに、パケットを傍受することができ、移動ノードは、通常のIPv6ノードとしてホームリンク上のホームアドレスの近隣キャッシュエントリを管理することができます。ただし、このシナリオの一つは限界があります。コレスポンデントノードがホームリンクに配置されている場合、ホームエージェントは、モバイルノード宛のパケットを傍受しない場合があります。これらのパケットは、唯一のホームリンクを経由してルーティングされたが、これは、モバイルノードがホームリンク上のノードと通信するための最適なパスでされています。
2. If there are routers other than the home agent on the home link, then it cannot be guaranteed that all packets meant for the mobile node are routed to the home agent. In this case, the mobile node MUST NOT operate the Neighbor Discovery protocol for the home address on the home link. This allows the home agent to keep using proxy Neighbor Discovery, and thus it keeps receiving all the packets sent to the mobile node's home address. If the home agent, according to its local policy, needs to deliver packets to the mobile node over the home link, an issue arises with respect to how the home agent discovers the mobile node's link local address. This specification uses the Mobility Header Link-Layer Address option defined in [RFC5568] in order to carry the mobile node's link-layer address in the Binding Update. Likewise, the mobile node would also know the link-layer address of the default router address to send packets from the home link without Neighbor Discovery. The link-layer address is used to transmit packets from and to the mobile node on the home link. The packets are transmitted without the Neighbor Discovery protocol by constructing the link-layer header manually. This operation is similar to Mobile IPv6 [RFC3775] when a mobile node sends a de-registration Binding Update to the home agent's link-layer address in the operation for returning home.
2.ホームリンク上のホームエージェント以外のルータがある場合、それは、モバイルノードのためのもの、すべてのパケットがホームエージェントにルーティングされることを保証することはできません。この場合、移動ノードは、ホームリンク上のホームアドレスの近隣探索プロトコルを動作させてはなりません。これは、ホームエージェントは、プロキシ近隣探索を使用して維持することができますので、それはモバイルノードのホームアドレスに送信されたすべてのパケットを受信し続けます。ホームエージェントは、そのローカルポリシーに従って、ホームリンクを介して移動ノードにパケットを配信する必要がある場合、問題は、ホームエージェントは、モバイルノードのリンクローカルアドレスを発見する方法に関連して発生します。この仕様は、結合更新で移動ノードのリンク層アドレスを実行するために、[RFC5568]で定義されたモビリティヘッダリンク層アドレスオプションを使用しています。同様に、モバイルノードは、近隣探索せずにホームリンクからパケットを送信するためにデフォルトルータアドレスのリンク層アドレスを知っているだろう。リンク層アドレスは、ホームリンク上の移動ノードからとにパケットを送信するために使用されます。パケットは、手動でリンク層ヘッダを構築することによって近隣探索プロトコルなしで送信されます。この操作は、モバイルノードが帰国のための操作でホームエージェントのリンク層アドレスに登録解除バインディングアップデートを送信モバイルIPv6 [RFC3775]に似ています。
When the home binding is used, the mobile node MUST send a registering Binding Update with a Binding Identifier mobility option with the 'H' flag set. The lifetime MUST be set to a non-zero lifetime of the home binding, and the Care-of Address field MUST be set to the home address. The mobile node registers only one home binding at a time, even if it attaches to the home link by multiple interfaces.
結合ホームを使用する場合は、モバイルノードが「H」フラグが設定されたバインディング識別子モビリティオプションで登録するバインディングアップデートを送らなければなりません。寿命は結合自宅の非ゼロ一生に設定しなければならなくて、気付アドレスフィールドには、ホームアドレスに設定しなければなりません。モバイルノードは、複数のインタフェースによってホーム・リンクに取り付けられていても、一度に結合つのみ自宅を登録します。
The mobile node SHOULD include the Mobility Header Link-Layer Address option [RFC5568] to notify the mobile node's link-layer address to the home agent, too. The option code of the Mobility Header Link-Layer Address option MUST be set to '2' (link-layer address of the mobile node). This link-layer address is required for the home agent to send the Binding Acknowledgement and to forward the mobile node's packet.
モバイルノードは、あまりにも、ホームエージェントにモバイルノードのリンク層アドレスを通知するモビリティヘッダリンク層アドレスオプション[RFC5568]を含むべきです。モビリティヘッダリンク層アドレスオプションのオプションコードは「2」（モバイルノードのリンクレイヤアドレス）に設定しなければなりません。このリンク層アドレスは、バインディング確認を送信するために、モバイルノードのパケットを転送するホームエージェントのために必要とされます。
According to [RFC3775], the mobile node MUST start responding to Neighbor Solicitation for its home address right after it sends the de-registration Binding Update to the home agent. However, in this specification, the mobile node MUST NOT respond to Neighbor Solicitation before receiving a Binding Acknowledgement, since the home agent may continue proxying for the home address. If the mobile node receives [MCOA RETURNHOME WO/NDP (5)] status value in the received Binding Acknowledgment, it MUST NOT respond to Neighbor Solicitation even after the Binding Acknowledgement.
[RFC3775]によれば、移動ノードは、それがホームエージェントに登録解除バインディングアップデートを送信した直後にそのホームアドレスの近隣要請への対応を開始しなければなりません。しかし、この仕様では、モバイルノードは、ホームエージェントがホームアドレスをプロキシする続ける可能性があるため、バインディング確認を受信する前に近隣要請に応じてはいけません。モバイルノードは、受信した結合確認で[MCOA RETURNHOME WO / NDP（5）]のステータス値を受信した場合、それも結合確認した後に近隣要請に応答してはいけません。
The management of the home binding is the same as the binding management described in this specification. The home binding can be included in a bulk binding registration (Section 5.3). The MN SHOULD refresh the lifetime of the home binding by sending appropriate Binding Updates as with any other binding.
家の経営結合は、本明細書に記載されたバインディング管理と同じです。バインディング家は、バルク結合登録（5.3節）に含めることができます。 MNは、他の結合と同じように、適切なバインディングアップデートを送信することにより、結合家の寿命を更新する必要があります。
o When the mobile node receives the Binding Acknowledgement with the status value 'Binding Update Accepted' and the BID option, it can configure its home address to the interface attached to the home link and start operating Neighbor Discovery for the home address on the home link. Packets can be transmitted from and to the mobile node as if the mobile node were a regular IPv6 node.
モバイルノードは、ステータス値「更新受理バインディング」とBIDオプションを使用してバインディング確認応答を受信すると、O、それは、ホームリンクに接続されたインターフェイスにそのホームアドレスを設定し、ホームリンク上のホームアドレスのためのオペレーティング近隣探索を開始することができます。モバイルノードは、通常のIPv6ノードであるかのようにパケットから移動ノードに送信することができます。
o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in the Binding Acknowledgement, it MUST NOT operate Neighbor Discovery for the home address. When the mobile node sends packets from the interface attached to the home link, it MUST learn the link-layer address of the next hop (i.e., default router of the mobile node). A mobile node learns the default router's link-layer address from a Source Link-Layer Address option in Router Advertisements. The mobile node sends packets directly to the default router's link-layer address. This is done by constructing the packet to include a link-layer header with the learned link-layer address of the default router. The home agent also forwards the packet to the mobile node on the home link by using the mobile node's link-layer address. The link-layer address SHOULD be cached when the home agent receives the de-registration Binding Update message. Note that the default router MUST NOT cache the mobile node's link-layer address in the neighbor cache when it forwards the packet from the mobile node to the home agent.
モバイルノードは、ステータスを受信した場合O [MCOA RETURNHOMEは/ NDP WO]結合確認では、ホームアドレスの近隣探索を操作してはなりません。モバイルノードがホームリンクに接続されたインターフェイスからパケットを送信する場合、それは次のホップ（モバイルノードの、すなわち、デフォルトルータ）のリンク層アドレスを学ばなければなりません。モバイルノードは、ルータ広告でソースリンク層アドレスオプションからデフォルトルータのリンク層アドレスを学習します。モバイルノードは、デフォルトルータのリンク層アドレスに直接パケットを送信します。これは、デフォルトルータの学びリンク層アドレスとリンク層ヘッダを含めるために、パケットを構成することによって行われます。ホームエージェントは、モバイルノードのリンク層アドレスを使用してホームリンク上のモバイルノードにパケットを転送します。ホームエージェントは、登録解除Binding Updateメッセージを受信したときに、リンク層アドレスがキャッシュされるべき。それは、モバイルノードからホームエージェントにパケットを転送するときに、デフォルトのルータは近隣キャッシュ内の移動ノードのリンクレイヤアドレスをキャッシュしてはならないことに注意してください。
When the mobile node detaches from the home link, it SHOULD immediately send a Binding Update for one of the active care-of addresses with the 'H' flag unset. When the 'H' flag of the BID option is unset in any Binding Update, the home agent stops forwarding the mobile node's packets to the home link.
モバイルノードがホームリンクから離脱するとき、それはすぐに解除「H」フラグ付きのアクティブ気付アドレスのいずれかのバインディングアップデートを送信すべきです。 BIDオプションの「H」フラグは任意のバインディングアップデートで設定されていない場合は、ホームエージェントはホームリンクにモバイルノードのパケットの転送を停止します。
The verification of a Binding Acknowledgement is the same as Mobile IPv6 (Section 11.7.3 of [RFC3775]). The operation for sending a Binding Acknowledgement is described in Section 6.2.
結合確認の検証は、モバイルIPv6（[RFC3775]のセクション11.7.3）と同じです。バインディング肯定応答を送信するための操作は、セクション6.2に記載されています。
If a mobile node includes a Binding Identifier mobility option in a Binding Update with the 'A' flag set, a Binding Acknowledgement SHOULD carry a Binding Identifier mobility option. According to [RFC3775], the receiver of the Binding Update ignores unknown mobility options and processes the Binding Update without the unknown mobility option. Therefore, if no such mobility option is included in the Binding Acknowledgement in response to a Binding Update for a multiple care-of addresses registration, this indicates that the originating node of the Binding Acknowledgement does not support processing the Binding Identifier mobility option regardless of status value. In such case, the receiver of the Binding Update may create a regular binding. The mobile node then SHOULD no longer attempt a multiple care-of addresses registration with that node. If this occurs with home registration, the mobile node MAY attempt to discover another home agent that supports the Binding Identifier mobility option for the home registration.
モバイルノードは、 'フラグが設定されたバインディング更新中の結合識別子モビリティオプションが含まれている場合、結合確認は、結合識別子モビリティオプションを運ぶべきです。 [RFC3775]によると、バインディングアップデートの受信機は、未知のモビリティオプションを無視して、未知のモビリティ・オプションを使用せずにバインディング更新を処理します。そのようなモビリティオプションは、複数の気付アドレスの登録のための結合更新に応答して、結合確認に含まれていない場合したがって、これは、結合確認の発信ノードに関わらずステータスの結合識別子モビリティオプションを処理するサポートしていないことを示しています値。このような場合には、バインディング更新の受信機は、定期的な結合を作成することができます。モバイルノードは、もはやそのノードで複数の気付けアドレスの登録を試みるべきではありません。これはホーム登録で発生した場合、モバイルノードは、ホーム登録のためのバインディング識別子モビリティオプションをサポートする別のホームエージェントを発見しようとすることができます。
If a Binding Identifier mobility option is present in the received Binding Acknowledgement, the mobile node checks the Status field in the option. If the status value in the Binding Identifier mobility option is zero, the mobile node uses the value in the Status field of the Binding Acknowledgement. Otherwise, it uses the value in the Status field of the Binding Identifier mobility option.
バインディング識別子モビリティオプションが受信されたバインディング受信確認中に存在している場合、モバイルノードは、オプションで、Statusフィールドをチェックします。バインディング識別子モビリティオプションのステータス値がゼロの場合、モバイルノードは、結合確認のステータスフィールドの値を使用しています。それ以外の場合は、バインディング識別子モビリティオプションのステータスフィールドの値を使用しています。
If the status code is greater than or equal to 128, the mobile node starts relevant operations according to the error code. Otherwise, the mobile node assumes that the originator (home agent or correspondent node) successfully registered the binding information and BID for the mobile node.
ステータスコードが128以上である場合、移動ノードは、エラーコードに応じて、関連する動作を開始します。それ以外の場合は、モバイルノードは、発信元（ホームエージェントやコレスポンデントノード）が正常にモバイルノードのバインディング情報とBIDを登録することを前提としています。
o If the status value is [MCOA PROHIBITED], the mobile node MUST stop registering multiple bindings with the node that sent the Binding Acknowledgement.
ステータス値がある場合、O [MCOA禁止]は、モバイル・ノードは、バインディング肯定応答を送信したノードと複数のバインディングの登録を停止しなければなりません。
o If the status value is [MCOA BULK REGISTRATION PROHIBITED], the mobile node needs to stop using bulk registrations with the node that sent the Binding Acknowledgement. It should assume that none of the attempted registrations were successful.
ステータス値は[MCOAバルク登録しない]の場合、O、モバイルノードは、バインディング受信確認を送信したノードとバルクレジストレーションの使用を停止する必要があります。それは未遂登録のどれも成功しなかったと仮定しなければなりません。
o If [MCOA MALFORMED] is specified, it indicates that the Binding Identifier mobility option is formatted wrong, presumably due to a programming error or major packet corruption.
[MCOA MALFORMED]が指定されている場合は、O、それはバインディング識別子モビリティオプションは、おそらくプログラミングエラーまたは主要なパケットの破損に、間違ってフォーマットされていることを示しています。
o If [MCOA NON-MCOA BINDING EXISTS] is specified, it means that there is a non-MCoA binding entry in the receiver. The mobile node MUST set 'O' flag so that all the registered bindings are replaced by an MCoA registration as described in Section 5.9.
[MCOA NON-MCOA BINDING EXISTS]が指定されている場合は、O、それは、受信機における非MCoAバインディングエントリがあることを意味します。モバイルノードは、セクション5.9で説明したように、すべての登録されたバインディングがMCoA登録によって置換されているように「O」フラグを設定しなければなりません。
o If [MCOA UNKNOWN COA] is specified, it means that the mobile node sent a Binding Identifier mobility option without a Care-of Address field, but the receiver could not find an entry for the BID indicated. If the mobile node is trying to de-register a BID, it need not do anything further. If the mobile node is trying to refresh a binding, it SHOULD send a Binding Identifier mobility option including the Care-of Address field.
【MCOA UNKNOWN COA]が指定されている場合は、O、それはモバイルノードが気付アドレスのフィールドなしで結合識別子モビリティオプションを送信するが、受信機が示されているBIDのエントリを見つけることができなかったことを意味します。モバイルノードがBIDを登録解除しようとしている場合、それはさらに何もする必要はありません。モバイルノードがバインディングをリフレッシュしようとしている場合は、気付アドレスフィールドを含むバインディング識別子モビリティオプションを送るべきです。
The verification of a Binding Refresh Request is the same as in Mobile IPv6 (Section 11.7.4 of [RFC3775]). The operation of sending a Binding Refresh Request is described in Section 6.4.
バインディングリフレッシュ要求の検証は、モバイルIPv6（[RFC3775]のセクション11.7.4）と同じです。結合更新要求を送信する動作は6.4節に記述されています。
If a mobile node receives a Binding Refresh Request with a Binding Identifier mobility option, it indicates that the node sending the Binding Refresh Request message is requesting that the mobile node send a new Binding Update for the BID. The mobile node SHOULD then send a Binding Update at least for the respective binding, as described in Sections 5.2 and 5.3.
モバイルノードは、バインディングの識別子モビリティオプションと結合更新要求を受信した場合には、ノードが結合更新要求メッセージは、移動ノードがBIDのための新たなバインディングアップデートを送信することを要求して送信することを示しています。セクション5.2および5.3に記載されているように、モバイルノードは、それぞれの結合のための少なくともバインディング更新を送信するべきです。
When a mobile node bootstraps and registers multiple bindings for the first time, it MUST set the 'O' flag in the Binding Update message. If old bindings still exist at the home agent, the mobile node has no knowledge of which bindings still exist at the home agent. This scenario happens when a mobile node reboots and loses state regarding the registrations. If the 'O' flag is set, all the bindings are replaced by the new binding(s).
モバイルノードのブートストラップとが初めて複数のバインディングを登録する際には、Binding Updateメッセージで「O」フラグを設定しなければなりません。古いバインディングはまだホームエージェントに存在する場合は、モバイルノードは、バインディングがまだホームエージェントに存在しているの知識を持ちません。モバイルノードが再起動し、登録に関する状態を失うと、このシナリオは起こります。 「O」フラグが設定されている場合は、すべてのバインディング（s）は新しいバインディングに置き換えられます。
If either a correspondent node or a home agent has multiple bindings for a mobile node in their binding cache database, it can use any of the bindings to communicate with the mobile node. This section explains how to retrieve the desired binding for the binding management. This document does not provide any mechanism to select the suitable binding for forwarding data packets.
コレスポンデントノードまたはホームエージェントのいずれかが、それらの結合キャッシュデータベース内の移動ノードに対して複数のバインディングを持っている場合、それはモバイルノードと通信するためのバインディングのいずれかを使用することができます。このセクションでは、所望の結合管理のためのバインディングを取得する方法について説明します。このドキュメントでは、データパケットを転送するための適切な結合を選択するための任意のメカニズムを提供しません。
A node that is either a correspondent node or a home agent SHOULD use both the home address and the BID as the search key of the binding cache if it knows the corresponding BID (for example, when processing signaling messages). In the example below, if a node searches the binding with the home address and BID2, it gets binding2 for this mobile node.
それは（シグナリングメッセージを処理例えば、）対応するBIDを知っている場合は、通信相手ノードまたはホームエージェントのいずれかであるノードは、バインディングキャッシュの検索キーとしてホームアドレスとBIDの両方を使用すべきです。ノードが検索した場合、以下の例では、ホームアドレスとBID2との結合は、このモバイルノードのためbinding2を取得します。
binding1 [2001:db8::EUI, care-of address1, BID1]
binding2 [2001:db8::EUI, care-of address2, BID2]
binding3 [2001:db8::EUI, care-of address3, BID3]
Figure 8: Searching the Binding Cache
図8：バインディングキャッシュを検索
The node learns the BID when it receives a Binding Identifier mobility option. At that time, the node MUST look up its binding cache database with the home address and the BID retrieved from the Binding Update. If the node does not know the BID, it searches for a binding with only the home address. In such a case, the first matched binding is found. If the node does not desire to use multiple bindings for a mobile node, it can simply ignore the BID.
それはバインディング識別子モビリティオプションを受信したときにノードがBIDを学習します。その時、ノードはホームアドレスとバインディング・アップデートから取得したBIDとその結合キャッシュデータベースをルックアップする必要があります。ノードはBIDを知らない場合は、それが唯一のホームアドレスとの結合を検索します。このような場合には、最初に一致した結合が見出されます。ノードは、移動ノードに対して複数のバインディングを使用することを希望しない場合は、それは単にBIDを無視することができます。
If a Binding Update does not contain a Binding Identifier mobility option, its processing is the same as in [RFC3775]. If the receiver already has multiple bindings for the home address, it MUST replace all the existing bindings with the received binding. If the [RFC3775] Binding Update is for de-registration, the receiver MUST delete all existing bindings from its binding cache.
バインディングアップデートバインディング識別子モビリティオプションが含まれていない場合、その処理は[RFC3775]と同じです。受信機はすでにホームアドレスに対して複数のバインディングを持っている場合は、受信した結合を持つすべての既存のバインディングを交換する必要があります。 [RFC3775]バインディングアップデートは、登録解除のためのものである場合、受信機は、その結合キャッシュからすべての既存のバインディングを削除しなければなりません。
If the Binding Update contains Binding Identifier mobility option(s), it is first validated according to Section 9.5.1 of [RFC3775]. Then the receiver processes the Binding Identifier mobility option(s) as described in the following steps.
結合更新は、バインディング識別子モビリティオプション（複数可）が含まれている場合、それは最初の[RFC3775]のセクション9.5.1に従って検証されます。次いで、受信機は、以下のステップで説明したようにバインディング識別子モビリティオプション（複数可）を処理します。
o The length value is examined. The length value MUST be either 4, 8, or 20 depending on the Care-of Address field. If the length is incorrect, the receiver MUST reject the Binding Update and return the status value set to [MCOA MALFORMED].
O長さの値が調べられます。長さ値は、気付アドレスフィールドに応じて、4,8、または20のいずれかでなければなりません。長さが正しくない場合、受信機は、結合更新を拒絶し、[MCOA MALFORMED]に設定された状態値を返さなければなりません。
o When the length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the unicast routable address [RFC3775] is not present in the Care-of Address field, the receiver MUST reject the Binding Identifier mobility option and return the status value set to [MCOA MALFORMED].
長さの値は、8または20のいずれかである場合、O、気付アドレスは、結合識別子モビリティオプションに存在しなければなりません。ユニキャストルーティング可能なアドレス[RFC3775]は気付アドレスのフィールドに存在しない場合、受信機は、バインディング識別子モビリティオプションを拒否し、[MCOA MALFORMED]に設定された状態値を返さなければなりません。
o When multiple Binding Identifier mobility options are present in the Binding Update, it is treated as bulk registration. If the receiving node is a correspondent node, it MUST reject the Binding Update and return the status value set to [MCOA BULK REGISTRATION PROHIBITED] in the binding Acknowledgement.
複数の結合識別子モビリティオプションは、バインディング更新中に存在する場合、O、それは、バルク登録として扱われます。受信ノードは、コレスポンデントノードである場合、それはバインディング更新を拒否し、バインディング確認の[MCOAバルク登録しない]に設定された状態値を返さなければなりません。
o If the Lifetime field in the Binding Update is set to zero, the receiving node deletes the binding entry that corresponds to the BID in the Binding Identifier mobility option. If the receiving node does not have an appropriate binding for the BID, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 133 [not home agent for this mobile node].
バインディングアップデートで寿命フィールドはゼロに設定されている場合は、O、受信ノードは、バインディング識別子モビリティオプションでBIDに対応するバインディングエントリを削除します。受信ノードがBIDバインディング適切れていない場合、それが結合更新を拒絶して[このモバイルノードのためではないホームエージェント] 133に設定された状態との結合肯定応答を送信しなければなりません。
o If the 'O' flag is set in the de-registering Binding Update, it is ignored. If the 'H' flag is set, the home agent stores a home address in the Care-of Address field of the binding cache entry. The home agent MUST follow the descriptions described in Section 5.6.
「O」フラグが登録解除の結合更新に設定されている場合は、O、それは無視されます。 「H」フラグが設定されている場合は、ホームエージェントはバインディングキャッシュエントリの気付アドレスフィールド内のホームアドレスを格納します。ホームエージェントは、5.6節で説明した記述に従わなければなりません。
o If the Lifetime field is not set to zero, the receiving node registers a binding with the specified BID as a mobile node's binding. The care-of address is obtained from the Binding Update packet as follows:
寿命フィールドはゼロに設定されていない場合はO、受信ノードは、モバイルノードのバインディングとして指定されたBIDとの結合を登録します。次のように気付アドレスがバインディング更新パケットから取得されます。
* If the length value of the Binding Identifier mobility option is 20, the care-of address is the IPv6 address copied from the Care-of Address field in the Binding Identifier mobility option.
バインディング識別子モビリティオプションの長さの値が20の場合は*、気付アドレスがバインディング識別子モビリティオプションで気付アドレスフィールドからコピーされたIPv6アドレスです。
* When the length value is 8, the address MUST be the IPv4 valid address. How to obtain an IPv4 care-of address is described in Section 8.
*長さの値が8である場合、アドレスは、IPv4有効なアドレスでなければなりません。どのようにのIPv4気付アドレスを取得することは、セクション8に記載されています。
* When the length value is 4 and the Binding Identifier is present in the binding cache, the receiving node MUST update the associated binding entry. Otherwise, the receiving node MUST reject that Binding Identifier mobility option and send a Binding Acknowledgement with the status for that Binding Identifier mobility option set to [MCOA UNKNOWN].
*長さの値は4であり、結合識別子は、バインディング・キャッシュに存在する場合、受信ノードは、関連するバインディングエントリを更新しなければなりません。そうでない場合、受信ノードは、識別子、モビリティオプション結合とする[MCOA UNKNOWN]に設定され、その結合識別子モビリティオプションのステータスとの結合肯定応答を送信することを拒絶しなければなりません。
o Once the care-of address(es) have been retrieved from the Binding Update, the receiving nodes create new binding(s).
気付アドレス（複数可）はバインディング更新から取得したらO、受信ノードは、（複数の）新しいバインディングを作成します。
* If the 'O' flag is set in the Binding Update, the receiving node removes all the existing bindings and registers the received binding(s).
「O」フラグが結合更新に設定されている場合*、受信ノードは、すべての既存のバインディングを削除し、受信された（複数の）バインディングを登録します。
* If the 'O' flag is unset in the Binding Update and the receiver has a regular binding that does not have a BID for the mobile node, it must not process the Binding Update. The receiver should send a Binding Acknowledgement with status set to [MCOA NON-MCOA BINDING EXISTS].
*「O」フラグが結合更新に設定されていないと、受信機は、移動ノードのBIDを有していないことを定期的に結合されている場合、それはバインディング更新を処理してはなりません。受信機は、[MCOA NON-MCOA結合はEXISTS]に設定された状態で結合確認を送信すべきです。
* If the receiver already has a binding with the same BID but different care-of address, it MUST update the binding and respond with a Binding Acknowledgement with status set to 0 [Binding Update accepted].
*受信機がすでに同じBIDとの結合が異なる気付アドレスを持っている場合は、それが結合を更新し、0に設定された状態との結合を確認応答で応じなければなりません[バインディング更新は受け入れ]。
* If the receiver does not have a binding entry for the BID, it registers a new binding for the BID and responds with a Binding Acknowledgement with status set to 0 [Binding Update accepted].
*受信機は、BIDのためのバインディングエントリを持っていない場合、それはBIDのために新しいバインディングを登録し、0に設定された状態との結合を確認応答で応答[バインディング更新は受け入れ]。
If all the above operations are successfully completed and the 'A' flag is set in the Binding Update, a Binding Acknowledgement containing the Binding Identifier mobility options MUST be sent to the mobile node. Whenever a Binding Acknowledgement is sent, all the Binding Identifier mobility options stored in the Binding Update MUST be copied to the Binding Acknowledgement except the Status field. The Care-of Address field in each Binding Identifier mobility option, however, MAY be omitted, because the mobile node can match a corresponding Binding Update List entry using the BID.
上記のすべての操作が正常に完了している場合と「」フラグが結合更新に設定されている、結合識別子モビリティオプションを含むバインディング受信確認は、モバイルノードに送信されなければなりません。バインディング確認が送信されるたびに、バインディングアップデートに保存されているすべてのバインディング識別子モビリティオプションは、Statusフィールドを除くバインディング確認にコピーする必要があります。モバイルノードがBIDを使用して、対応するバインディング更新リストエントリを一致させることができますので、気付アドレスフィールド各バインディング識別子モビリティオプションでは、しかし、省略されるかもしれません。
When a correspondent node sends a Binding Acknowledgement, the status value MUST always be stored in the Status field of the Binding Acknowledgement and the Status field of the Binding Identifier mobility option MUST always be set to zero.
通信相手ノードは、バインディング肯定応答を送信するとき、状態値は常に結合確認のStatusフィールドに格納されなければならないとバインディング識別子モビリティオプションのStatusフィールドは常にゼロに設定しなければなりません。
When the home agent sends a Binding Acknowledgement, the status value can be stored in the Status field of either a Binding Acknowledgement or a Binding Identifier mobility option. If the status value is specific to one of the bindings in the bulk registration, the status value MUST be stored in the Status field in the corresponding Binding Identifier mobility option. In this case, the Status field of the Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that the receiver can examine the Status field of each Binding Identifier mobility option for further operations. Otherwise, the Status field of the Binding Identifier mobility option MUST be set to zero and the home agent Status field of the Binding Acknowledgement is used.
ホームエージェントはバインディング確認を送信すると、ステータス値は、バインディング確認または結合識別子モビリティオプションのいずれかのステータスフィールドに格納することができます。ステータス値は、バルク登録におけるバインディングのいずれかに特異的である場合、ステータス値が、対応するバインディング識別子モビリティオプションでStatusフィールドに格納されなければなりません。受信機はさらに操作の各結合識別子モビリティオプションのStatusフィールドを調べることができるように、この場合には、結合確認のステータスフィールドは、[MCOA NOTCOMPLETE]に設定しなければなりません。それ以外の場合は、バインディング識別子モビリティオプションのStatusフィールドはゼロに設定しなければならなくて、結合確認のホームエージェントのステータスフィールドが使用されています。
The operations described in this section are related to returning home with simultaneous use of home and foreign links.
このセクションで説明する操作は、家庭と外国のリンクを同時に使用して帰国に関連しています。
o When the home agent sends the Binding Acknowledgement after successfully processing the home binding registration, it MUST set the status value to either 0 [Binding Update Accepted] or [MCOA RETURNHOME WO/NDP (5)] in the Status field of the Binding Acknowledgment, depending on home agent configuration at the home link. The new values are:
ホーム・エージェントが正常家バインディング登録を処理した後にバインディング確認を送信する場合、O、それに状態値を設定する必要があり、0 [バインディング更新承認]または[MCOA RETURNHOME WO / NDP（5）]結合確認のStatusフィールドに、ホームリンクでホームエージェントの構成に応じて。新しい値は次のとおりです。
* Binding Update Accepted (0): The Neighbor Discovery protocol is permitted for the home address at the home link. This is the regular returning home operation of [RFC3775].
*バインディングアップデート認められたが（0）：近隣探索プロトコルは、ホームリンクのホームアドレスのために許可されています。これは、[RFC3775]の定期戻っホーム操作です。
* MCOA RETURNHOME WO/NDP (5): The Neighbor Discovery protocol is prohibited for the home address at the home link.
* MCOA RETURNHOMEはWO / NDPは（5）：近隣探索プロトコルは、ホームリンクのホームアドレスのために禁止されています。
The respective Binding Identifier mobility options need to be included in the Binding Acknowledgement.
それぞれの結合識別子モビリティオプションは結合確認に含まれる必要があります。
o If the Binding Update is rejected, the appropriate error value MUST be set in the Status field. In this case, the home agent operation is the same as in [RFC3775].
バインディング更新が拒否された場合、O、適切なエラー値は、Statusフィールドに設定しなければなりません。この場合、ホームエージェント操作は[RFC3775]と同じです。
o Only if the home agent is the only router in the home link MAY it turn off Neighbor Discovery for the requested home address and respond with the [Binding Update Accepted] status value to the mobile node. Since the mobile node will not reply to Neighbor Solicitation for the home address before receiving the Binding Acknowledgement, the home agent SHOULD use the link-layer address carried by the Mobility Header Link-Layer Address option [RFC5568] in the received Binding Update. After the completion of the home binding registration, the mobile node starts regular Neighbor Discovery operations for the home address on the home link. The neighbor cache entry for the home address is created by the regular exchange of Neighbor Solicitation and Neighbor Advertisement.
Oホームエージェントはホームリンクで唯一のルータは、それが要求されたホームアドレスのために近隣探索をオフにして、モバイルノードに[バインディング更新可】ステータス値で応答することができる場合のみ。移動ノードが結合確認を受信する前に自宅の住所のための近隣要請に返答しませんので、ホームエージェントが受信バインディングアップデートにモビリティヘッダリンク層アドレスオプション[RFC5568]で運ばリンク層アドレスを使用する必要があります。ホームバインディング登録の完了後、モバイルノードは、ホームリンク上のホームアドレスのために定期的な近隣探索操作を開始します。ホームアドレスのための近隣キャッシュエントリは、近隣要請と近隣広告の定期的な交換によって作成されます。
o If the home agent is not the only router in the home link, the home agent returns [MCOA RETURNHOME WO/NDP] value in the Status field of the Binding Identifier mobility option. The home agent learns the mobile node's link-layer address by receiving the Mobility Header Link-Layer Address option carried by the Binding Update. It stores the link-layer address as a neighbor cache entry for the mobile node so that it can send the packets to the mobile node's link-layer address.
ホーム・エージェントはホームリンクで唯一のルータでない場合は、O、ホームエージェントはバインディング識別子モビリティオプションのStatusフィールドに[MCOA RETURNHOME WO / NDP]の値を返します。ホームエージェントはバインディングアップデートによって運ばれるモビリティヘッダリンク層アドレスオプションを受信することによって、移動ノードのリンク層アドレスを学習します。それは、モバイルノードのリンク層アドレスにパケットを送信できるように、モバイルノードのための近隣キャッシュエントリとしてリンク層アドレスを格納します。
o Note that the use of proxy Neighbor Discovery is an easier way to intercept the mobile nodes' packets instead of IP routing in some deployment scenarios. Therefore, even if a home agent is the only router, it is an implementation and operational choice whether the home agent returns [Binding Update Accepted] or [MCOA RETURNHOME WO/NDP].
Oプロキシ近隣探索の使用は、いくつかの展開シナリオでは、モバイルノードのパケットの代わりに、IPルーティングを傍受する簡単な方法であることに注意してください。したがって、ホームエージェントは、ルータだけであっても、実装と運用のホームエージェントは、[更新受理バインディング]返すかどうかを選択または[MCOA RETURNHOME WO / NDP]はあります。
o If the BID option is not included in the Binding Acknowledgement, the home agent might not recognize the home registration. The home agent might have processed the home registration Binding Update as a regular de-registration, as described in [RFC3775], and deleted all the registered binding cache entries for the mobile node. Thus, the mobile node SHOULD stop using the interface attached to the foreign link and use only the interface attached to the home link.
BIDオプションは結合確認に含まれていない場合は、O、ホームエージェントは、ホーム登録を認識しない場合があります。ホームエージェントは、[RFC3775]で説明したように、定期的に登録解除と更新をバインディングホーム登録を処理し、移動ノードのために登録されているすべてのバインディングキャッシュエントリを削除している場合があります。このように、モバイルノードが外部リンクに接続されたインターフェイスの使用を停止し、ホームリンクに接続インタフェースのみを使用すべきです。
When a node (home agent or correspondent node) sends a Binding Refresh Request for a particular binding created with the BID, the node SHOULD include the Binding Identifier mobility option in the Binding Refresh Request. The node MAY include multiple Binding Identifier mobility options if there are multiple bindings that need to be refreshed.
ノード（ホームエージェントやコレスポンデントノード）はBIDで作成したバインディングの特定のための結合更新要求を送信すると、ノードが結合更新要求でバインディング識別子モビリティオプションを含めるべきです。リフレッシュする必要が複数のバインディングがある場合、ノードは、複数の結合識別子モビリティオプションを含むかもしれません。
When a node receives packets with a Home Address destination option from a mobile node, it MUST check that the care-of address that appears in the Source Address field of the IPv6 header is equal to one of the care-of addresses in the binding cache entry. If no binding is found, the packets MUST be discarded. The node MUST also send a Binding Error message as specified in [RFC3775]. This verification MUST NOT be done for a Binding Update.
ノードは、移動ノードからホームアドレス宛先オプションでパケットを受信すると、気付アドレスIPv6ヘッダの送信元アドレスフィールドに表示されるバインディングキャッシュに気付アドレスのいずれかに等しいことをチェックしなければなりませんエントリ。何の結合が検出されない場合、パケットは捨てなければなりません。ノードは、[RFC3775]で指定されるように結合エラーメッセージを送らなければなりません。この検証は、バインディングアップデートのために行われてはなりません。
The binding management mechanisms are the same for a mobile host that uses Mobile IPv6 and for a mobile router that is using the NEMO Basic Support protocol [RFC3963]. Therefore, the extensions described in this document can also be used to support a mobile router with multiple care-of addresses. [RFC4980] contains an analysis of NEMO multihoming.
バインディング管理メカニズムは、モバイルIPv6を使用し、NEMOベーシックサポートプロトコル[RFC3963]を使用しているモバイルルータのモバイルホストのために同じです。したがって、この文献に記載の拡張機能は、複数の気付アドレスでモバイルルータをサポートするために使用することができます。 [RFC4980]はNEMOのマルチホーミングの分析を含んでいます。
Dual Stack Mobile IPv6 (DSMIPv6) [RFC5555] extends Mobile IPv6 to register an IPv4 care-of address instead of the IPv6 care-of address when the mobile node is attached to an IPv4-only access network. It also allows the mobile node to acquire an IPv4 home address in addition to an IPv6 home address for use with IPv4-only correspondent nodes. This section describes how the multiple care-of addresses registration works with IPv4 care-of and home addresses.
デュアルスタックモバイルIPv6（DSMIPv6）[RFC5555]は移動ノードがIPv4のみのアクセスネットワークに接続されたときにモバイルIPv6は、IPv6気付アドレスの代わりのIPv4気付アドレスを登録するために延びています。また、移動ノードがIPv4のみのコレスポンデントノードとの使用のためのIPv6ホームアドレスに加えたIPv4ホームアドレスを取得することを可能にします。このセクションでは、複数の気付アドレスの登録は、IPv4気付とホームアドレスとどのように機能するかについて説明します。
The mobile node can use the extensions described in the document to register multiple care-of addresses, even if some of the care-of addresses are IPv4 addresses.
モバイルノードが気付アドレスの一部は、IPv4アドレスであっても、複数の気付アドレスを登録するために文書で説明した拡張機能を使用することができます。
Bulk registration MUST NOT be used for the initial binding registration from an IPv4 care-of address. This is because the Binding Update and Binding Acknowledgement exchange is used to detect NAT on the path between the mobile node and the home agent. So the mobile node needs to check for a NAT between each IPv4 care-of address and the home agent.
一括登録は、IPv4気付アドレスからの最初の結合の登録のために使用してはいけません。バインディング更新と結合確認交換は、モバイルノードとホームエージェントとの間のパス上でNATを検出するために使用されているためです。だから、モバイルノードは、アドレスごとのIPv4の介護とホームエージェント間のNATをチェックする必要があります。
The Binding Update MUST be sent to the IPv4 home agent address by using UDP and IPv4 headers as shown in Figure 9. It is similar to [RFC5555] except that the IPv4 care-of address option MUST NOT be used when the BID mobility option is used.
図9に示すように、バインディングアップデートは、それがIPv4気付アドレスのオプションがBIDのモビリティオプションがあるときに使用してはならないことを除いて、[RFC5555]に似ているUDPとIPv4ヘッダーを使用することで、IPv4ホームエージェントアドレスに送らなければなりません中古。
IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
UDP Header
IPv6 header (src=V6HoA, dst=HAADDR)
ESP Header
Mobility header
-Binding Update
Mobility Options
- Binding Identifier (IPv4 CoA)
*V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [RFC5555]
Figure 9: Initial Binding Update for IPv4 Care-of Address
図9：IPv4の気付アドレスの初期バインディングアップデート
If a NAT is not detected, the mobile node can update the IPv4 care-of address by using bulk registration. The mobile node can register the IPv4 care-of address along with other IPv4 and IPv6 care-of addresses. Figure 10 shows the Binding Update format when the mobile node sends a Binding Update from one of its IPv6 care-of addresses. If the mobile node sends a Binding Update from an IPv4 care-of address, it MUST follow the format described in Figure 9. Note that the IPv4 care-of address must be registered by a non-bulk binding registration whenever it is changed.
NATが検出されない場合、モバイルノードが一括登録を使用してのIPv4気付アドレスを更新することができます。モバイルノードは、他のIPv4およびIPv6気付アドレスと一緒のIPv4気付アドレスを登録することができます。モバイルノードは、そのIPv6アドレスの気付の一つから結合更新を送信する場合図10は、結合更新のフォーマットを示します。移動ノードがIPv4気付アドレスのバインディング更新を送信する場合、それが変更されるたびのIPv4気付アドレスが非バルクバインディング登録によって登録されなければならないことを図9ノートに記載形式に従わなければなりません。
As shown in Figure 9, the IPv4 care-of address will appear in the Binding Identifier mobility option. The IPv4 Care-of Address mobility option defined in [RFC5555] MUST always be omitted. The receiver of the Binding Update message for an IPv4 care-of address
図9に示すように、のIPv4気付アドレスのバインディング識別子モビリティオプションに表示されます。 [RFC5555]で定義されたIPv4気付アドレスモビリティオプションは常に省略しなければなりません。 IPv4気付アドレスのバインディング更新メッセージの受信
MUST treat the IPv4 address stored in the Binding Identifier mobility option as the one in the IPv4 Care-of Address mobility option of [RFC5555]. If the IPv4 address in the Binding Identifier mobility option is different from one in the Source Address field in the IPv4 header of the Binding Update (i.e., V4ADDR in Figure 9), the source address is used as an IPv4 care-of address. Otherwise, the IPv4 address in the Binding Identifier mobility option is used as an IPv4 care-of address.
[RFC5555]のIPv4の気付アドレスモビリティオプション内の1つのような結合識別子モビリティオプションに保存されているIPv4アドレスを扱わなければなりません。バインディング識別子モビリティオプションでIPv4アドレスがバインディング更新のIPv4ヘッダのソースアドレスフィールドで一つから異なる場合（すなわち、図9のV4ADDR）、送信元アドレスは、IPv4気付アドレスとして使用されます。そうでなければ、バインディング識別子モビリティオプションでIPv4アドレスは、IPv4気付アドレスとして使用されます。
IPv6 header (src=Care-of Address, dst=Home Agent Address)
IPv6 Home Address Option
ESP Header
Mobility header
-Binding Update
Mobility Options
- Binding Identifier (IPv6/v4 CoA)
- Binding Identifier (IPv6/v4 CoA)
- ...
Figure 10: Binding Bulk Registration for an IPv4 Care-of Address
図10：IPv4の気付アドレスのバインディング一括登録
When the home agent returns a Binding Acknowledgement for the IPv4 care-of address registration, it SHOULD NOT use the IPv4 Address Acknowledgement mobility option and SHOULD use only the Binding Identifier mobility option. The registration status for the IPv4 care-of address is stored in the Status field of the Binding Identifier mobility option. However, if the home agent needs to store the status value specially defined for the IPv4 Address Acknowledgement mobility option, it MUST store the status value in the IPv4 Address Acknowledgement mobility option and MUST NOT store it in the Binding Identifier mobility option. In such case, the home agent MUST include both the IPv4 Address Acknowledgement mobility option and the Binding Identifier mobility option.
ホームエージェントは、IPv4気付アドレスを登録するためのバインディング確認応答を返すと、それは、IPv4アドレスの受け付けモビリティオプションを使用すべきではなく、唯一のバインディング識別子モビリティ・オプションを使用する必要があります。気付アドレスのIPv4の登録状況は、バインディング識別子モビリティオプションのStatusフィールドに格納されます。ホームエージェントは、特別のIPv4アドレスの受け付けモビリティオプション用に定義されたステータス値を格納する必要がある場合しかし、それは、IPv4アドレスの受け付けモビリティオプションのステータス値を保存しなければなりませんし、バインディング識別子モビリティオプションに保管してはなりません。そのような場合には、ホームエージェントは、IPv4アドレスの確認応答モビリティオプションとバインディング識別子モビリティオプションの両方を含まなければなりません。
When the mobile node wants to configure an IPv4 home address in addition to the IPv6 home address, it can request one using the IPv4 Home Address option in the Binding Update. If the home agent accepts the Binding Update, the mobile node can now register multiple care-of addresses for the IPv4 home address in addition to the IPv6 home address. The mobile node MUST always use the IPv4 Home Address mobility option for any purposes of the IPv4 home address management. The same set of care-of addresses will be registered for both IPv6 and IPv4 home addresses. The mobile node cannot bind a different set of care-of addresses to each home address.
モバイルノードがIPv6ホームアドレスに加えて、IPv4のホームアドレスを設定したい場合は、バインディング更新中のIPv4ホームアドレスオプションを使用して1を要求することができます。ホームエージェントはバインディングアップデートを受け入れる場合、モバイルノードは現在のIPv6ホームアドレスに加えて、IPv4のホームアドレスに対して複数の気付アドレスを登録することができます。モバイルノードは、常にIPv4のホームアドレス管理のいずれかの目的のためのIPv4ホームアドレスモビリティオプションを使用しなければなりません。気付アドレスの同じセットは、IPv6とIPv4のホームアドレスの両方に登録されます。モバイルノードは、それぞれのホームアドレスに気付アドレスの異なるセットをバインドすることはできません。
According to [RFC5555], the home agent includes the IPv4 Address Acknowledgement option in the Binding Acknowledgement only if the mobile node had requested an IPv4 home address in the corresponding Binding Update. The IPv4 Address Acknowledgement option MUST be present before any Binding Identifier mobility option. The Status field of the IPv4 Address Acknowledgement option contains only the error code defined in Section 3.2.1 of [RFC5555]. The home agent MUST always include the IPv4 Address Acknowledgement mobility option in the Binding Acknowledgement for the IPv4 home address registration.
[RFC5555]によると、ホームエージェントは、モバイルノードが、対応するバインディング更新中のIPv4ホームアドレスを要求した場合にのみ、結合確認でIPv4アドレスの確認応答のオプションが含まれています。 IPv4アドレスの確認応答オプションは、任意のバインディング識別子モビリティオプションの前に存在しなければなりません。 IPv4のアドレスの確認応答オプションのStatusフィールドは、[RFC5555]のセクション3.2.1で定義されたエラーコードのみが含まれています。ホームエージェントは、常にIPv4のホームアドレス登録のための結合謝辞でのIPv4アドレスの受け付けモビリティオプションを含まなければなりません。
Mobile IPv6 [RFC3775] and the NEMO protocol [RFC3963] require the use of IPsec to protect signaling messages, including Binding Updates, Binding Acknowledgements, and return routability messages. IPsec may also be used to protect all tunneled data traffic. The Mobile IPv6- IKEv2 specification [RFC4877] specifies how IKEv2 can be used to set up the required IPsec security associations. The following assumptions were made in [RFC3775], [RFC3963], and [RFC4877] with respect to the use of IKEv2 and IPsec.
モバイルIPv6 [RFC3775]及びNEMOプロトコル[RFC3963]は結合更新結合謝辞、及びルータビリティメッセージを返す含むシグナリングメッセージを保護するためのIPsecの使用を必要とします。 IPsecはまた、すべてのトンネリングデータトラフィックを保護するために使用することができます。モバイルIPv6- IKEv2の仕様[RFC4877]はIKEv2のが必要なのIPsecセキュリティアソシエーションを設定するために使用することができるかを指定します。以下の仮定は、IKEv2のとIPsecの使用に関して[RFC3775]、[RFC3963]及び[RFC4877]で行われました。
o There is only one primary care-of address per mobile node.
O 1つのプライマリケア - のモバイルノードあたりのアドレスがあります。
o The primary care-of address is stored in the IPsec database for tunnel encapsulation and decapsulation.
oをプライマリ気付アドレスは、トンネルカプセル化およびカプセル化解除のためにIPsecのデータベースに格納されています。
o When the home agent receives a packet from the mobile node, the source address is verified against the care-of address in the corresponding binding cache entry. If the packet is a reverse-tunneled packet from the mobile node, the care-of address check is done against the source address on the outer IPv6 header. The reverse-tunneled packet could either be a tunneled Home Test Init message or tunneled data traffic to the correspondent node.
ホームエージェントは、モバイルノードからパケットを受信すると、O、送信元アドレスは、対応するバインディングキャッシュエントリに気付アドレスに対して検証されます。パケットは、移動ノードから逆トンネリングされたパケットである場合、気付アドレスのチェックは、外側のIPv6ヘッダに送信元アドレスに対して行われます。逆トンネリングされたパケットは、いずれかの対応ノードにトンネリングホーム試験開始メッセージや、トンネリングデータトラフィックである可能性があります。
o The mobile node runs IKEv2 (or IKEv1) with the home agent using the care-of address. The IKE SA is based on the care-of address of the mobile node.
モバイルノードoを気付アドレスを使用して、ホームエージェントとのIKEv2（またはIKEv1の）を実行します。 IKE SAは気付けモバイルノードのアドレスに基づいています。
The above assumptions may not be valid when multiple care-of addresses are used by the mobile node. In the following sections, the main issues with the use of multiple care-of addresses with IPsec are addressed.
複数の気付アドレスがモバイルノードによって使用されるとき、上記の仮定が有効ではないかもしれません。次のセクションでは、IPsecの持つ複数の気付アドレスの使用の主な問題は解決されています。
For each home address for which the mobile node sets up security associations with the home agent, the mobile node must pick one care-of address and use that as the source address for all IKEv2 messages exchanged to create and maintain the IPsec security associations associated with the home address. The resultant IKEv2 security association is created based on this care-of address.
モバイルノードがホームエージェントにセキュリティアソシエーションを設定する各ホームアドレスの場合は、モバイルノードは、1つの気付アドレスを選択し、すべてのIKEv2メッセージの送信元アドレスとして関連付けられたのIPsecセキュリティアソシエーションを作成し、維持するために交換することを使用する必要があります。自宅の住所。結果のIKEv2セキュリティアソシエーションは、この気付アドレスに基づいて作成されます。
If the mobile node needs to change the care-of address, it just sends a Binding Update with the care-of address it wants to use, with the corresponding Binding Identifier mobility option, and with the 'K' bit set. This will force the home agent to update the IKEv2 security association to use the new care-of address. If the 'K' bit is not supported on the mobile node or the home agent, the mobile node MUST re-establish the IKEv2 security association with the new care-of address. This will also result in new IPsec security associations being set up for the home address.
モバイルノードが気付アドレスを変更する必要がある場合、それだけで、対応するバインディング識別子モビリティオプションで、と「K」ビットのセットで、気付けアドレス、それが使用したいとのバインディングアップデートを送信します。これは、新しい気付アドレスを使用するのIKEv2セキュリティアソシエーションを更新するには、ホームエージェントを強制します。 「K」ビットは、モバイルノードまたはホームエージェントでサポートされていない場合、モバイルノードは、新たな気付アドレスでのIKEv2セキュリティアソシエーションを再確立する必要があります。これはまた、新しいIPsecセキュリティアソシエーションがホームアドレスのために設定されているになります。
For Mobile IPv6 signaling message protected using IPsec in transport mode, the use of a particular care-of address among multiple care-of addresses does not matter for IPsec processing.
モバイルIPv6は、トランスポートモードでIPsecを使用して保護されたメッセージをシグナリングするために、特定の気付アドレス複数の気付アドレスのうちの使用は、IPsec処理のために重要ではありません。
The home agent processes Mobile Prefix Discovery messages with the same rules of data packets described in Section 6.5.
ホームエージェントは、6.5節で説明したデータパケットの同じルールを使用したモバイルプレフィックスディスカバリーメッセージを処理します。
The use of IPsec in tunnel mode with multiple care-of addresses introduces a few issues that require changes to how the mobile node and the home agent send and receive tunneled traffic. The route optimization mechanism described in [RFC3775] mandates the use of IPsec protection in tunnel mode for the Home Test Init and Home Test messages. The mobile node and the home agent may also choose to protect all reverse-tunneled payload traffic with IPsec in tunnel mode. The following sections address multiple care-of address support for these two types of messages.
複数の気付アドレスを持つトンネルモードのIPsecの使用は、モバイルノードとホームエージェントがトンネルトラフィックを送受信する方法の変更が必要になるいくつかの問題を紹介します。 [RFC3775]で説明経路最適化メカニズムは、ホーム試験開始とホーム試験メッセージのトンネルモードのIPsec保護を使用することを義務付け。モバイルノードとホームエージェントはまた、トンネルモードでのIPsecをすべて逆トンネル化ペイロードトラフィックを保護することもできます。次のセクションでは、メッセージのこれら2つのタイプのために複数の気付アドレスの支援に取り組みます。
The mobile node MAY use the same care-of address for all Home Test Init messages sent reverse tunneled through the home agent. The mobile node may use the same care-of address irrespective of which correspondent node the Home Test Init message is being to. RFC 3775 requires the home agent to verify that the mobile node is using the care-of address that is in the binding cache entry when it receives a reverse-tunneled Home Test Init message. If a different address is used as the source address, the message is silently dropped by the home agent. This document requires the home agent implementation to decapsulate and forward the Home Test Init message as long as the source address is one of the care-of addresses in the binding cache entry for the mobile node.
モバイルノードは、逆のホームエージェントを介してトンネル送信されたすべてのホーム試験開始メッセージに同じ気付アドレスを使用するかもしれません。モバイルノードに関係なくホーム試験開始メッセージがにされている相手ノードの同じ気付アドレスを使用してもよいです。 RFC 3775は、モバイルノードが気付それが逆トンネリングホーム試験開始メッセージを受信したバインディングキャッシュエントリにあるアドレスを使用していることを確認するために、ホームエージェントが必要です。異なるアドレスを送信元アドレスとして使用されている場合、メッセージは静かにホームエージェントによって削除されます。この文書では、限り、送信元アドレスが気付アドレスモバイルノードのバインディングキャッシュエントリ内の一つであるとして、ホーム試験開始メッセージをデカプセル化して転送するために、ホームエージェントの実装が必要です。
When the home agent tunnels a Home Test message to the mobile node, the care-of address used in the outer IPv6 header is not relevant to the Home Test message. So regular IPsec tunnel encapsulation with the care-of address known to the IPsec implementation on the home agent is sufficient.
ホームエージェントは、モバイルノードにホーム・テスト・メッセージをトンネルする際、気付アドレス外側のIPv6ヘッダで使用されるホーム・テスト・メッセージに関係しません。だから、気付アドレス、ホームエージェント上のIPsec実装に知られているとの定期的なIPsecトンネルカプセル化は十分です。
When the mobile node sends and receives multiple traffic flows protected by IPsec to different care-of addresses, the use of the correct care-of address for each flow becomes important. Support for this requires the following two considerations on the home agent.
モバイルノードが送信し、受信したときに複数のトラフィックは、異なる気付アドレスへのIPsecによって保護されて流れ、各フローの正しい気付アドレスの使用が重要となります。これに対するサポートは、ホームエージェントに次の2点が必要です。
o When the home agent receives a reverse-tunneled payload message protected by IPsec in tunnel mode, the source address used in the outer IPv6 header is irrelevant to IPsec, since the tunnel mode security association is based on the addresses in the inner IPv6 header. Therefore, the same IPsec security association can be used for payload traffic tunneled from any of the care-of addresses. Note that the care-of address used in the reverse-tunneled traffic can be different from the care-of address used as the source address in the IKEv2 exchange. However, this does not cause an issue due to the above-mentioned reason.
ホームエージェントは、トンネルモードのIPsecによって保護された逆トンネリングペイロードメッセージを受信すると、トンネルモードのセキュリティアソシエーションがインナーIPv6ヘッダのアドレスに基づいているので、O、外側のIPv6ヘッダで使用されるソースアドレスは、IPsecのとは無関係です。そのため、同じIPsecセキュリティアソシエーションは気付アドレスのいずれかからトンネルペイロードトラフィックのために使用することができます。気付アドレスリバーストンネルトラフィックに使用されるが、気付アドレスのIKEv2交換のソースアドレスとして使用される異なることができることに留意されたいです。しかし、これは、上記の理由に問題を引き起こすことはありません。
o For tunneled IPsec traffic from the home agent to the mobile node, the IPsec implementation on the home agent will not be aware of which care-of address to use when performing IPsec tunnel encapsulation. The Mobile IP stack on the home agent, based on the binding cache entries created by the mobile node, knows to which care-of address the packet belonging to a particular flow needs to be tunneled. The destination address for the outer IP header must either be conveyed dynamically per packet to the IPsec stack when it performs the encapsulation or the Mobile IPv6 stack must get access to the packet after IPsec processing is done and modify the destination address. The first option requires changes to the IPsec implementation. In the second option, there is a need for special processing in the forwarding function to replace the destination address on the outer header with the correct care-of address. The exact technique to achieve the above is implementation specific.
OモバイルノードにホームエージェントからトンネリングさIPsecトラフィックの場合は、ホームエージェント上のIPsec実装は、IPsecトンネルカプセル化を行うときに気付けアドレスを使用するかを認識しません。モバイルノードによって作成されたバインディングキャッシュエントリに基づいて、ホームエージェントのモバイルIPスタックは、特定のフローに属するパケットをトンネル化する必要がある気付アドレスを知っています。それはカプセル化またはIPsec処理が行われた後のパケットへのアクセスを取得し、宛先アドレスを変更しなければならないモバイルIPv6スタックを行う場合、外側IPヘッダの宛先アドレスは、いずれかのIPsecスタックにパケットごとに動的に搬送されなければなりません。最初のオプションは、IPsec実装を変更する必要があります。第二のオプションでは、正しい気付アドレスと外部ヘッダの宛先アドレスを交換する転送機能に特別な処理が必要とされています。上記を達成するための正確な技法は、実装固有です。
The security considerations for securing the Binding Update and Binding Acknowledgement messages with multiple care-of addresses are very similar to the security considerations for securing the Binding Update and Binding Acknowledgement. Please see [RFC3775] for more information. The Binding Update and Binding Acknowledgement messages with multiple care-of addresses are securely exchanged as described in [RFC3775], [RFC4877], and Section 9 of this document. Additional security considerations are described below.
バインディングアップデートを確保し、複数の気付アドレスで受信確認メッセージを結合するためのセキュリティ上の考慮事項は、バインディングアップデートを確保し、確認応答を結合するためのセキュリティ上の考慮事項と非常によく似ています。詳細については、[RFC3775]を参照してください。 [RFC3775]、[RFC4877]、およびこのドキュメントのセクション9に記載されるように結合更新と複数の気付アドレスで応答メッセージをバインディングが確実に交換されます。追加のセキュリティ上の考慮事項を以下に記載されています。
With simultaneous binding support, it is possible for a malicious mobile node to successfully bind a number of victims' addresses as valid care-of addresses for the mobile node with its home agent. Once these addresses have been bound, the malicious mobile node can perform a re-direction attack by instructing the home agent (e.g., setting filtering rules to direct a large file transfer) to tunnel packets to the victims' addresses. Such risk is highlighted in [MIP6ANALYSIS]. These attacks are possible because the care-of addresses sent by the mobile node in the Binding Update messages are not verified by the home agent, i.e., the home agent does not check if the mobile node is at the care-of address at which it claims to be. The security model for Mobile IPv6 assumes that there is a trust relationship between the mobile node and its home agent. Any malicious attack by the mobile node is traceable by the home agent. This acts as a deterrent for the mobile node to launch such attacks.
悪質なモバイルノードが正常に有効な気付アドレスをそのホームエージェントとモバイルノードのためとして、被害者のアドレスの数をバインドするために同時結合のサポートで、それは可能です。これらのアドレスがバインドされていたら、悪質なモバイルノードは、被害者のアドレスにトンネルパケットにホームエージェント（例えば、大容量のファイル転送を指示するフィルタリングルールを設定すること）を指示することにより再方向攻撃を行うことができます。このようなリスクは、[MIP6ANALYSIS]で強調表示されます。介護のバインディング更新メッセージにモバイルノードによって送信されたアドレスがホームエージェントによって検証されていないため、これらの攻撃は、モバイルノードが気付アドレスそれでである場合、すなわち、ホームエージェントはチェックしません、可能であり、であることを主張します。モバイルIPv6のセキュリティモデルは、モバイルノードとそのホームエージェントとの間に信頼関係があることを前提としています。モバイルノードによって任意の悪意のある攻撃は、ホームエージェントによって追跡可能です。これは、このような攻撃を開始するために、モバイルノードのための抑止力として機能します。
Although such a risk exists in Mobile IPv6, the risk level is increased when simultaneous multiple care-of address bindings are performed. In Mobile IPv6, a mobile node can only have a single care-of address binding per home address at a given time. However, for simultaneous multiple care-of address bindings, a mobile node can have more than one care-of address binding per home address at a given time. This implies that a mobile node using simultaneous binding support can effectively bind more than a single victim's address. Another difference is the degree of risk involved. In the single care-of address binding case, once the re-direction attack is initiated, a malicious mobile node would be unable to use its home address for communications (such as to receive control packets pertaining to the file transfer). However, in the simultaneous binding support case, a malicious mobile node could bind a valid care-of address in addition to multiple victims addresses. This valid care-of address could then be used by the malicious mobile node to set up flow filtering rules at its home agent, thereby controlling and/or launching new re-direction attacks.
そのようなリスクは、モバイルIPv6に存在するが、同時に複数の気付アドレスのバインディングが実行されるとき、危険度が高くなります。モバイルIPv6では、モバイルノードは、特定の時点で単一のケア - のホームアドレスごとにアドレスバインディングを持つことができます。しかし、同時に複数の気付アドレスのバインディングのために、モバイルノードは、与えられた時間に複数の気付ホームアドレスごとにアドレスバインディングを持つことができます。これは同時結合のサポートを使用して、モバイルノードが効果的に、単一の犠牲者のアドレスよりも結合できることを意味します。もう一つの違いは、関係するリスクの度合いです。再方向攻撃が開始されると、単一の気付アドレスの場合の結合には、悪質なモバイル・ノードは、（そのようなファイル転送に関連する制御パケットを受信すると）通信にそのホームアドレスを使用することができないであろう。しかし、同時結合サポートケースには、悪質なモバイル・ノードは、複数の被害者のアドレスに加えて、有効な気付アドレスを結合することができます。この有効な気付アドレスは、それによって制御および/または新規の再方向攻撃を開始、そのホームエージェントでフローフィルタリングルールを設定する悪意のモバイルノードによって使用することができます。
Thus, in view of such risks, it is advisable for a home agent to employ some form of care-of address verification mechanism before using the care-of addresses as a valid routing path to a mobile node. These mechanisms are out of scope for this document.
ホームエージェントは、モバイルノードへの有効なルーティングパスとして気付アドレスを使用する前に、気付けアドレス検証メカニズムのいくつかのフォームを採用するためにこのように、そのようなリスクを考慮して、それが賢明です。これらのメカニズムはこの文書の範囲外です。
In the binding registration of Mobile IPv6, a care-of address is always verified by its reachability by a home agent. This reachability test may decrease the above risks. However, when bulk registration is used, a home agent cannot verify reachability of care-of addresses carried in a Binding Identifier mobility option. Therefore, the home agent can choose to reject bulk registration by using [MCOA BULK REGISTRATION PROHIBITED] in a Binding Acknowledgement. Alternatively, when a mobile node first registers a care-of address, it uses the individual Binding Updates for the first appeared care-of address. During the initial binding registration, a home agent can verify the address reachability for that given care-of address. After that, the mobile node uses bulk registration to refresh the care-of address.
モバイルIPv6のバインディング登録では、気付けアドレスは常にホームエージェントによって、その到達可能性によって検証されます。この到達可能性テストは、上記のリスクを減少させることができます。一括登録を使用する場合しかし、ホームエージェントは気付バインディング識別子モビリティオプションで運ばれたアドレスの到達可能性を検証することはできません。したがって、ホームエージェントはバインディング確認応答で[MCOAバルク登録禁止]を使用して一括登録を拒否することを選択することができます。モバイルノードが最初の気付アドレスを登録する際あるいは、それが最初に出現気付アドレスの更新をバインディング個体を用います。初期結合登録時に、ホームエージェントは、その与えられた気付アドレスのアドレス到達可能性を検証することができます。その後、モバイルノードは、気付アドレスをリフレッシュするために一括登録を使用しています。
The following Extension Types have been assigned by IANA:
以下の拡張タイプは、IANAによって割り当てられています：
o Binding Identifier mobility option type: (35) has been assigned from the same space as the mobility option in [RFC3775].
O結合識別子モビリティオプションのタイプ：（35）[RFC3775]におけるモビリティ・オプションと同じ空間から割り当てられています。
o New Successful Status of Binding Acknowledgement: These status codes have been assigned from the same space as the Binding Acknowledgement status codes in [RFC3775].
謝辞バインディングの新しい成功した状況○：これらのステータスコードは[RFC3775]で結合確認のステータスコードと同じ空間から割り当てられています。
* MCOA NOTCOMPLETE (4)
* MCOA NOTCOMPLETE（4）
* MCOA RETURNHOME WO/NDP (5)
* MCOAはRETURNHOME / NDPを持っている（5）
o New Unsuccessful Status of Binding Acknowledgement: These status codes have also been assigned from the same space as the Binding Acknowledgement status codes in [RFC3775].
謝辞バインディングのO新失敗ステータス：これらのステータスコードはまた、[RFC3775]にバインディング確認ステータスコードと同じ空間から割り当てられています。
* MCOA MALFORMED (164)
* MCOA MALFORMED（164）
* MCOA NON-MCOA BINDING EXISTS (165)
* MCOA NON-MCOAの結合（165）が存在します
* MCOA PROHIBITED (166)
* MCOA禁止（166）
* MCOA UNKNOWN COA (167)
* MCOA UNKNOWN COA（167）
* MCOA BULK REGISTRATION PROHIBITED (168)
* MCOAバルク登録の禁止（168）
* MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
* MCOA同時家と外国禁止（169）
Ryuji Wakikawa and Thierry Ernst are grateful to Keio University for its initial support on this specification at the time when they were working there. In addition, the authors would like to thank Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Martti Kuparinen, Romain Kuntz, Benjamin Lim, Heikki Mahkonen, Nicolas Montavont, and Chan-Wah Ng for their discussions and inputs. Thanks to Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Uehara, Masafumi Watari, and Jun Murai for earlier work on this subject.
隆次Wakikawaとティエリーエルンストは、彼らがそこに働いていた時に、この仕様上その初期支援のための慶應義塾大学に感謝しています。また、著者は、彼らの議論や入力のため雅文Aramoto、圭吾麻生、ジュリアンCharbon、TERO Kauppinen、マルッティKuparinenが、ロマンKuntz、ベンジャミン・リム、ヘイッキMahkonen、ニコラスMontavont、とチャン・ワウ呉に感謝したいと思います。このテーマに関する以前の仕事のための進小柴、弘樹Matutani、幸四郎三ツ矢、浩二岡田啓介上原、雅文亘理、および村井純に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877] Devarapalli、V.とF.デュポン、 "IKEv2のと改訂のIPsecアーキテクチャとのモバイルIPv6の操作"、RFC 4877、2007年4月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]ソリマン、H.、エド。、RFC 5555 "デュアルスタックホストとルータのためのモバイルIPv6のサポート"、2009年6月。
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568] Koodli、R.、エド。、 "モバイルIPv6高速ハンドオーバ"、RFC 5568、2009年7月。
[MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Work in Progress, May 2008.
[動機]エルンスト、T.、Montavont、N.、Wakikawa、R.、呉、C.、およびK. Kuladinithi、進歩、2008年5月には、作業 "複数のインタフェースアドレスとグローバルアドレスを使用するための動機とシナリオ"。
[RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007.
[RFC4980]呉、C.、エルンスト、T.、パイク、E.、およびM. Bagnulo、 "ネットワークモビリティサポートにおけるマルチホーミングの分析"、RFC 4980、2007年10月。
[MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, May 2008.
[MIP6ANALYSIS] Montavont、N.、Wakikawa、R.、エルンスト、T.、呉、C.、およびK. Kuladinithi、 "モバイルIPv6におけるマルチホーミングの分析"、進歩、2008年5月での作業。
[RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]マナー、J.、エド。、およびM.古城、エド。、 "モビリティ関連用語"、RFC 3753、2004年6月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[RFC4885]エルンスト、T.およびH-Y。 LACH、 "ネットワークモビリティサポート用語"、RFC 4885、2007年7月。
Authors' Addresses
著者のアドレス
Ryuji Wakikawa (Editor) TOYOTA InfoTechnology Center Co., Ltd.
りゅじ わきかわ （えぢとｒ） とよた いんふぉてｃｈのぉｇｙ せんてｒ こ。、 Ｌｔｄ。
EMail: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)
Eメール：ryuji.wakikawa@gmail.com（ryuji@jp.toyota-itc.com）
Vijay Devarapalli Wichorus
ビジェイdevarapalli vicaras
EMail: vijay@wichorus.com
メールアドレス：vijay@wichorus.com
George Tsirtsis Qualcomm
ジョージTsirtsisクアルコム
EMail: Tsirtsis@gmail.com
メールアドレス：Tsirtsis@gmail.com
Thierry Ernst INRIA
ティエリーエルンストINRIA
EMail: thierry.ernst@inria.fr
メールアドレス：thierry.ernst@inria.fr
Kenichi Nagami INTEC NetCore Inc.
けにち ながみ いんてＣ ねｔこれ いんｃ。
EMail: nagami@inetcore.com
メールアドレス：nagami@inetcore.com