[要約] RFC 5648は、IPv6モビリティ管理プロトコルであるMultiple Care-of Addresses Registration（MCoA）に関する仕様を提供しています。このRFCの目的は、モビリティ管理のために複数のCare-ofアドレスを登録するための手順と要件を定義することです。
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仕様によると、モバイルノードにはいくつかのアドレスがある場合がありますが、プライマリケアオブアドレスと呼ばれる1つだけがホームエージェントと特派員ノードに登録できます。ただし、コスト、帯域幅、遅延などの問題については、モバイルノードが複数のアクセスを介して同時にインターネットアクセスを取得することが役立ちます。このドキュメントでは、モバイル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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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、Cellular Radioなどの複数のインターフェイスを持つモバイルノードでますます当てはまります。複数のインターフェイスを備えたモバイルノードがモバイル管理にモバイルIPv6 [RFC3775]を使用する場合、モバイルIPv6が提供するセッションの連続性を活用しながら、複数のインターフェイスを使用してパケットを送信および受信することはできません。これは、モバイルIPv6を使用すると、モバイルノードが自宅の住所で一度に1つのケアのケアのみをバインドできるためです。モバイル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）番号が作成され、バインディングアップデートで送信されます。このバインディングアップデートを受信するホームエージェントは、各入札に対して個別のバインディングを作成します。入札情報は、対応するバインディングキャッシュエントリに保存されます。入札情報を使用して、個々のバインディングを識別できるようになりました。同じ拡張機能を、特派員ノードに送信したバインディング更新にも使用できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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)
バインディング識別番号（入札）
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.
入札は、モバイルノードによって登録された複数のバインディングを区別するために使用される識別番号です。明確な入札の割り当てにより、モバイルノードは、特定のホームアドレスの複数のバインディングキャッシュエントリを登録できます。同じホームアドレスに割り当てられた入札は、同時に複製してはなりません。値ゼロは、将来の拡張機能のために予約されています。各入札は、モバイルノードによって生成および管理されます。入札はバインディングアップデートリストに保存され、バインディングアップデートのモバイルノードによって送信されます。モバイルノードは、たとえば、プライバシーを保護するために、その管理ポリシーに従っていつでも入札の値を変更する場合があります。実装は、バインディングのステータスが変更された場合でも、同じバインディングに対して同じ入札を使用し続けるために、入札を慎重に割り当てる必要があります。詳細については、セクション5.1をご覧ください。
Binding Identifier Mobility Option
バインディング識別子モビリティオプション
The Binding Identifier mobility option is used to carry the BID information.
バインディング識別子モビリティオプションは、入札情報を運ぶために使用されます。
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）と呼ばれる新しい拡張機能が導入され、同じホームアドレスに関連する複数のバインディングを区別します。モバイルノードが1つ以上のインターフェイスで複数のIPv6グローバルアドレスを構成する場合、これらのアドレスをホームエージェントにケアオブアドレスとして登録できます。モバイルノードが複数のバインディングを登録する場合、各アドレスの入札を生成し、バインディングアップデートリストに入札を保存する必要があります。モバイルノードは、入札を使用して各バインディングを個別に操作できます。モバイルノードは、バインディング識別子モビリティオプションを使用してバインディングアップデートを送信することにより、そのケアアドレスを登録します。
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.
入札は、バインディング識別子モビリティオプションに含まれています。バインディング識別子モビリティオプションでバインディングアップデートを受信した後、ホームエージェントは、バインディング識別子モビリティオプションからバインディングキャッシュエントリの対応するフィールドに入札をコピーする必要があります。モバイルノードに既存のバインディングキャッシュエントリがあり、バインディングアップデートの入札が既存のエントリと一致しない場合、ホームエージェントは新しいアドレスと入札の新しいバインディングキャッシュエントリを作成する必要があります。モバイルノードは、単一のバインディングアップデートで一度に複数のアドレスを登録するか、個々のバインディングアップデートで個別に登録できます。
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]に記載されているように、返品ルー上の操作を実行する必要があります。これには、各住所ごとのケアのケアトークンの管理と、各住所の特派員ノードとのケアのケアイニシとテストのケアメッセージの交換が含まれます。モバイルノードは、特定のケアオブアドレスにホームエージェントと同じ入札を使用する場合があります。プロトコルのシンプルさの場合、このドキュメントでは、特派員ノードへのバルク登録はサポートされていません。これは、[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]
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]に準拠した通常のモバイルノードとして機能することを決定した場合、バインディング識別子モビリティオプションなしでバインディングアップデートを送信します。バインディングアップデートの受信機は、入札で登録されたすべてのバインディングを削除し、モバイルノードの単一のバインディングのみを登録します。モバイルノードは、アクティブな単一のバインディングしかない場合でも、入札を使用し続けることができることに注意してください。
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].
バインディングキャッシュルックアップは、入札が利用可能な場合は、自宅の住所と入札情報に基づいて行われます。これは、RFC 3775とは異なり、キャッシュルックアップのバインドにはホームアドレスのみが使用されます。バインディングキャッシュルックアップは、プロトコルシグナルまたはデータパケットのいずれかで操作されます。バインディングアップデートなどのプロトコルシグナリングの場合、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 CARE-of Address1] Binding [2001：DB8 :: EUI BID2 CARE-of Address2]
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.
2. モバイルノードは、図3に示すように、ホームリンクに接続されたインターフェイスと訪問されたリンクにまだ添付されているインターフェイスの両方を同時に使用できます。ホームエージェントが唯一のルーターであるかどうかによって、2つのトポロジが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]
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 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]との逆方向の互換性が保持されます。レシーバー（ホームエージェントまたは特派員ノード）がこの仕様をサポートしていない場合、バインディング識別子モビリティオプションがわかりません。受信機は、未知のモビリティオプション（つまり、バインディング識別子モビリティオプション）をスキップし、[RFC3775]で定義されているようにバインディングアップデートを処理します。[RFC3775]との逆方向の互換性を維持するために、モバイルノードがこのドキュメントで説明されている拡張機能を使用してバインディングアップデートメッセージを送信する場合、レシーバーはバインディング識別子モビリティオプションをバインディング承認で反映する必要があります。モバイルノードが受信したバインディングの確認にバインディング識別子モビリティオプションを見つけられない場合、もう一方のエンドノードがこの仕様をサポートしていないと仮定します。そのような場合、モバイルノードはレガシー[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.
入札は、バインディングキャッシュとバインディングアップデートリスト構造に保存する必要があります。
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.
この仕様は、新しいフラグを使用してバインディングアップデートメッセージを拡張します。フラグを以下に示し、説明します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
このフラグが設定されると、モバイルノードのすべてのバインディングキャッシュエントリは、このバインディングアップデートメッセージに登録する新しいエントリに置き換えられます。このフラグは、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.
バインディング識別子モビリティオプションは、バインディングアップデート、バインディング確認、バインディングリフレッシュリクエスト、およびテストのケアINITとケアオブテストメッセージに含まれています。バインディング識別子モビリティオプションには、アドレスのケアフィールドが存在しない場合、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：入札モビリティオプション
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に設定する必要があります。このオプションによってアドレスのケアが運ばれない場合、長さの値を4に設定する必要があります。IPv4アドレスのケアオブアドレスフィールドに保存されている場合、長さは8でなければなりません。IPv6 Care-of Addressの場合は20に設定する必要があります。
Binding ID (BID)
バインディングID（入札）
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.
バインディングアップデートまたはバインディング識別子モビリティオプションのケアのケアによって示されるバインディングに割り当てられた入札。入札は、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.
ステータスフィールドは、8ビットの署名のない整数です。拘束力のある識別子モビリティオプションが拘束力のある承認に含まれる場合、このフィールドは、この入札のみの拘束力のある承認のステータスフィールドを上書きします。このフィールドがゼロに設定されている場合、受信機はこのフィールドを無視し、拘束力のある確認メッセージに保存されている登録ステータスを使用します。バインディング識別子モビリティオプションがバインディングの確認またはテストのケアメッセージのいずれか内で運ばれない場合、受信機はこのフィールドを無視する必要があります。考えられるステータスコードは、バインディング承認のステータスコードと同じです。このステータスフィールドは、テストのケアメッセージのアドレスケアテストに関連するエラー情報を伝達するためにも使用されます。
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のケアオブアドレスのいずれかをこのフィールドに保存できます。特派員ノードへのバインディング登録（つまり、ルート最適化）の場合、このフィールドにIPv6のケアのケアのみを保存できます。このフィールドでアドレスが指定されていない場合、このフィールドの長さはゼロでなければなりません（つまり、オプションには表示されません）。オプションがバインディングアップデート以外のメッセージに含まれている場合、このフィールドの長さもゼロでなければなりません。
New status values for the Status field in a Binding Acknowledgement are defined for handling the multiple care-of addresses registration:
拘束力のある承認内のステータスフィールドの新しいステータス値は、複数のアドレスのケアの登録を処理するために定義されています。
MCOA NOTCOMPLETE (4)
MCOA NOT COMPLETE（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.
バルク登録では、すべての拘束力のある識別子モビリティオプションが正常に登録されたわけではありません。それらのいくつかは拒否されました。故障したモビリティオプションのエラーステータス値は、バインディング識別子モビリティオプションのステータスフィールドに個別に保存されます。
MCOA RETURNHOME WO/NDP (5)
MCOAリターンホームWO/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奇形（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）に保存されているバインディング識別子モビリティオプションのケアオブアドレスフィールド（ESP）に保存されていない場合。
MCOA NON-MCOA BINDING EXISTS (165)
MCOA非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バルク登録禁止（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同時ホームと外国人禁止（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を使用できることに注意してください。モバイルノードが入札を使用するかどうかは、ローカル構成によって決定されます。
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.
2. モバイルノードは、単一の物理ネットワークインターフェイスを使用しますが、インターフェイスが添付されているリンク上の複数のプレフィックスの広告を受信します。これにより、モバイルノードが発表された各プレフィックスからインターフェイス上にいくつかのグローバルアドレスを構成します。
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.
モバイルノードは、自宅の住所と同時に登録する場合、各住所に入札を割り当てます。入札は、特定のホームアドレスに対して一意でなければなりません。値は1〜65535の整数です。ゼロ値は入札として使用しないでください。モバイルノードに1つのアドレスのみがある場合、登録するための複数のアドレスのケアがあるまで入札の割り当ては必要ありません。
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.
モバイルノードが特定の入札を初めて登録する場合、バインディング識別子モビリティオプションにアドレスのケアフィールドを含める必要があります。同じ入札を再登録または解体する後の登録の場合、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.
[RFC4877]に記載されているように、IPSEC ESPがバインディングアップデートの保護に使用される場合、アドレスのケアを代替アドレスモビリティオプションで運ぶ必要があります。ただし、この仕様では、バインディング識別子モビリティオプションのケアオブアドレスフィールドに配置する必要があります。バインディングアップデートのビットを保存するために、代替のアドレスケアオプションオプションを含める必要はありません。
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用のアクティブホームとケアオブキーゲントークン（バインディング管理キー、[RFC3775]のセクション5.2.5を参照）を持つ必要があります。キーゲントークンのケアは、モバイルノードが特派員ノードに登録することを望んでいる各住所に対して維持する必要があります。特派員ノードへのバインディングアップデートは、バインディング識別子モビリティオプションの後に配置されたバインディング認証データモビリティオプションによって保護されます。
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.
モバイルノードが、Homeエージェントの既存の登録バインディングを送信バインディングアップデートの単一のバインディングに置き換えたい場合、「O」フラグを設定します。「O」フラグが設定されていない場合、ホームエージェントの既存のバインディングにバインディングが追加されます。単一のバインディングは、割り当てられた入札に登録されます。セクション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.
バルク登録を使用するために、モバイルノードには、同じバインディングアップデートメッセージに登録する各入札のバインディング識別子モビリティオプションが含まれています。単一の登録（セクション5.1を参照）と同様に、初めて登録された各入札には、ケアオブアドレスのフィールドが含まれています。これを図7に示します。バインディングアップデートの残りのフィールドとオプション（Lifetime、Sequence番号、バインディングアップデートのフラグなど）は、すべてのアドレスで一般的です。
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)
IPv6ヘッダー（SRC =ケアオブアドレス、DST =ホームエージェントアドレス）IPv6ホームアドレスオプションESPヘッダーモビリティヘッダーバインディングアップデートモビリティオプションバインディング識別子（ケアオブアドレスを含む）バインディング識別子識別子バインディング識別子識別子（住所のケア）バインディング識別（住所のケアなし）
:
：
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]で定義されているように、Lifetimeセットをゼロに設定した定期的な登録バインディングアップデートを送信します。バインディング識別子モビリティオプションは必要ありません。
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.
モバイルノードがホームエージェントと特派員ノードから特定のバインディングを削除したい場合、モバイルノードはLifetimeセットのバインディングアップデートをゼロに送信し、BID（s）のバインディング識別子モビリティオプションを含む登録解除したい。受信者は、指定された入札に一致する（ES）のケアオブアドレス（ES）のみを削除します。登録解除は既に存在する入札を削除しようとするため、各バインディング識別子オプションのアドレスケアフィールドは、セクション5.1で定義されているように送信者が省略できます。
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.
モバイルノードは物理的に家に帰りますが、ホームリンクに接続されたインターフェイスをシャットダウンします。その結果、インターフェイスの1つによってホームリンクに取り付けられていても、モバイルノードは家に帰りません。インターフェイスをシャットダウンする前に、インターフェイスに以前に関連付けられたアドレスのケアのバインディングは、セクション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ノードとしてホームリンクのホームアドレスのネイバーキャッシュエントリを管理できます。ただし、このシナリオには1つの制限があります。特派員ノードがホームリンクにある場合、ホームエージェントはモバイルノードに運命づけられているパケットを傍受することはできません。これらのパケットはホームリンクを介してのみルーティングされますが、これはモバイルノードがホームリンクのノードと通信するための最も最適なパスです。
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]で定義されたMobility Header Link-Layerアドレスオプションを使用して、バインディングアップデートでモバイルノードのリンクレイヤーアドレスを運びます。同様に、モバイルノードは、デフォルトのルーターアドレスのリンク層アドレスを知っており、近隣の発見なしでホームリンクからパケットを送信します。リンク層アドレスは、ホームリンクのモバイルノードからのパケットを送信するために使用されます。パケットは、リンク層ヘッダーを手動で構築することにより、Neighbor Discoveryプロトコルなしで送信されます。この操作は、モバイルノードがホームエージェントのリンクレイヤーアドレスに登録解除バインディングアップデートを送信して、操作のためにホームエージェントのリンク層アドレスに送信すると、モバイル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」フラグセットを使用して、バインディング識別子モビリティオプションを使用して登録バインディングアップデートを送信する必要があります。寿命は、ホームバインディングのゼロ以外の寿命に設定する必要があり、住所のケアフィールドは自宅の住所に設定する必要があります。モバイルノードは、複数のインターフェイスでホームリンクに取り付けられていても、一度に1つのホームバインディングのみを登録します。
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.
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リターンホームWO/NDP]を受信した場合、自宅の住所の近隣発見を操作してはなりません。モバイルノードがホームリンクに接続されたインターフェイスからパケットを送信する場合、次のホップのリンクレイヤーアドレス（つまり、モバイルノードのデフォルトルーター）を学習する必要があります。モバイルノードは、ルーター広告のソースリンクレイヤーアドレスオプションからデフォルトのルーターのリンク層アドレスを学習します。モバイルノードは、パケットをデフォルトのルーターのリンク層アドレスに直接送信します。これは、パケットを構築して、デフォルトのルーターの学習リンク層アドレスにリンク層ヘッダーを含めることによって行われます。また、ホームエージェントは、モバイルノードのリンク層アドレスを使用して、ホームリンクのモバイルノードにパケットを転送します。リンク層アドレスは、ホームエージェントがゼロレジスタレーションバインディングアップデートメッセージを受信したときにキャッシュする必要があります。デフォルトのルーターは、モバイルノードからホームエージェントにパケットを転送するときに、近隣キャッシュのモバイルノードのリンク層アドレスをキャッシュしてはならないことに注意してください。
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.
モバイルノードに、「A」フラグセットを使用したバインディングアップデートにバインディング識別子モビリティオプションが含まれている場合、バインディングの確認には、バインディング識別子モビリティオプションが含まれている必要があります。[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.
Binding Identifier Mobilityオプションが受信されたバインディング確認書に存在する場合、モバイルノードはオプションのステータスフィールドをチェックします。バインディング識別子モビリティオプションのステータス値がゼロの場合、モバイルノードはバインディング確認のステータスフィールドに値を使用します。それ以外の場合、バインディング識別子モビリティオプションのステータスフィールドで値を使用します。
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以上の場合、モバイルノードはエラーコードに従って関連する操作を開始します。それ以外の場合、モバイルノードは、オリジネーター（ホームエージェントまたは特派員ノード）がバインディング情報を正常に登録し、モバイルノードに入札したと想定しています。
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.
o ステータス値が[MCOAバルク登録が禁止されている]の場合、モバイルノードは、拘束力のある確認を送信したノードでバルク登録の使用を停止する必要があります。試行された登録のいずれも成功しなかったと仮定する必要があります。
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.
o [MCOA奇形]が指定されている場合、おそらくプログラミングエラーまたは主要なパケットの破損により、バインディング識別子モビリティオプションが間違ってフォーマットされていることを示します。
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.
o [MCOA非MCOA結合が存在する]が指定されている場合、受信機に非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.
o [MCOA不明COA]が指定されている場合、モバイルノードがアドレス対応フィールドのないバインディング識別子モビリティオプションを送信したことを意味しますが、受信機は示されている入札のエントリを見つけることができませんでした。モバイルノードが入札の登録を解除しようとしている場合、これ以上何もする必要はありません。モバイルノードがバインディングを更新しようとしている場合、アドレスのケアフィールドを含むバインディング識別子モビリティオプションを送信する必要があります。
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.
モバイルノードがバインディング識別子モビリティオプションを使用してバインディングリフレッシュリクエストを受信した場合、バインディングリフレッシュリクエストメッセージを送信するノードがモバイルノードが入札用に新しいバインディングアップデートを送信することを要求していることを示します。モバイルノードは、セクション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).
モバイルノードがブートストラップして複数のバインディングを初めて登録する場合、バインディングアップデートメッセージに「O」フラグを設定する必要があります。ホームエージェントに古いバインディングがまだ存在する場合、モバイルノードにはホームエージェントにまだどのバインディングが存在するかについての知識がありません。このシナリオは、モバイルノードが再起動し、登録に関して状態を失ったときに発生します。「O」フラグが設定されている場合、すべてのバインディングは新しいバインディングに置き換えられます。
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.
特派員ノードまたはホームエージェントのいずれかのノードは、対応する入札を知っている場合（たとえば、信号メッセージを処理するとき）、ホームアドレスと入札の両方をバインディングキャッシュの検索キーとして使用する必要があります。以下の例では、ノードがホームアドレスとBID2とのバインディングを検索すると、このモバイルノードのバインディング2が取得されます。
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.
ノードは、バインディング識別子モビリティオプションを受信したときに入札を学習します。その時点で、ノードはホームアドレスとバインディングアップデートから取得された入札でバインディングキャッシュデータベースを調べる必要があります。ノードが入札を知らない場合、ホームアドレスのみでバインディングを検索します。そのような場合、最初の一致した結合が見つかります。ノードがモバイルノードに複数のバインディングを使用することを望まない場合、単に入札を無視できます。
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不正]に返す必要があります。
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].
o 長さの値が8または20の場合、バインディング識別子モビリティオプションにはケアオブアドレスが存在する必要があります。ユニキャストルーファブルアドレス[RFC3775]がアドレスのケアフィールドに存在しない場合、受信者はバインディング識別子モビリティオプションを拒否し、[MCOA奇形]に設定されたステータス値を返す必要があります。
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 バインディングアップデートの寿命フィールドがゼロに設定されている場合、受信ノードは、バインディング識別子モビリティオプションの入札に対応するバインディングエントリを削除します。受信ノードに入札のための適切なバインディングがない場合、バインディングアップデートを拒否し、ステータスを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 寿命フィールドがゼロに設定されていない場合、受信ノードはモバイルノードのバインディングとして指定された入札とのバインディングを登録します。住所のケアは、次のようにバインディングアップデートパケットから取得されます。
* 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の場合、Care of Addressは、バインディング識別子モビリティオプションのCare of Addressフィールドからコピーされた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不明]に設定されたバインディング識別子モビリティオプションのステータスと結合確認を送信する必要があります。
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」フラグが設定されており、受信機にモバイルノードの入札がない定期的なバインディングがある場合、バインディングアップデートを処理してはなりません。受信者は、[MCOA非MCOAバインディング]に設定されたステータスを使用して拘束力のある確認を送信する必要があります。
* 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].
* 受信者が既に同じ入札でバインディングを持っているが、異なるアドレスのケアを持っている場合、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].
* 受信者が入札の拘束力のあるエントリを持っていない場合、入札の新しいバインディングを登録し、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.
上記のすべての操作が正常に完了し、「A」フラグがバインディングアップデートに設定されている場合、バインディング識別子モビリティオプションを含むバインディングの確認をモバイルノードに送信する必要があります。拘束力のある確認が送信されるたびに、バインディングアップデートに保存されているすべてのバインディング識別子モビリティオプションを、ステータスフィールドを除くバインディング確認書にコピーする必要があります。ただし、モバイルノードが入札を使用して対応するバインディングアップデートリストエントリと一致できるため、各バインディング識別子モビリティオプションのケアオブアドレスフィールドは省略できます。
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.
特派員ノードが拘束力のある承認を送信する場合、ステータス値は常にバインディング確認のステータスフィールドに保存する必要があり、バインディング識別子モビリティオプションのステータスフィールドは常にゼロに設定する必要があります。
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.
ホームエージェントが拘束力のある謝辞を送信すると、ステータス値は、拘束力のある確認または拘束力のある識別子モビリティオプションのステータスフィールドに保存できます。ステータス値がバルク登録のバインディングの1つに固有の場合、ステータス値は、対応するバインディング識別子モビリティオプションのステータスフィールドに保存する必要があります。この場合、バインディングの承認のステータスフィールドは[MCOA Not Complete]に設定する必要があります。これにより、受信機は、さらなる操作のために各バインディング識別子モビリティオプションのステータスフィールドを調べることができます。それ以外の場合、バインディング識別子モビリティオプションのステータスフィールドをゼロに設定し、バインディング確認のホームエージェントステータスフィールドを使用する必要があります。
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リターンホームWO/NDP（5）]に設定する必要があります。ホームリンクでのホームエージェントの構成に応じて。新しい値は次のとおりです。
* 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）：Home Linkの自宅住所では、近隣発見プロトコルが許可されています。これは、[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）：Home Linkのホームアドレスでは、近隣発見プロトコルが禁止されています。
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 バインディングアップデートが拒否された場合、適切なエラー値をステータスフィールドに設定する必要があります。この場合、ホームエージェントの操作は[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 ホームエージェントがホームリンクの唯一のルーターである場合にのみ、要求されたホームアドレスの近隣発見をオフにし、モバイルノードに[バインディングアップデートを受け入れた]ステータス値で応答します。モバイルノードは、バインディングの確認を受ける前にホームアドレスの近隣勧誘に返信しないため、ホームエージェントは、受信したバインディングアップデートでMobility Header Link-Layerアドレスオプション[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 ホームエージェントがホームリンクの唯一のルーターではない場合、ホームエージェントは、バインディング識別子モビリティオプションのステータスフィールドに[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リターンホーム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.
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.
ノード（ホームエージェントまたは特派員ノード）が入札で作成された特定のバインディングのバインディングリフレッシュリクエストを送信する場合、ノードにはバインディングリフレッシュリクエストにバインディング識別子モビリティオプションを含める必要があります。ノードには、更新する必要がある複数のバインディングがある場合、複数のバインディング識別子モビリティオプションが含まれる場合があります。
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ヘッダーのソースアドレスフィールドに表示されるアドレスのケアオブアドレスが、バインディングキャッシュ内のアドレスのケアの1つに等しいことを確認する必要があります。エントリ。バインディングが見つからない場合は、パケットを破棄する必要があります。ノードは、[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 Care of Addressの代わりにMobile IPv6を拡張してIPv6 Care of Addressを登録します。また、IPv4のみの特派員ノードで使用するためのIPv6ホームアドレスに加えて、モバイルノードがIPv4ホームアドレスを取得することもできます。このセクションでは、複数のアドレスの登録がIPv4 Care ofおよびHomeアドレスでどのように機能するかについて説明します。
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に示すように、UDPおよびIPv4ヘッダーを使用して、バインディングアップデートをIPv4ホームエージェントアドレスに送信する必要があります。これは、[RFC5555]に似ています。使用済み。
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]
IPv4ヘッダー（src = v4addr、dst = ha_v4addr）udpヘッダーIPv6ヘッダー（Src = v6hoa、dst = haaddr）[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ケアオブアドレスを登録できます。図10は、モバイルノードがIPv6ケアオブアドレスの1つからバインディングアップデートを送信するときのバインディングアップデート形式を示しています。モバイルノードがIPv4のケアオブアドレスからバインディングアップデートを送信する場合、図9に説明する形式に従う必要があります。IPv4のケアオブアドレスは、変更されたときはいつでもバルクバインディング登録以外の登録によって登録する必要があることに注意してください。
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 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.
図9に示すように、IPv4のケアオブアドレスは、バインディング識別子モビリティオプションに表示されます。[RFC5555]で定義されているIPv4 Care-of Addressモビリティオプションは、常に省略する必要があります。IPv4 Care-of Addressのバインディングアップデートメッセージの受信者は、[RFC5555]のIPv4 Care-of Addressモビリティオプションのモビリティオプションのものとして、バインディング識別子モビリティオプションに保存されているIPv4アドレスを処理する必要があります。バインディング識別子モビリティオプションのIPv4アドレスが、バインディングアップデートのIPv4ヘッダーのソースアドレスフィールドの1つ（つまり、図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) - ...
IPv6ヘッダー（src = Care -ofアドレス、DST =ホームエージェントアドレス）IPv6ホームアドレスオプションESPヘッダーモビリティヘッダー - バインディングアップデートモビリティオプション - バインディング識別子（IPv6/V4 COA） - バインディング識別子（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 Care-of Address登録の拘束力のある確認を返す場合、IPv4アドレス確認モビリティオプションを使用しないでください。バインディング識別子モビリティオプションのみを使用する必要があります。IPv4 Care-of Addressの登録ステータスは、バインディング識別子モビリティオプションのステータスフィールドに保存されます。ただし、Homeエージェントが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ホームアドレスオプションを使用してリクエストすることができます。ホームエージェントがバインディングアップデートを受け入れる場合、モバイルノードは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アドレス確認オプションのステータスフィールドには、[RFC555]のセクション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つの主要なケアアドレスは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ヘッダーのソースアドレスに対して、ケアオブアドレスチェックが行われます。逆タンネルパケットは、トンネル付きホームテストINITメッセージまたは特派員ノードへのトンネルデータトラフィックのいずれかです。
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つのケアアドレスを選択し、それを交換して、関連するIPSECセキュリティ関連を作成および維持するために交換されたすべてのIKEV2メッセージのソースアドレスとして使用する必要があります。自宅の住所。結果の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.
トランスポートモードでIPSECを使用して保護されたモバイルIPv6シグナリングメッセージの場合、複数のアドレスのケアの特定のケアを使用することは、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]で説明されているルート最適化メカニズムは、ホームテストINITおよびホームテストメッセージのためにトンネルモードでの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.
モバイルノードは、ホームエージェントを介して逆トンネルが送信されたすべてのホームテストINITメッセージに対して同じケアオブアドレスを使用する場合があります。モバイルノードは、ホームテストINITメッセージが表示されている特派員ノードに関係なく、同じアドレスを使用する場合があります。RFC 3775では、ホームエージェントがモバイルノードが、逆回転したホームテストINITメッセージを受信したときにバインディングキャッシュエントリにあるケアオブアドレスを使用していることを確認する必要があります。別のアドレスがソースアドレスとして使用される場合、メッセージはホームエージェントによって静かに削除されます。このドキュメントでは、モバイルノードのバインディングキャッシュエントリのアドレスの1つである限り、ホームエージェントの実装がホームテストINITメッセージを脱カプセル化して転送する必要があります。
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.
o ホームエージェントがトンネルモードでIPSECによって保護された逆タンネル付きペイロードメッセージを受信すると、トンネルモードセキュリティアソシエーションは内部IPv6ヘッダーのアドレスに基づいているため、外側のIPv6ヘッダーで使用されるソースアドレスはIPSECとは無関係です。したがって、同じIPSECセキュリティアソシエーションを使用して、いずれかのアドレスのいずれかからのペイロードトラフィックに使用できます。逆隔離されたトラフィックで使用されるアドレスのケアは、IKEV2 Exchangeのソースアドレスとして使用されるアドレスのケアとは異なる可能性があることに注意してください。ただし、これは上記の理由により問題を引き起こしません。
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スタックは、特定のフローに属するパケットにどのようなケアに対処する必要があるかを知っています。外側のIPヘッダーの宛先アドレスは、パケットごとにIPSECスタックに動的に伝達される必要があります。カプセル化を実行する場合、またはモバイルIPv6スタックがIPSEC処理が完了した後にパケットにアクセスし、宛先アドレスを変更する必要があります。最初のオプションでは、IPSEC実装の変更が必要です。2番目のオプションでは、外部ヘッダーの宛先アドレスを正しいケアオブアドレスに置き換えるために、転送機能の特別な処理が必要です。上記を達成するための正確な手法は、実装固有です。
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では、モバイルノードは、特定の時間に自宅アドレスごとに単一のアドレスバインディングバインディングのみを持つことができます。ただし、同時に複数の住所ケアバインディングの場合、モバイルノードは、特定の時間に自宅の住所ごとに複数のケアのケアバインディングを持つことができます。これは、同時バインディングサポートを使用したモバイルノードが、1人以上の被害者の住所を効果的にバインドできることを意味します。もう1つの違いは、関与するリスクの程度です。単一のアドレスバインディングバインディングケースでは、再方向攻撃が開始されると、悪意のあるモバイルノードは、通信に自宅アドレスを使用できません（ファイル転送に関するコントロールパケットを受信するなど）。ただし、同時バインディングサポートの場合、悪意のあるモバイルノードは、複数の犠牲者アドレスに加えて、有効なケアオブアドレスに結合する可能性があります。この有効なケアオブアドレスは、悪意のあるモバイルノードによって使用され、ホームエージェントにフローフィルタリングルールを設定し、それにより新しい再方向攻撃を制御および/または起動することができます。
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].
o 拘束力のある承認の新しい成功したステータス：これらのステータスコードは、[RFC3775]のバインディング確認ステータスコードと同じスペースから割り当てられています。
* MCOA NOTCOMPLETE (4)
* MCOA NOT COMPLETE（4）
* MCOA RETURNHOME WO/NDP (5)
* MCOAリターンホームWO/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奇形（164）
* MCOA NON-MCOA BINDING EXISTS (165)
* MCOA非MCOA結合が存在する（165）
* MCOA PROHIBITED (166)
* MCOA禁止（166）
* MCOA UNKNOWN COA (167)
* MCOA不明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.
ワキカワとティエリー・エルンストは、彼らがそこで働いていた当時のこの仕様に関する最初のサポートについて、キオ大学に感謝しています。さらに、著者は、アラモト島、aso、keigo、ジュリエン・チャーボン、テロ・カウピネン、マルティ・クパリネン、ロマン・クンツ、ベンジャミン・リム、ハイッキ・マコネン、ニコラス・モンタヴォント、チャンワの議論とインプットに感謝します。コソ島、松田hiro、宮田小川、岡田小川、上原ke、マサフミワタリ、およびムレイムライのおかげで、この主題に関する以前の研究に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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. Dupont、「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.、Petrescu、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] Soliman、H.、ed。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年6月。
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568] Koodli、R.、ed。、「Mobile IPv6 Fast Handovers」、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.
[モチベーション] Ernst、T.、Montavont、N.、Wakikawa、R.、Ng、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] Ng、C.、Ernst、T.、Paik、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.、Ernst、T.、Ng、C。、およびK. Kuladinithi、「モバイルIPv6におけるマルチホミングの分析」、2008年5月の作業。
[RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753] Mather、J.、ed。、およびM. Kojo、ed。、「Mobility関連用語」、RFC 3753、2004年6月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[RFC4885] Ernst、T。およびH-Y。Lach、「ネットワークモビリティサポート用語」、RFC 4885、2007年7月。
Authors' Addresses
著者のアドレス
Ryuji Wakikawa (Editor) TOYOTA InfoTechnology Center Co., Ltd.
ワキカワRyuji（編集者）Toyota Infotechnology Center Co.、Ltd。
EMail: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)
Vijay Devarapalli Wichorus
Vijay Devarapalli Wichorus
EMail: vijay@wichorus.com
George Tsirtsis Qualcomm
George Tsirtsis Qualcomm
EMail: Tsirtsis@gmail.com
Thierry Ernst INRIA
ティエリー・エルンスト・インリア
EMail: thierry.ernst@inria.fr
Kenichi Nagami INTEC NetCore Inc.
kenichi nagami intec netcore Inc.
EMail: nagami@inetcore.com