[要約] RFC 5213は、モバイルノードの移動性をサポートするためのProxy Mobile IPv6プロトコルに関する仕様です。このRFCの目的は、モバイルノードのIPアドレスの変更を必要とせずに、ネットワーク内での移動を可能にすることです。
Network Working Group S. Gundavelli, Ed.
Request for Comments: 5213 K. Leung
Category: Standards Track Cisco
V. Devarapalli
Wichorus
K. Chowdhury
Starent Networks
B. Patil
Nokia
August 2008
Proxy Mobile IPv6
プロキシモバイルIPv6
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6.
ネットワークベースのモビリティ管理により、モビリティ関連のシグナル伝達に参加することなく、ホストのIPモビリティが可能になります。ネットワークは、ホストに代わってIPモビリティを管理する責任があります。ネットワーク内のモビリティエンティティは、ホストの動きを追跡し、必要なモビリティシグナル伝達を開始する責任があります。この仕様は、ネットワークベースのモビリティ管理プロトコルについて説明し、プロキシモバイルIPv6と呼ばれます。
Table of Contents
目次
1. Introduction ................................................. 4
2. Conventions and Terminology ................................. 5
2.1. Conventions Used in This Document ....................... 5
2.2. Terminology ............................................. 5
3. Proxy Mobile IPv6 Protocol Overview ......................... 9
4. Proxy Mobile IPv6 Protocol Security ......................... 15
4.1. Peer Authorization Database (PAD) Example Entries ....... 16
4.2. Security Policy Database (SPD) Example Entries ........... 17
5. Local Mobility Anchor Operation ............................. 17
5.1. Extensions to Binding Cache Entry Data Structure ......... 18
5.2. Supported Home Network Prefix Models ..................... 19
5.3. Signaling Considerations ................................. 20
5.3.1. Processing Proxy Binding Updates ..................... 20
5.3.2. Initial Binding Registration (New Mobility Session) .. 22
5.3.3. Binding Lifetime Extension (No Handoff) ............. 23
5.3.4. Binding Lifetime Extension (After Handoff) ........... 24
5.3.5. Binding De-Registration ............................. 24
5.3.6. Constructing the Proxy Binding Acknowledgement
Message ............................................. 25
5.4. Multihoming Support ..................................... 27
5.4.1. Binding Cache Entry Lookup Considerations ........... 28
5.5. Timestamp Option for Message Ordering ................... 34
5.6. Routing Considerations ................................... 37
5.6.1. Bi-Directional Tunnel Management ..................... 37
5.6.2. Forwarding Considerations ........................... 38
5.6.3. Explicit Congestion Notification (ECN)
Considerations for Proxy Mobile IPv6 Tunnels ......... 39
5.7. Local Mobility Anchor Address Discovery ................. 40
5.8. Mobile Prefix Discovery Considerations ................... 40
5.9. Route Optimization Considerations ....................... 41
6. Mobile Access Gateway Operation ............................. 41
6.1. Extensions to Binding Update List Entry Data Structure ... 42
6.2. Mobile Node's Policy Profile ............................. 43
6.3. Supported Access Link Types ............................. 44
6.4. Supported Address Configuration Modes ................... 44
6.5. Access Authentication and Mobile Node Identification ..... 45
6.6. Acquiring Mobile Node's Identifier ....................... 45
6.7. Home Network Emulation ................................... 46
6.8. Link-local and Global Address Uniqueness ................. 46
6.9. Signaling Considerations ................................. 48
6.9.1. Binding Registrations ............................... 48
6.9.2. Router Solicitation Messages ......................... 56
6.9.3. Default-Router ....................................... 57
6.9.4. Retransmissions and Rate Limiting ................... 58
6.9.5. Path MTU Discovery ................................... 59
6.10. Routing Considerations ................................... 60
6.10.1. Transport Network ................................... 60
6.10.2. Tunneling and Encapsulation Modes ................... 61
6.10.3. Local Routing ....................................... 62
6.10.4. Tunnel Management ................................... 62
6.10.5. Forwarding Rules ..................................... 62
6.11. Supporting DHCP-Based Address Configuration on the
Access Link ............................................. 64
6.12. Home Network Prefix Renumbering ......................... 66
6.13. Mobile Node Detachment Detection and Resource Cleanup ... 66
6.14. Allowing Network Access to Other IPv6 Nodes ............. 67
7. Mobile Node Operation ....................................... 67
7.1. Moving into a Proxy Mobile IPv6 Domain ................... 67
7.2. Roaming in the Proxy Mobile IPv6 Domain ................. 69
8. Message Formats ............................................. 69
8.1. Proxy Binding Update Message ............................. 69
8.2. Proxy Binding Acknowledgement Message ................... 71
8.3. Home Network Prefix Option ............................... 72
8.4. Handoff Indicator Option ................................. 73
8.5. Access Technology Type Option ........................... 74
8.6. Mobile Node Link-layer Identifier Option ................. 76
8.7. Link-local Address Option ............................... 77
8.8. Timestamp Option ......................................... 77
8.9. Status Values ........................................... 78
9. Protocol Configuration Variables ............................. 80
9.1. Local Mobility Anchor - Configuration Variables ......... 80
9.2. Mobile Access Gateway - Configuration Variables ......... 81
9.3. Proxy Mobile IPv6 Domain - Configuration Variables ....... 82
10. IANA Considerations ......................................... 83
11. Security Considerations ..................................... 84
12. Acknowledgements ............................................. 85
13. References ................................................... 86
13.1. Normative References ..................................... 86
13.2. Informative References ................................... 87
Appendix A. Proxy Mobile IPv6 Interactions with AAA
Infrastructure ..................................... 89
Appendix B. Routing State ....................................... 89
IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC3775]. Mobile IPv6 requires client functionality in the IPv6 stack of a mobile node. Exchange of signaling messages between the mobile node and home agent enables the creation and maintenance of a binding between the mobile node's home address and its care-of address. Mobility as specified in [RFC3775] requires the IP host to send IP mobility management signaling messages to the home agent, which is located in the network.
IPv6ホストのIPモビリティは、モバイルIPv6 [RFC3775]で指定されています。モバイルIPv6には、モバイルノードのIPv6スタックでクライアント機能が必要です。モバイルノードとホームエージェントの間の信号メッセージの交換により、モバイルノードのホームアドレスとそのケアアドレス間のバインディングの作成とメンテナンスが可能になります。[RFC3775]で指定されているモビリティでは、IPホストがネットワークにあるホームエージェントにIPモビリティ管理シグナリングメッセージを送信する必要があります。
Network-based mobility is another approach to solving the IP mobility challenge. It is possible to support mobility for IPv6 nodes without host involvement by extending Mobile IPv6 [RFC3775] signaling messages between a network node and a home agent. This approach to supporting mobility does not require the mobile node to be involved in the exchange of signaling messages between itself and the home agent. A proxy mobility agent in the network performs the signaling with the home agent and does the mobility management on behalf of the mobile node attached to the network. Because of the use and extension of Mobile IPv6 signaling and home agent functionality, this protocol is referred to as Proxy Mobile IPv6 (PMIPv6).
ネットワークベースのモビリティは、IPモビリティチャレンジを解決するためのもう1つのアプローチです。ネットワークノードとホームエージェント間のモバイルIPv6 [RFC3775]シグナリングメッセージを拡張することにより、ホストの関与なしにIPv6ノードのモビリティをサポートすることができます。モビリティをサポートするこのアプローチでは、モバイルノードがそれ自体とホームエージェントの間のシグナリングメッセージの交換に関与する必要はありません。ネットワーク内のプロキシモビリティエージェントは、ホームエージェントとの信号を実行し、ネットワークに添付されたモバイルノードに代わってモビリティ管理を行います。モバイルIPv6シグナル伝達とホームエージェント機能の使用と拡張のため、このプロトコルはプロキシモバイルIPv6（PMIPv6）と呼ばれます。
Network deployments that are designed to support mobility would be agnostic to the capability in the IPv6 stack of the nodes that it serves. IP mobility for nodes that have mobile IP client functionality in the IPv6 stack as well as those nodes that do not, would be supported by enabling Proxy Mobile IPv6 protocol functionality in the network. The advantages of developing a network-based mobility protocol based on Mobile IPv6 are:
モビリティをサポートするように設計されたネットワークの展開は、それが提供するノードのIPv6スタックの機能に不可知論されます。IPv6スタックにモバイルIPクライアント機能を備えたノードのIPモビリティと、そうでないノードは、ネットワーク内のプロキシモバイルIPv6プロトコル機能を有効にすることでサポートされます。モバイルIPv6に基づいてネットワークベースのモビリティプロトコルを開発することの利点は次のとおりです。
o Reuse of home agent functionality and the messages/format used in mobility signaling. Mobile IPv6 is a mature protocol with several implementations that have undergone interoperability testing.
o ホームエージェントの機能と、モビリティシグナル伝達で使用されるメッセージ/形式の再利用。モバイルIPv6は、相互運用性テストを受けたいくつかの実装を備えた成熟したプロトコルです。
o A common home agent would serve as the mobility agent for all types of IPv6 nodes.
o 一般的なホームエージェントは、あらゆるタイプのIPv6ノードのモビリティエージェントとして機能します。
The problem statement and the need for a network-based mobility protocol solution has been documented in [RFC4830]. Proxy Mobile IPv6 is a solution that addresses these issues and requirements.
問題のステートメントとネットワークベースのモビリティプロトコルソリューションの必要性は、[RFC4830]に記録されています。プロキシモバイルIPv6は、これらの問題と要件に対処するソリューションです。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
All the general mobility-related terms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC3775].
このドキュメントで使用されるすべての一般的なモビリティ関連用語は、モバイルIPv6ベース仕様[RFC3775]で定義されていると解釈されます。
This document adopts the terms, Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC4831]. This document also provides the following context-specific explanation to the following terms used in this document.
このドキュメントでは、NetLMMゴールドキュメント[RFC4831]に、Local Mobility Anchor（LMA）およびMobile Access Gateway（MAG）という用語を採用しています。このドキュメントは、このドキュメントで使用されている次の用語の次のコンテキスト固有の説明も提供します。
Proxy Mobile IPv6 Domain (PMIPv6-Domain)
プロキシモバイルIPv6ドメイン（PMIPv6-Domain）
Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in this specification. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile access gateways between which security associations can be set up and authorization for sending Proxy Binding Updates on behalf of the mobile nodes can be ensured.
プロキシモバイルIPv6ドメインとは、この仕様で定義されているプロキシモバイルIPv6プロトコルを使用して、モバイルノードのモビリティ管理が処理されるネットワークを指します。プロキシモバイルIPv6ドメインには、ローカルモビリティアンカーとモバイルアクセスゲートウェイが含まれています。その間にセキュリティ関連を設定でき、モバイルノードに代わってプロキシバインディングアップデートを送信するための許可を確保できます。
Local Mobility Anchor (LMA)
ローカルモビリティアンカー（LMA）
Local Mobility Anchor is the home agent for the mobile node in a Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home network prefix(es) and is the entity that manages the mobile node's binding state. The local mobility anchor has the functional capabilities of a home agent as defined in Mobile IPv6 base specification [RFC3775] with the additional capabilities required for supporting Proxy Mobile IPv6 protocol as defined in this specification.
ローカルモビリティアンカーは、プロキシモバイルIPv6ドメインのモバイルノードのホームエージェントです。これは、モバイルノードのホームネットワークプレフィックス（ES）のトポロジアンカーポイントであり、モバイルノードのバインディング状態を管理するエンティティです。ローカルモビリティアンカーには、モバイルIPv6ベース仕様[RFC3775]で定義されているホームエージェントの機能機能があり、この仕様で定義されているプロキシモバイルIPv6プロトコルをサポートするために必要な追加機能があります。
Mobile Access Gateway (MAG)
モバイルアクセスゲートウェイ（MAG）
Mobile Access Gateway is a function on an access router that manages the mobility-related signaling for a mobile node that is attached to its access link. It is responsible for tracking the mobile node's movements to and from the access link and for signaling the mobile node's local mobility anchor.
モバイルアクセスゲートウェイは、アクセスリンクに接続されているモバイルノードのモビリティ関連の信号を管理するアクセスルーターの関数です。アクセスリンクとの間のモバイルノードの動きを追跡し、モバイルノードのローカルモビリティアンカーを通知する責任があります。
Mobile Node (MN)
モバイルノード（MN）
Throughout this document, the term mobile node is used to refer to an IP host or router whose mobility is managed by the network. The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack node and is not required to participate in any IP mobility related signaling for achieving mobility for an IP address that is obtained in that Proxy Mobile IPv6 domain.
このドキュメント全体で、モバイルノードという用語は、モビリティがネットワークによって管理されているIPホストまたはルーターを参照するために使用されます。モバイルノードは、IPv4のみのノード、IPv6のみのノード、またはデュアルスタックノードである場合があり、そのプロキシモバイルIPv6ドメインで取得されたIPアドレスのモビリティを達成するために、IPモビリティ関連のシグナル伝達に参加する必要はありません。。
LMA Address (LMAA)
LMAアドレス（LMAA）
The global address that is configured on the interface of the local mobility anchor and is the transport endpoint of the bi-directional tunnel established between the local mobility anchor and the mobile access gateway. This is the address to which the mobile access gateway sends the Proxy Binding Update messages. When supporting IPv4 traversal, i.e., when the network between the local mobility anchor and the mobile access gateway is an IPv4 network, this address will be an IPv4 address and will be referred to as IPv4-LMAA, as specified in [IPV4-PMIP6].
ローカルモビリティアンカーのインターフェイスで構成されているグローバルアドレスは、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間に確立された双方向トンネルの輸送エンドポイントです。これは、モバイルアクセスゲートウェイがプロキシバインディングアップデートメッセージを送信するアドレスです。IPv4トラバーサルをサポートする場合、つまり、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間のネットワークがIPv4ネットワークである場合、このアドレスは[IPv4-PMIP6]で指定されているIPv4-LMAAと呼ばれ、IPv4-LMAAと呼ばれます。。
Proxy Care-of Address (Proxy-CoA)
プロキシケアオブアドレス（Proxy-Coa）
Proxy-CoA is the global address configured on the egress interface of the mobile access gateway and is the transport endpoint of the tunnel between the local mobility anchor and the mobile access gateway. The local mobility anchor views this address as the care-of address of the mobile node and registers it in the Binding Cache entry for that mobile node. When the transport network between the mobile access gateway and the local mobility anchor is an IPv4 network and if the care-of address that is registered at the local mobility anchor is an IPv4 address, the term, IPv4- Proxy-CoA is used, as specified in [IPV4-PMIP6].
Proxy-Coaは、モバイルアクセスゲートウェイの出口インターフェイスで構成されたグローバルアドレスであり、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間のトンネルの輸送エンドポイントです。ローカルモビリティアンカーは、このアドレスをモバイルノードのケアアドレスと見なし、そのモバイルノードのバインディングキャッシュエントリに登録します。モバイルアクセスゲートウェイとローカルモビリティアンカーの間のトランスポートネットワークがIPv4ネットワークであり、ローカルモビリティアンカーに登録されているケアアドレスがIPv4アドレスである場合、IPv4-プロキシCoAという用語が使用されます。[IPv4-PMIP6]で指定されています。
Mobile Node's Home Network Prefix (MN-HNP)
モバイルノードのホームネットワークプレフィックス（MN-HNP）
The MN-HNP is a prefix assigned to the link between the mobile node and the mobile access gateway. More than one prefix can be assigned to the link between the mobile node and the mobile access gateway, in which case, all of the assigned prefixes are managed as a set associated with a mobility session. The mobile node configures its interface with one or more addresses from its home network prefix(es). If the mobile node connects to the Proxy Mobile IPv6 domain through multiple interfaces, simultaneously, each of the attached interfaces will be assigned a unique set of home network prefixes, and all the prefixes assigned to a given interface of a mobile node will be managed under one mobility session. For example, home network prefixes P1 and P2 assigned to interface I1 will be managed under one mobility session and prefixes P3, P4, and P5 assigned to interface I2 of the mobile node will be managed under a different mobility session. Additionally, in some configurations the assigned prefix can be of 128-bit prefix length.
MN-HNPは、モバイルノードとモバイルアクセスゲートウェイの間のリンクに割り当てられたプレフィックスです。モバイルノードとモバイルアクセスゲートウェイの間のリンクに複数のプレフィックスを割り当てることができます。この場合、割り当てられたすべてのプレフィックスは、モビリティセッションに関連付けられたセットとして管理されます。モバイルノードは、ホームネットワークプレフィックス（ES）から1つ以上のアドレスを使用してインターフェイスを構成します。モバイルノードが複数のインターフェイスを介してプロキシモバイルIPv6ドメインに接続すると同時に、添付された各インターフェイスにホームネットワークプレフィックスの一意のセットが割り当てられ、モバイルノードの特定のインターフェイスに割り当てられたすべてのプレフィックスが下で管理されます1つのモビリティセッション。たとえば、インターフェイスI1に割り当てられたホームネットワークのプレフィックスP1とP2は、1つのモビリティセッションで管理され、モバイルノードのインターフェイスI2に割り当てられたプレフィックスP3、P4、およびP5は、異なるモビリティセッションで管理されます。さらに、一部の構成では、割り当てられたプレフィックスは128ビットのプレフィックス長さになります。
Mobile Node's Home Address (MN-HoA)
モバイルノードのホームアドレス（MN-HOA）
MN-HoA is an address from a mobile node's home network prefix. The mobile node will be able to use this address as long as it is attached to the access network that is in the scope of that Proxy Mobile IPv6 domain. If the mobile node uses more than one address from its home network prefix(es), any one of these addresses is referred to as mobile node's home address. Unlike in Mobile IPv6 where the home agent is aware of the home address of the mobile node, in Proxy Mobile IPv6, the mobility entities are only aware of the mobile node's home network prefix(es) and are not always aware of the exact address(es) that the mobile node configured on its interface from its home network prefix(es). However, in some configurations and based on the enabled address configuration modes on the access link, the mobility entities in the network can be certain about the exact address(es) configured by the mobile node.
MN-HOAは、モバイルノードのホームネットワークプレフィックスのアドレスです。モバイルノードは、そのプロキシモバイルIPv6ドメインの範囲内にあるアクセスネットワークに接続されている限り、このアドレスを使用できます。モバイルノードがホームネットワークプレフィックスから複数のアドレスを使用している場合、これらのアドレスのいずれかがモバイルノードのホームアドレスと呼ばれます。ホームエージェントがモバイルノードのホームアドレスを認識しているモバイルIPv6とは異なり、プロキシモバイルIPv6では、モビリティエンティティはモバイルノードのホームネットワークプレフィックス（ES）のみを認識しており、正確なアドレスを常に認識しているわけではありません（ES）ホームネットワークプレフィックス（ES）からインターフェイスに構成されたモバイルノード。ただし、一部の構成では、アクセスリンクの有効なアドレス構成モードに基づいて、ネットワーク内のモビリティエンティティは、モバイルノードで構成された正確なアドレスについて確実にすることができます。
Mobile Node's Home Link
This is the link on which the mobile node obtained its layer-3 address configuration for the attached interface after it moved into that Proxy Mobile IPv6 domain. This is the link that conceptually follows the mobile node. The network will ensure the mobile node always sees this link with respect to the layer-3 network configuration, on any access link that it attaches to in that Proxy Mobile IPv6 domain.
これは、モバイルノードがそのプロキシモバイルIPv6ドメインに移動した後、添付のインターフェイスのレイヤー-3アドレス構成を取得したリンクです。これは、概念的にモバイルノードに従うリンクです。ネットワークは、モバイルノードが、そのプロキシモバイルIPv6ドメインで付着するアクセスリンクで、レイヤー-3ネットワーク構成に関するこのリンクを常に表示するようにします。
Multihomed Mobile Node
マルチホームモバイルノード
A mobile node that connects to the same Proxy Mobile IPv6 domain through more than one interface and uses these interfaces simultaneously is referred to as a multihomed mobile node.
複数のインターフェイスを介して同じプロキシモバイルIPv6ドメインに接続し、これらのインターフェイスを同時に使用するモバイルノードは、マルチホームモバイルノードと呼ばれます。
Mobile Node Identifier (MN-Identifier)
モバイルノード識別子（Mn-Identifier）
The identity of a mobile node in the Proxy Mobile IPv6 domain. This is the stable identifier of a mobile node that the mobility entities in a Proxy Mobile IPv6 domain can always acquire and use for predictably identifying a mobile node. This is typically an identifier such as a Network Access Identifier (NAI) [RFC4282] or other identifier such as a Media Access Control (MAC) address.
プロキシモバイルIPv6ドメインのモバイルノードのID。これは、プロキシモバイルIPv6ドメインのモビリティエンティティが常に取得し、モバイルノードを予測できるように使用できるモバイルノードの安定した識別子です。これは通常、ネットワークアクセス識別子（NAI）[RFC4282]などの識別子またはメディアアクセス制御（MAC）アドレスなどのその他の識別子です。
Mobile Node Link-layer Identifier (MN-LL-Identifier)
モバイルノードリンク層識別子（MN-ll-Identifier）
An identifier that identifies the attached interface of a mobile node. For those interfaces that have a link-layer identifier, this identifier can be based on that. The link-layer identifier, in some cases, is generated by the mobile node and conveyed to the mobile access gateway. This identifier of the attached interface must be stable, as seen by any of the mobile access gateways in a given Proxy Mobile IPv6 domain. In some other cases, there might not be any link-layer identifier associated with the mobile node's interface. An identifier value of ALL_ZERO is not considered a valid identifier and cannot be used as an interface identifier.
Policy Profile
ポリシープロファイル
Policy Profile is an abstract term for referring to a set of configuration parameters that are configured for a given mobile node. The mobility entities in the Proxy Mobile IPv6 domain require access to these parameters for providing the mobility management to a given mobile node. The specific details on how the network entities obtain this policy profile is outside the scope of this document.
ポリシープロファイルは、特定のモバイルノードに対して構成されている一連の構成パラメーターを参照するための抽象的な用語です。プロキシモバイルIPv6ドメインのモビリティエンティティは、特定のモバイルノードにモビリティ管理を提供するために、これらのパラメーターにアクセスする必要があります。ネットワークエンティティがこのポリシープロファイルを取得する方法に関する具体的な詳細は、このドキュメントの範囲外です。
Proxy Binding Update (PBU)
プロキシバインディングアップデート（PBU）
A request message sent by a mobile access gateway to a mobile node's local mobility anchor for establishing a binding between the mobile node's home network prefix(es) assigned to a given interface of a mobile node and its current care-of address (Proxy-CoA).
モバイルノードのローカルモビリティアンカーにモバイルアクセスゲートウェイによって送信されたリクエストメッセージは、モバイルノードの特定のインターフェイスに割り当てられたモバイルノードのホームネットワークプレフィックス（ES）と現在のケアオブアドレス（Proxy-CoAの間でバインディングを確立するためのメッセージ）。
Proxy Binding Acknowledgement (PBA)
プロキシバインディング謝辞（PBA）
A reply message sent by a local mobility anchor in response to a Proxy Binding Update message that it received from a mobile access gateway.
モバイルアクセスゲートウェイから受け取ったプロキシバインディングアップデートメッセージに応じて、ローカルモビリティアンカーによって送信された返信メッセージ。
Per-MN-Prefix and Shared-Prefix Models
PER-MN-PREFIXおよび共有-Prefixモデル
The term Per-MN-Prefix model is used to refer to an addressing model where there is a unique network prefix or prefixes assigned for each node. The term Shared-Prefix model is used to refer to an addressing model where the prefix(es) are shared by more than one node. This specification supports the Per-MN-Prefix model and does not support the Shared-Prefix model.
Per-MN-Prefixモデルという用語は、各ノードに割り当てられた一意のネットワークプレフィックスまたはプレフィックスがあるアドレス指定モデルを参照するために使用されます。共有-Prefixモデルという用語は、プレフィックス（ES）が複数のノードで共有されるアドレス指定モデルを参照するために使用されます。この仕様は、Per-MN-Prefixモデルをサポートし、共有-Prefixモデルをサポートしていません。
Mobility Session
モビリティセッション
In the context of Proxy Mobile IPv6 specification, the term mobility session refers to the creation or existence of state associated with the mobile node's mobility binding on the local mobility anchor and on the serving mobile access gateway.
プロキシモバイルIPv6仕様のコンテキストでは、モビリティセッションという用語は、ローカルモビリティアンカーとサービングモバイルアクセスゲートウェイに関連するモバイルノードのモビリティバインディングに関連する状態の作成または存在を指します。
DHCP
DHCP
Throughout this document, the acronym DHCP refers to DHCP for IPv6, as defined in [RFC3315].
このドキュメント全体で、頭字語DHCPは[RFC3315]で定義されているように、IPv6のDHCPを指します。
ALL_ZERO and NON_ZERO
all_zeroとnon_zero
Protocol message fields initialized with value 0 in each byte of the field. For example, an 8-byte link-layer identifier field with the value set to 0 in each of the 8 bytes, or an IPv6 address with the value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is used to refer to any value other than an ALL_ZERO value.
フィールドの各バイトに値0で初期化されたプロトコルメッセージフィールド。たとえば、8バイトのリンクレイヤー識別子フィールドは、8バイトのそれぞれで値が0に設定されているか、16バイトのすべてで値0のIPv6アドレスを備えています。逆に、non_zeroという用語は、all_zero値以外の値を参照するために使用されます。
This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 [RFC3775].
この仕様は、ネットワークベースのモビリティ管理プロトコルについて説明しています。プロキシモバイルIPv6と呼ばれ、モバイルIPv6 [RFC3775]に基づいています。
Proxy Mobile IPv6 protocol is intended for providing network-based IP mobility management support to a mobile node, without requiring the participation of the mobile node in any IP mobility related signaling. The mobility entities in the network will track the mobile node's movements and will initiate the mobility signaling and set up the required routing state.
プロキシモバイルIPv6プロトコルは、IPモビリティ関連のシグナル伝達でモバイルノードの参加を必要とせずに、ネットワークベースのIPモビリティ管理サポートをモバイルノードに提供することを目的としています。ネットワーク内のモビリティエンティティは、モバイルノードの動きを追跡し、モビリティシグナリングを開始し、必要なルーティング状態を設定します。
The core functional entities in the NETLMM infrastructure are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The local mobility anchor is responsible for maintaining the mobile node's reachability state and is the topological anchor point for the mobile node's home network prefix(es). The mobile access gateway is the entity that performs the mobility management on behalf of a mobile node, and it resides on the access link where the mobile node is anchored. The mobile access gateway is responsible for detecting the mobile node's movements to and from the access link and for initiating binding registrations to the mobile node's local mobility anchor. There can be multiple local mobility anchors in a Proxy Mobile IPv6 domain each serving a different group of mobile nodes. The architecture of a Proxy Mobile IPv6 domain is shown in Figure 1.
NetLMMインフラストラクチャのコア機能エンティティは、ローカルモビリティアンカー（LMA）とモバイルアクセスゲートウェイ（MAG）です。ローカルモビリティアンカーは、モバイルノードの到達可能性状態を維持する責任があり、モバイルノードのホームネットワークプレフィックス（ES）のトポロジカルアンカーポイントです。モバイルアクセスゲートウェイは、モバイルノードに代わってモビリティ管理を実行するエンティティであり、モバイルノードが固定されているアクセスリンクにあります。モバイルアクセスゲートウェイは、アクセスリンクとの間のモバイルノードの動きを検出し、モバイルノードのローカルモビリティアンカーへのバインディング登録を開始する責任があります。プロキシモバイルIPv6ドメインには、複数のローカルモビリティアンカーがあり、それぞれ異なるモバイルノードのグループを提供します。プロキシモバイルIPv6ドメインのアーキテクチャを図1に示します。
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
LMAA1 -> | | <-- LMAA2
| |
\\ //\\
\\ // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
| | |
MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4
{MN1} {MN3}
Figure 1: Proxy Mobile IPv6 Domain
図1：プロキシモバイルIPv6ドメイン
When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access link, the mobile access gateway on that access link, after identifying the mobile node and acquiring its identity, will determine if the mobile node is authorized for the network-based mobility management service.
モバイルノードがプロキシモバイルIPv6ドメインに入力してアクセスリンクに接続すると、そのアクセスリンクのモバイルアクセスゲートウェイは、モバイルノードを識別してそのアイデンティティを取得した後、ネットワークベースのモビリティに対してモバイルノードが許可されているかどうかを判断します管理サービス。
If the network determines that the mobile node is authorized for network-based mobility service, the network will ensure that the mobile node using any of the address configuration mechanisms permitted by the network will be able to obtain the address configuration on the connected interface and move anywhere in that Proxy Mobile IPv6 domain. The obtained address configuration includes the address(es) from its home network prefix(es), the default-router address on the link, and other related configuration parameters. From the perspective of each mobile node, the entire Proxy Mobile IPv6 domain appears as a single link, the network ensures that the mobile node does not detect any change with respect to its layer-3 attachment even after changing its point of attachment in the network.
The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack (IPv4/v6) node. Based on the policy profile information that indicates the type of address or prefixes to be assigned for the mobile node in the network, the mobile node will be able to obtain an IPv4, IPv6, or dual IPv4/IPv6 address and move anywhere in that Proxy Mobile IPv6 domain. However, this specification only supports IPv6 address/prefix mobility with the transport network being IPv6. The support for IPv4 addressing or an IPv4 transport network is specified in the companion document [IPV4-PMIP6].
モバイルノードは、IPv4のみのノード、IPv6のみのノード、またはデュアルスタック（IPv4/V6）ノードである場合があります。ネットワーク内のモバイルノードに割り当てられるアドレスまたはプレフィックスのタイプを示すポリシープロファイル情報に基づいて、モバイルノードはIPv4、IPv6、またはデュアルIPv4/IPv6アドレスを取得し、そのプロキシのどこにでも移動できますモバイルIPv6ドメイン。ただし、この仕様はIPv6アドレス/プレフィックスモビリティのみをサポートし、トランスポートネットワークはIPv6です。IPv4アドレス指定またはIPv4トランスポートネットワークのサポートは、コンパニオンドキュメント[IPv4-PMIP6]で指定されています。
If the mobile node connects to the Proxy Mobile IPv6 domain through multiple interfaces and over multiple access networks, the network will allocate a unique set of home network prefixes for each of the connected interfaces. The mobile node will be able to configure address(es) on those interfaces from the respective home network prefix(es). However, if the mobile node performs a handoff by moving its address configuration from one interface to the other, and if the local mobility anchor receives a handoff hint from the serving mobile access gateway about the same, the local mobility anchor will assign the same home network prefix(es) that it previously assigned prior to the handoff. The mobile node will also be able to perform a handoff by changing its point of attachment from one mobile access gateway to a different mobile access gateway using the same interface and will be able to retain the address configuration on the attached interface.
モバイルノードが複数のインターフェイスを介してプロキシモバイルIPv6ドメインに接続し、複数のアクセスネットワークを介して接続すると、ネットワークは、接続された各インターフェイスに一意のホームネットワークプレフィックスセットを割り当てます。モバイルノードは、それぞれのホームネットワークプレフィックス（ES）からこれらのインターフェイスでアドレスを構成することができます。ただし、モバイルノードがアドレス構成を一方のインターフェイスから別のインターフェースに移動することでハンドオフを実行し、ローカルモビリティアンカーがサービングモバイルアクセスゲートウェイからほぼ同じハンドオフヒントを受け取った場合、ローカルモビリティアンカーは同じ家を割り当てますハンドオフの前に以前に割り当てられたネットワークプレフィックス（es）。また、モバイルノードは、同じインターフェイスを使用して、1つのモバイルアクセスゲートウェイから異なるモバイルアクセスゲートウェイに添付のポイントを変更することにより、ハンドオフを実行することもでき、添付のインターフェイスでアドレス構成を保持できます。
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| (Acquire MN-Id and Profile) |
| | |
|--- Rtr Sol --------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | (Allocate MN-HNP(s), Setup BCE and Tunnel)
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| (Set Up Tunnel and Routing) |
| | |
| |==== Bi-Dir Tunnel ===|
| | |
|<--------- Rtr Adv ---| |
| | |
IP Address | |
Configuration | |
| | |
Figure 2: Mobile Node Attachment - Signaling Call Flow
図2：モバイルノード添付ファイル - シグナリングコールフロー
Figure 2 shows the signaling call flow when the mobile node enters the Proxy Mobile IPv6 domain. The Router Solicitation message from the mobile node may arrive at any time after the mobile node's attachment and has no strict ordering relation with the other messages in the call flow.
図2は、モバイルノードがプロキシモバイルIPv6ドメインに入るときのシグナリングコールフローを示しています。モバイルノードからのルーター勧誘メッセージは、モバイルノードの添付ファイルの後でもいつでも到着する場合があり、コールフローの他のメッセージと厳密な順序付け関係がありません。
For updating the local mobility anchor about the current location of the mobile node, the mobile access gateway sends a Proxy Binding Update message to the mobile node's local mobility anchor. Upon accepting this Proxy Binding Update message, the local mobility anchor sends a Proxy Binding Acknowledgement message including the mobile node's home network prefix(es). It also creates the Binding Cache entry and sets up its endpoint of the bi-directional tunnel to the mobile access gateway.
モバイルノードの現在の位置に関するローカルモビリティアンカーを更新するために、モバイルアクセスゲートウェイは、モバイルノードのローカルモビリティアンカーにプロキシバインディングアップデートメッセージを送信します。このプロキシバインディングアップデートメッセージを受け入れると、ローカルモビリティアンカーは、モバイルノードのホームネットワークプレフィックス（ES）を含むプロキシバインド確認メッセージを送信します。また、バインディングキャッシュエントリを作成し、双方向トンネルのエンドポイントをモバイルアクセスゲートウェイに設定します。
The mobile access gateway on receiving the Proxy Binding Acknowledgement message sets up its endpoint of the bi-directional tunnel to the local mobility anchor and also sets up the forwarding for the mobile node's traffic. At this point, the mobile access gateway has all the required information for emulating the mobile node's home link. It sends Router Advertisement messages to the mobile node on the access link advertising the mobile node's home network prefix(es) as the hosted on-link prefix(es).
プロキシバインディング確認メッセージを受信するモバイルアクセスゲートウェイは、ローカルモビリティアンカーへの双方向トンネルのエンドポイントを設定し、モバイルノードのトラフィックの転送も設定します。この時点で、モバイルアクセスゲートウェイには、モバイルノードのホームリンクをエミュレートするために必要なすべての情報があります。ホストされているオンリンクプレフィックス（ES）として、モバイルノードのホームネットワークプレフィックスを宣伝するアクセスリンクのモバイルノードにルーター広告メッセージを送信します。
The mobile node, on receiving these Router Advertisement messages on the access link, attempts to configure its interface using either stateful or stateless address configuration modes, based on the modes that are permitted on that access link as indicated in Router Advertisement messages. At the end of a successful address configuration procedure, the mobile node has one or more addresses from its home network prefix(es).
モバイルノードは、アクセスリンクでこれらのルーター広告メッセージを受信する際に、ルーター広告メッセージに示されているように、そのアクセスリンクで許可されているモードに基づいて、ステートフルまたはステートレスアドレス構成モードのいずれかを使用してインターフェイスを構成しようとします。アドレス構成手順が成功すると、モバイルノードには、ホームネットワークプレフィックス（ES）から1つ以上のアドレスがあります。
After address configuration, the mobile node has one or more valid addresses from its home network prefix(es) at the current point of attachment. The serving mobile access gateway and the local mobility anchor also have proper routing states for handling the traffic sent to and from the mobile node using any one or more of the addresses from its home network prefix(es).
アドレス構成後、モバイルノードには、現在の添付ファイルのポイントにあるホームネットワークプレフィックス（ES）から1つ以上の有効なアドレスがあります。サービングモバイルアクセスゲートウェイとローカルモビリティアンカーには、ホームネットワークプレフィックス（ES）の1つ以上のアドレスを使用して、モバイルノードとの間で送信されるトラフィックを処理するための適切なルーティング状態もあります。
The local mobility anchor, being the topological anchor point for the mobile node's home network prefix(es), receives any packets that are sent to the mobile node by any node in or outside the Proxy Mobile IPv6 domain. The local mobility anchor forwards these received packets to the mobile access gateway through the bi-directional tunnel. The mobile access gateway on other end of the tunnel, after receiving the packet, removes the outer header and forwards the packet on the access link to the mobile node. However, in some cases, the traffic sent from a correspondent node that is locally connected to the mobile access gateway may not be received by the local mobility anchor and may be routed locally by the mobile access gateway (refer to Section 6.10.3).
モバイルノードのホームネットワークプレフィックス（ES）のトポロジアンカーポイントであるローカルモビリティアンカーは、プロキシモバイルIPv6ドメイン内または外側のノードによってモバイルノードに送信されるパケットを受信します。ローカルモビリティアンカーは、これらの受信したパケットを双方向トンネルを通るモバイルアクセスゲートウェイに転送します。トンネルのもう一方の端にあるモバイルアクセスゲートウェイは、パケットを受け取った後、外側のヘッダーを取り外し、アクセスリンクのパケットをモバイルノードに転送します。ただし、場合によっては、モバイルアクセスゲートウェイにローカルに接続されている特派員ノードから送信されたトラフィックは、ローカルモビリティアンカーによって受信されず、モバイルアクセスゲートウェイによってローカルにルーティングされる場合があります（セクション6.10.3を参照）。
The mobile access gateway acts as the default router on the point-to-point link shared with the mobile node. Any packet that the mobile node sends to any correspondent node will be received by the mobile access gateway and will be sent to its local mobility anchor through the bi-directional tunnel. The local mobility anchor on the other end of the tunnel, after receiving the packet, removes the outer header and routes the packet to the destination. However, in some cases, the traffic sent to a correspondent node that is locally connected to the mobile access gateway may be locally routed by the mobile access gateway (refer to Section 6.10.3).
モバイルアクセスゲートウェイは、モバイルノードと共有されるポイントツーポイントリンクのデフォルトルーターとして機能します。モバイルノードが任意の特派員ノードに送信するパケットは、モバイルアクセスゲートウェイによって受信され、双方向トンネルを介してローカルモビリティアンカーに送信されます。トンネルの反対側のローカルモビリティアンカーは、パケットを受け取った後、外側のヘッダーを取り外し、パケットを宛先にルーティングします。ただし、場合によっては、モバイルアクセスゲートウェイにローカルに接続されている特派員ノードに送信されるトラフィックは、モバイルアクセスゲートウェイによってローカルにルーティングされる場合があります（セクション6.10.3を参照）。
+-----+ +-----+ +-----+ +-----+
| MN | |p-MAG| | LMA | |n-MAG|
+-----+ +-----+ +-----+ +-----+
| | | |
| |==Bi-Dir Tunnel=| |
MN Detached | | |
| MN Detached Event | |
| | | |
| |-- DeReg PBU -->| |
| | | |
| | Accept PBU |
| | (Start MinDelayBeforeBCEDelete Timer)
| | | |
| |<-------- PBA --| |
| | | |
MN Attached | | |
| | | MN Attached event received
| | | from MN or from network
| | | (Acquire MN-Id and Profile)
| | | |
|--- Rtr Sol ------------------------------------->|
....
Registration steps as in Fig. 2.
....
| | |==Bi-Dir Tunnel=|
| | | |
|<------------------------------------ Rtr Adv ----|
| | | |
MN retains HoA/HNP(s)
| | | |
Figure 3: Mobile Node Handoff - Signaling Call Flow
図3：モバイルノードハンドオフ - シグナリングコールフロー
Figure 3 shows the signaling call flow for the mobile node's handoff from the previously attached mobile access gateway (p-MAG) to the newly attached mobile access gateway (n-MAG). This call flow only reflects a specific message ordering, it is possible the registration message from the n-MAG may arrive before the de-registration message from the p-MAG arrives.
図3は、以前に添付されたモバイルアクセスゲートウェイ（P-Mag）から新しく添付されたモバイルアクセスゲートウェイ（N-Mag）へのモバイルノードのハンドオフのシグナリングコールフローを示しています。このコールフローは、特定のメッセージの順序を反映しているだけで、P-Magからの登録メッセージが到着する前にn-Magからの登録メッセージが到着する可能性があります。
After obtaining the initial address configuration in the Proxy Mobile IPv6 domain, if the mobile node changes its point of attachment, the mobile access gateway on the previous link will detect the mobile node's detachment from the link. It will signal the local mobility anchor and will remove the binding and routing state for that mobile node. The local mobility anchor, upon receiving this request, will identify the corresponding mobility session for which the request was received, and accepts the request after which it waits for a certain amount of time to allow the mobile access gateway on the new link to update the binding. However, if it does not receive any Proxy Binding Update message within the given amount of time, it will delete the binding cache entry.
プロキシモバイルIPv6ドメインで初期アドレス構成を取得した後、モバイルノードが添付ポイントを変更すると、前のリンクのモバイルアクセスゲートウェイがリンクからのモバイルノードのデタッチメントを検出します。ローカルモビリティアンカーを通知し、そのモバイルノードのバインディングおよびルーティング状態を削除します。ローカルモビリティアンカーは、このリクエストを受信すると、リクエストが受信された対応するモビリティセッションを特定し、新しいリンクのモバイルアクセスゲートウェイを許可するために一定の時間を待ってからリクエストを受け入れます。バインディング。ただし、指定された時間内にプロキシバインディングアップデートメッセージを受信しない場合、バインディングキャッシュエントリが削除されます。
The mobile access gateway on the new access link, upon detecting the mobile node on its access link, will signal the local mobility anchor to update the binding state. After completion of the signaling, the serving mobile access gateway will send the Router Advertisements containing the mobile node's home network prefix(es), and this will ensure the mobile node will not detect any change with respect to the layer-3 attachment of its interface.
新しいアクセスリンクのモバイルアクセスゲートウェイは、アクセスリンクのモバイルノードを検出すると、ローカルモビリティアンカーにバインディング状態を更新します。シグナリングの完了後、サービングモバイルアクセスゲートウェイは、モバイルノードのホームネットワークプレフィックス（ES）を含むルーター広告を送信します。これにより、モバイルノードがインターフェイスのレイヤー-3アタッチメントに関する変更を検出しないようにします。。
The signaling messages, Proxy Binding Update, and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor, MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
モバイルアクセスゲートウェイとローカルモビリティアンカーの間で交換されるシグナリングメッセージ、プロキシバインディングアップデート、およびプロキシバインディングバインディングの承認は、エンドツーエンドのセキュリティ協会を使用して保護する必要があります。
The mobile access gateway and the local mobility anchor MUST implement IPsec for protecting the Proxy Mobile IPv6 signaling messages [RFC4301]. IPsec is a mandatory-to-implement security mechanism. However, additional documents may specify alternative mechanisms and the mobility entities can enable a specific mechanism for securing Proxy Mobile IPv6 signaling messages, based on either a static configuration or after a dynamic negotiation using any standard security negotiation protocols. As in Mobile IPv6 [RFC3775], the use of IPsec for protecting a mobile node's data traffic is optional.
モバイルアクセスゲートウェイとローカルモビリティアンカーは、プロキシモバイルIPv6シグナリングメッセージを保護するためにIPSECを実装する必要があります[RFC4301]。IPSECは、必須のセキュリティメカニズムです。ただし、追加のドキュメントは代替メカニズムを指定する場合があり、モビリティエンティティは、静的構成に基づいて、または標準的なセキュリティネゴシエーションプロトコルを使用した動的交渉後のプロキシモバイルIPv6シグナリングメッセージを保護するための特定のメカニズムを有効にすることができます。モバイルIPv6 [RFC3775]と同様に、モバイルノードのデータトラフィックを保護するためのIPSECの使用はオプションです。
IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection of these messages is not required.
IPSECは、積極性保護を備えた輸送モードのセキュリティペイロード（ESP）[RFC4303]を使用して、信号メッセージを保護するために使用する必要があります。これらのメッセージの機密保護は必要ありません。
IPsec ESP [RFC4303] in tunnel mode MAY be used to protect the mobile node's tunneled data traffic, if protection of data traffic is required.
トンネルモードのIPSEC ESP [RFC4303]は、データトラフィックの保護が必要な場合、モバイルノードのトンネルデータトラフィックを保護するために使用できます。
Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] SHOULD be used to set up security associations between the mobile access gateway and the local mobility anchor to protect the Proxy Binding Update and Proxy Binding Acknowledgement messages. The mobile access gateway and the local mobility anchor can use any of the authentication mechanisms, as specified in [RFC4306], for mutual authentication.
インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）[RFC4306]を使用して、モバイルアクセスゲートウェイとローカルモビリティアンカーのセキュリティ関連を設定して、プロキシバインディングアップデートとプロキシバインディング承認メッセージを保護する必要があります。モバイルアクセスゲートウェイとローカルモビリティアンカーは、相互認証のために[RFC4306]で指定されているように、認証メカニズムを使用できます。
The Mobile IPv6 specification [RFC3775] requires the home agent to prevent a mobile node from creating security associations or creating binding cache entries for another mobile node's home address. In the protocol described in this document, the mobile node is not involved in creating security associations for protecting the signaling messages or sending binding updates. Therefore, the local mobility anchor MUST restrict the creation and manipulation of proxy bindings to specifically authorized mobile access gateways and prefixes. The local mobility anchor MUST be locally configurable to authorize such specific combinations. Additional mechanisms, such as a policy store or Authentication, Authorization, and Accounting (AAA) may be employed, but these are outside the scope of this specification.
モバイルIPv6仕様[RFC3775]では、ホームエージェントがモバイルノードがセキュリティ関連の作成や別のモバイルノードのホームアドレスのバインディングキャッシュエントリを作成しないようにする必要があります。このドキュメントで説明されているプロトコルでは、モバイルノードは、信号メッセージを保護したり、バインディングアップデートを送信するためのセキュリティ関連の作成に関与していません。したがって、ローカルモビリティアンカーは、プロキシバインディングの作成と操作を、具体的に承認されたモバイルアクセスゲートウェイとプレフィックスに制限する必要があります。ローカルモビリティアンカーは、このような特定の組み合わせを承認するためにローカルで構成可能でなければなりません。ポリシーストアや認証、承認、会計（AAA）などの追加のメカニズムが採用される場合がありますが、これらはこの仕様の範囲外です。
Unlike in Mobile IPv6 [RFC3775], these signaling messages do not carry either the Home Address destination option or the Type 2 Routing header, and hence the policy entries and security association selectors stay the same and require no special IPsec related considerations.
モバイルIPv6 [RFC3775]とは異なり、これらのシグナル伝達メッセージはホームアドレスの宛先オプションまたはタイプ2ルーティングヘッダーのいずれでもないため、ポリシーエントリおよびセキュリティアソシエーションセレクターは同じままで、特別なIPSEC関連の考慮事項は必要ありません。
This section describes PAD entries [RFC4301] on the mobile access gateway and the local mobility anchor. The PAD entries are only example configurations. Note that the PAD is a logical concept and a particular mobile access gateway or a local mobility anchor implementation can implement the PAD in any implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation.
このセクションでは、モバイルアクセスゲートウェイとローカルモビリティアンカーのパッドエントリ[RFC4301]について説明します。パッドエントリは、構成の例のみです。パッドは論理的な概念であり、特定のモバイルアクセスゲートウェイであるか、ローカルモビリティアンカー実装により、任意の実装固有の方法でパッドを実装できることに注意してください。パッド状態は、特定の実装でさまざまなデータベースに配布される場合があります。
In the example shown below, the identity of the local mobility anchor is assumed to be lma_identity_1 and the identity of the mobile access gateway is assumed to be mag_identity_1.
以下に示す例では、ローカルモビリティアンカーのアイデンティティはLMA_IDIDETITY_1であると想定されており、モバイルアクセスゲートウェイのIDはmag_identity_1であると想定されています。
mobile access gateway PAD: - IF remote_identity = lma_identity_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address lma_address_1
モバイルアクセスゲートウェイパッド： - remote_identity = lma_identity_1の場合、リモートアドレスlma_address_1のchild_sasを認証し（共有secret/certificate/eap）承認
local mobility anchor PAD: - IF remote_identity = mag_identity_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address mag_address_1
ローカルモビリティアンカーパッド： - remote_identity = mag_identity_1の場合、リモートアドレスのchild_sasを認証し（共有secret/certificate/eap）、承認mag_address_1
Figure 4: PAD Entries
図4：パッドエントリ
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
上記の例の認証メカニズムのリストは網羅的ではありません。パッドに保存されている認証に使用される他の資格情報がある可能性があります。
This section describes the security policy entries [RFC4301] on the mobile access gateway and the local mobility anchor required to protect the Proxy Mobile IPv6 signaling messages. The SPD entries are only example configurations. A particular mobile access gateway or a local mobility anchor implementation could configure different SPD entries as long as they provide the required security.
このセクションでは、モバイルアクセスゲートウェイのセキュリティポリシーエントリ[RFC4301]と、プロキシモバイルIPv6シグナリングメッセージを保護するために必要なローカルモビリティアンカーについて説明します。SPDエントリは、構成の例のみです。特定のモバイルアクセスゲートウェイまたはローカルモビリティアンカー実装により、必要なセキュリティを提供する限り、異なるSPDエントリを構成できます。
In the example shown below, the identity of the mobile access gateway is assumed to be mag_identity_1, the address of the mobile access gateway is assumed to be mag_address_1, and the address of the local mobility anchor is assumed to be lma_address_1. The acronym MH represents the protocol number for the Mobility Header [RFC3775], while the terms local_mh_type and remote_mh_type stand for local mobility header type and remote mobility header type, respectively.
以下に示す例では、モバイルアクセスゲートウェイのIDはmag_identity_1であると想定され、モバイルアクセスゲートウェイのアドレスはmag_address_1であると想定され、ローカルモビリティアンカーのアドレスはlma_address_1であると想定されます。頭字語MHは、モビリティヘッダー[RFC3775]のプロトコル番号を表しますが、それぞれローカルモビリティヘッダータイプとリモートモビリティヘッダータイプのLocal_mh_typeおよびremote_mh_typeスタンドという用語があります。
mobile access gateway SPD-S:
- IF local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH & (local_mh_type = BU | remote_mh_type = BA)
Then use SA ESP transport mode
Initiate using IDi = mag_identity_1 to address lma_address_1
local mobility anchor SPD-S:
- IF local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH & (local_mh_type = BA | remote_mh_type = BU)
Then use SA ESP transport mode
Figure 5: SPD Entries
図5：SPDエントリ
The local mobility anchor MUST support the home agent function as defined in [RFC3775] and the extensions defined in this specification. A home agent with these modifications and enhanced capabilities for supporting the Proxy Mobile IPv6 protocol is referred to as a local mobility anchor.
ローカルモビリティアンカーは、[RFC3775]で定義されているホームエージェント機能と、この仕様で定義されている拡張機能をサポートする必要があります。プロキシモバイルIPv6プロトコルをサポートするためのこれらの変更と強化された機能を備えたホームエージェントは、ローカルモビリティアンカーと呼ばれます。
This section describes the operational details of the local mobility anchor.
このセクションでは、ローカルモビリティアンカーの運用の詳細について説明します。
Every local mobility anchor MUST maintain a Binding Cache entry for each currently registered mobile node. A Binding Cache entry is a conceptual data structure, described in Section 9.1 of [RFC3775].
すべてのローカルモビリティアンカーは、現在登録されている各モバイルノードのバインディングキャッシュエントリを維持する必要があります。結合キャッシュエントリは、[RFC3775]のセクション9.1で説明されている概念データ構造です。
For supporting this specification, the Binding Cache Entry data structure needs to be extended with the following additional fields.
この仕様をサポートするには、バインディングキャッシュ入力データ構造を次の追加フィールドで拡張する必要があります。
o A flag indicating whether or not this Binding Cache entry is created due to a proxy registration. This flag is set to value 1 for Binding Cache entries that are proxy registrations and is set to value 0 for all other entries.
o このバインディングキャッシュエントリがプロキシ登録により作成されるかどうかを示すフラグ。このフラグは、プロキシ登録であるバインディングキャッシュエントリの値1に設定されており、他のすべてのエントリで0に設定されています。
o The identifier of the registered mobile node, MN-Identifier. This identifier is obtained from the Mobile Node Identifier Option [RFC4283] present in the received Proxy Binding Update message.
o 登録されたモバイルノード、Mn-Identifierの識別子。この識別子は、受信したプロキシバインディングアップデートメッセージに存在するモバイルノード識別子オプション[RFC4283]から取得されます。
o The link-layer identifier of the mobile node's connected interface on the access link. This identifier can be acquired from the Mobile Node Link-layer Identifier option, present in the received Proxy Binding Update message. If the option was not present in the request, this variable length field MUST be set to two (octets) and MUST be initialized to a value of ALL_ZERO.
o アクセスリンク上のモバイルノードの接続インターフェイスのリンク層識別子。この識別子は、受信したプロキシバインディングアップデートメッセージに存在するモバイルノードリンクレイヤー識別子オプションから取得できます。オプションがリクエストに存在しなかった場合、この変数長さフィールドは2つ（オクテット）に設定し、ALL_ZEROの値に初期化する必要があります。
o The link-local address of the mobile access gateway on the point-to-point link shared with the mobile node. This is generated by the local mobility anchor after accepting the initial Proxy Binding Update message.
o モバイルノードと共有されるポイントツーポイントリンクのモバイルアクセスゲートウェイのリンクローカルアドレス。これは、最初のプロキシバインディングアップデートメッセージを受け入れた後、ローカルモビリティアンカーによって生成されます。
o A list of IPv6 home network prefixes assigned to the mobile node's connected interface. The home network prefix(es) may have been statically configured in the mobile node's policy profile, or, they may have been dynamically allocated by the local mobility anchor. Each one of these prefix entries will also include the corresponding prefix length.
o モバイルノードの接続インターフェイスに割り当てられたIPv6ホームネットワークプレフィックスのリスト。ホームネットワークのプレフィックス（ES）は、モバイルノードのポリシープロファイルで静的に構成されている可能性があります。または、ローカルモビリティアンカーによって動的に割り当てられた可能性があります。これらのプレフィックスエントリのそれぞれには、対応するプレフィックスの長さも含まれます。
o The tunnel interface identifier (tunnel-if-id) of the bi-directional tunnel between the local mobility anchor and the mobile access gateway where the mobile node is currently anchored. This is internal to the local mobility anchor. The tunnel interface identifier is acquired during the tunnel creation.
o ローカルモビリティアンカーとモバイルノードが現在固定されているモバイルアクセスゲートウェイの間の双方向トンネルのトンネルインターフェイス識別子（トンネル-IF-ID）。これは、ローカルモビリティアンカーの内部です。トンネル界面識別子は、トンネルの作成中に取得されます。
o The access technology type, by which the mobile node is currently attached. This is obtained from the Access Technology Type option, present in the Proxy Binding Update message.
o 現在、モバイルノードが添付されているアクセステクノロジータイプ。これは、プロキシバインディングアップデートメッセージに存在するアクセステクノロジータイプオプションから取得されます。
o The 64-bit timestamp value of the most recently accepted Proxy Binding Update message sent for this mobile node. This is the time of day on the local mobility anchor, when the message was received. If the Timestamp option is not present in the Proxy Binding Update message (i.e., when the sequence-number-based scheme is in use), the value MUST be set to ALL_ZERO.
o このモバイルノードに送信された、最近受け入れられたプロキシバインディングアップデートメッセージの64ビットタイムスタンプ値。これは、メッセージが受信されたときのローカルモビリティアンカーの時刻です。プロキシバインディングアップデートメッセージにタイムスタンプオプションが存在しない場合（つまり、シーケンス番号ベースのスキームが使用されている場合）、値はall_zeroに設定する必要があります。
Typically, any one of the mobile node's home network prefixes from its mobility session may be used as a key for locating its Binding Cache entry in all cases except when there has been a handoff of the mobile node's session to a new mobile access gateway, and that mobile access gateway is unaware of the home network prefix(es) assigned to that mobility session. In such handoff cases, the Binding Cache entry can be located under the considerations specified in Section 5.4.1.
通常、モビリティセッションのモバイルノードのホームネットワークプレフィックスのいずれかが、モバイルノードのセッションが新しいモバイルアクセスゲートウェイにハンドオフがあった場合を除き、すべての場合にバインディングキャッシュエントリを見つけるためのキーとして使用できます。そのモバイルアクセスゲートウェイは、そのモビリティセッションに割り当てられたホームネットワークのプレフィックス（ES）を認識していません。このようなハンドオフの場合、バインディングキャッシュエントリは、セクション5.4.1で指定された考慮事項の下に配置できます。
This specification supports the Per-MN-Prefix model and does not support the Shared-Prefix model. According to the Per-MN-Prefix model, home network prefix(es) assigned to a mobile node are for that mobile node's exclusive use and no other node shares an address from that prefix (other than the Subnet-Router anycast address [RFC4291] that is used by the mobile access gateway hosting that prefix on that link).
この仕様は、Per-MN-Prefixモデルをサポートし、共有-Prefixモデルをサポートしていません。PER-MN-PREFIXモデルによると、モバイルノードに割り当てられたホームネットワークプレフィックス（ES）はそのモバイルノードの排他的使用用であり、他のノードはそのプレフィックスのアドレスを共有していません（サブネットルーターANYCASTアドレス[RFC4291]以外これは、そのリンクのプレフィックスをホストするモバイルアクセスゲートウェイで使用されます）。
There may be more than one prefix assigned to a given interface of the mobile node; all of those assigned prefixes MUST be unique to that mobile node, and all are part of exactly one mobility session. If the mobile node simultaneously attaches to the Proxy Mobile IPv6 domain through multiple interfaces, each of the attached interfaces MUST be assigned one or more unique prefixes. Prefixes that are not assigned to the same interface MUST NOT be managed under the same mobility session.
モバイルノードの特定のインターフェイスに割り当てられたプレフィックスが複数ある場合があります。割り当てられたプレフィックスはすべて、そのモバイルノードに固有のものでなければならず、すべてが1つのモビリティセッションの一部です。モバイルノードが複数のインターフェイスを介してプロキシモバイルIPv6ドメインに同時に接続する場合、添付された各インターフェイスに1つ以上の一意のプレフィックスを割り当てる必要があります。同じインターフェイスに割り当てられていないプレフィックスは、同じモビリティセッションで管理してはなりません。
The mobile node's home network prefix(es) assigned to a given interface of a mobile node (part of a mobility session) will be hosted on the access link where the mobile node is attached (using that interface). The local mobility anchor is not required to perform any proxy Neighbor Discovery (ND) operations [RFC4861] for defending the mobile node's home address(es), as the prefixes are not locally hosted on the local mobility anchor. However, from the routing perspective, the home network prefix(es) is topologically anchored on the local mobility anchor.
モバイルノード（モビリティセッションの一部）の特定のインターフェイスに割り当てられたモバイルノードのホームネットワークプレフィックス（ES）は、モバイルノードが添付されているアクセスリンク（そのインターフェイスを使用）でホストされます。ローカルモビリティアンカーは、モバイルノードのホームアドレス（ES）を防御するために、プロキシNeighbor Discovery（ND）操作[RFC4861]を実行する必要はありません。プレフィックスはローカルモビリティアンカーでローカルにホストされていないためです。ただし、ルーティングの観点から見ると、ホームネットワークのプレフィックスは、ローカルモビリティアンカーにトポロジカルに固定されています。
This section provides the rules for processing the signaling messages. The processing rules specified in this section and other related sections are chained and are in a specific order. When applying these considerations for processing the signaling messages, the specified order MUST be maintained.
このセクションでは、信号メッセージを処理するためのルールを提供します。このセクションおよびその他の関連セクションで指定された処理ルールはチェーンされており、特定の順序であります。信号メッセージを処理するためにこれらの考慮事項を適用する場合、指定された注文を維持する必要があります。
1. The received Proxy Binding Update message (a Binding Update message with the (P) flag set to value of 1, format specified in Section 8.1) MUST be authenticated as described in Section 4. When IPsec is used for message authentication, the Security Parameter Index (SPI) in the IPsec header [RFC4306] of the received packet is needed for locating the security association, for authenticating the Proxy Binding Update message.
1. 受信したプロキシバインディング更新メッセージ（（p）フラグを1の値に設定したバインディングアップデートメッセージ、セクション8.1で指定された形式）は、セクション4で説明されているように認証する必要があります。（SPI）受け取ったパケットのIPSECヘッダー[RFC4306]では、プロキシバインディングアップデートメッセージを認証するために、セキュリティ協会を見つけるために必要です。
2. The local mobility anchor MUST observe the rules described in Section 9.2 of [RFC3775] when processing the Mobility Header in the received Proxy Binding Update message.
2. ローカルモビリティアンカーは、受信したプロキシバインディングアップデートメッセージのモビリティヘッダーを処理する際に、[RFC3775]のセクション9.2に記載されているルールを観察する必要があります。
3. The local mobility anchor MUST ignore the check, specified in Section 10.3.1 of [RFC3775], related to the presence of the Home Address destination option in the Proxy Binding Update message.
3. ローカルモビリティアンカーは、プロキシバインディングアップデートメッセージのホームアドレス宛先オプションの存在に関連する[RFC3775]のセクション10.3.1で指定されているチェックを無視する必要があります。
4. The local mobility anchor MUST identify the mobile node from the identifier present in the Mobile Node Identifier option [RFC4283] of the Proxy Binding Update message. If the Mobile Node Identifier option is not present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with Status field set to MISSING_MN_IDENTIFIER_OPTION (Missing Mobile Node Identifier option) and the identifier in the Mobile Node Identifier option carried in the message MUST be set to a zero length identifier.
4. ローカルモビリティアンカーは、プロキシバインディングアップデートメッセージのモバイルノード識別子オプション[RFC4283]に存在する識別子からモバイルノードを識別する必要があります。モバイルノード識別子オプションがプロキシバインディングアップデートメッセージに存在しない場合、ローカルモビリティアンカーはリクエストを拒否し、ステータスフィールドをMissing_mn_identifier_optionに設定してプロキシバインディング確認メッセージを送信する必要があります（モバイルノード識別子オプションがありません）および携帯電話の識別子はメッセージに掲載されたノード識別子オプションは、ゼロ長さ識別子に設定する必要があります。
5. The local mobility anchor MUST apply the required policy checks, as explained in Section 4, to verify that the sender is a trusted mobile access gateway authorized to send Proxy Binding Update messages on behalf of this mobile node.
5. セクション4で説明されているように、ローカルモビリティアンカーは、このモバイルノードに代わってプロキシバインディングアップデートメッセージを送信することが許可された信頼できるモバイルアクセスゲートウェイであることを確認するために、必要なポリシーチェックを適用する必要があります。
6. If the local mobility anchor determines that the requesting node is not authorized to send Proxy Binding Update messages for the identified mobile node, it MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy binding updates).
6. ローカルモビリティアンカーが、要求ノードが識別されたモバイルノードのプロキシバインディングアップデートメッセージを送信する権限がないと判断した場合、リクエストを拒否し、MAG_NOT_NOT_AUTHORIZED_FOR_PROXY_REGに設定されたステータスフィールドにプロキシバインド確認メッセージを送信する必要があります（プロキシを送信する権限はありませんバインディングの更新）。
7. If the local mobility anchor cannot identify the mobile node based on the identifier present in the Mobile Node Identifier option [RFC4283] of the Proxy Binding Update message, it MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE (Not a local mobility anchor for this mobile node).
7. ローカルモビリティアンカーが、プロキシバインディングアップデートメッセージのモバイルノード識別子オプション[RFC4283]に存在する識別子に基づいてモバイルノードを識別できない場合、リクエストを拒否し、not_lma_for_this_mobile_node_node_nodeに設定されたステータスフィールドにプロキシバインド確認メッセージを送信する必要があります。（このモバイルノードのローカルモビリティアンカーではありません）。
8. If the local mobility anchor determines that the mobile node is not authorized for the network-based mobility management service, it MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to PROXY_REG_NOT_ENABLED (Proxy Registration not enabled).
8. ローカルモビリティアンカーが、モバイルノードがネットワークベースのモビリティ管理サービスに対して承認されていないと判断した場合、リクエストを拒否し、proxy_reg_not_enabledに設定されたステータスフィールドを使用してプロキシバインディング確認メッセージを送信する必要があります（プロキシ登録は有効にされていません）。
9. The local mobility anchor MUST apply the considerations specified in Section 5.5 for processing the Sequence Number field and the Timestamp option (if present) in the Proxy Binding Update message.
9. ローカルモビリティアンカーは、プロキシバインディングアップデートメッセージのシーケンス番号フィールドとタイムスタンプオプション（存在する場合）を処理するためにセクション5.5で指定された考慮事項を適用する必要があります。
10. If there is no Home Network Prefix option(s) (with any value) present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing Home Network Prefix option).
10. プロキシバインディングアップデートメッセージにホームネットワークのプレフィックスオプション（任意の値）が存在しない場合、ローカルモビリティアンカーはリクエストを拒否し、[ステータス]フィールドをMissing_home_network_prefix_optionに設定してプロキシバインディング確認メッセージを送信する必要があります（ホームネットワークの欠落プレフィックスオプション）。
11. If the Handoff Indicator option is not present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MISSING_HANDOFF_INDICATOR_OPTION (Missing Handoff Indicator option).
11. プロキシバインディングアップデートメッセージにハンドオフインジケーターオプションが存在しない場合、ローカルモビリティアンカーはリクエストを拒否し、[ハンドオフインジケータオプションの欠落）に設定されているステータスフィールドを使用してプロキシバインディング確認メッセージを送信する必要があります。
12. If the Access Technology Type option is not present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MISSING_ACCESS_TECH_TYPE_OPTION (Missing Access Technology Type option).
12.
13. Considerations specified in Section 5.4.1 MUST be applied for performing the Binding Cache entry existence test. If those checks specified in Section 5.4.1 result in associating the received Proxy Binding Update message to a new mobility session creation request, considerations from Section 5.3.2 (Initial Binding Registration - New Mobility Session), MUST be applied. If those checks result in associating the request to an existing mobility session, the following checks determine the next set of processing rules that need to be applied.
13. セクション5.4.1で指定された考慮事項は、バインディングキャッシュ入力の存在テストを実行するために適用する必要があります。セクション5.4.1で指定されたこれらのチェックの結果、受信したプロキシバインディングアップデートメッセージを新しいモビリティセッションの作成要求に関連付ける場合、セクション5.3.2（初期バインディング登録 - 新しいモビリティセッション）からの考慮事項を適用する必要があります。これらのチェックがリクエストを既存のモビリティセッションに関連付ける場合、次のチェックにより、適用する必要がある次の処理ルールのセットが決定されます。
* If the received Proxy Binding Update message has the lifetime value of zero, considerations from Section 5.3.5 (Binding De-Registration) MUST be applied.
* 受信したプロキシバインディングアップデートメッセージの生涯値はゼロの場合、セクション5.3.5（バインディング解除）からの考慮事項を適用する必要があります。
* If the Proxy-CoA in the Binding Cache entry matches the source address of the request (or the address in the Alternate Care-of Address option, if the option is present), considerations from Section 5.3.3 (Binding LIfetime Extension - No handoff) MUST be applied.
*
* For all other cases, considerations from Section 5.3.4 (Binding Lifetime Extension - After handoff) MUST be applied.
* 他のすべてのケースでは、セクション5.3.4（ハンドオフ後の寿命延長 - 結合寿命延長）からの考慮事項を適用する必要があります。
14. When sending the Proxy Binding Acknowledgement message with any Status field value, the message MUST be constructed as specified in Section 5.3.6.
14. 任意のステータスフィールド値を使用してプロキシバインディング確認メッセージを送信する場合、メッセージはセクション5.3.6で指定されているように構築する必要があります。
1. If there is at least one instance of the Home Network Prefix option present in the Proxy Binding Update message with the prefix value set to ALL_ZERO, the local mobility anchor MUST allocate one or more home network prefixes to the mobile node and assign it to the new mobility session created for the mobile node. The local mobility anchor MUST ensure the allocated prefix(es) is not in use by any other node or mobility session. The decision on how many prefixes to be allocated for the attached interface can be based on a global policy or a policy specific to that mobile node. However, when stateful address autoconfiguration using DHCP is supported on the link, considerations from Section 6.11 MUST be applied for the prefix assignment.
1. プロキシバインディングアップデートメッセージに存在するホームネットワークのプレフィックスオプションの少なくとも1つのインスタンスがALL_ZEROに設定されたプレフィックス値を使用して、ローカルモビリティアンカーは1つ以上のホームネットワークプレフィックスをモバイルノードに割り当て、新しいものに割り当てる必要があります。モバイルノード用に作成されたモビリティセッション。ローカルモビリティアンカーは、割り当てられたプレフィックス（ES）が他のノードまたはモビリティセッションで使用されていないことを確認する必要があります。添付のインターフェイスに割り当てられるプレフィックスの数に関する決定は、そのモバイルノードに固有のグローバルポリシーまたはポリシーに基づいています。ただし、DHCPを使用したStateful Address Autoconfigurationがリンクでサポートされている場合、プレフィックス割り当てにはセクション6.11からの考慮事項を適用する必要があります。
2. If the local mobility anchor is unable to allocate any home network prefix for the mobile node, it MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to 130 (Insufficient resources).
2. ローカルモビリティアンカーがモバイルノードにホームネットワークプレフィックスを割り当てることができない場合、リクエストを拒否し、ステータスフィールドが130に設定されたプロキシバインディング確認メッセージを送信する必要があります（リソースが不十分です）。
3. If there are one or more Home Network Prefix options present in the Proxy Binding Update message (with each of the prefixes set to a NON_ZERO value), the local mobility anchor, before accepting that request, MUST ensure each one of those prefixes is owned by the local mobility anchor, and further that the mobile node is authorized to use these prefixes. If the mobile node is not authorized to use any one or more of those prefixes, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node not authorized for one or more of the requesting home network prefixes).
3. プロキシバインディングアップデートメッセージに1つ以上のホームネットワークプレフィックスオプションが存在する場合（各プレフィックスがnon_zero値に設定されている各プレフィックスを使用して）、ローカルモビリティアンカーは、その要求を受け入れる前に、それらのプレフィックスのそれぞれが所有されていることを確認する必要があります。ローカルモビリティアンカー、さらにモバイルノードがこれらのプレフィックスを使用することを許可されていること。モバイルノードがそれらのプレフィックスの1つ以上を使用することを許可されていない場合、ローカルモビリティアンカーはリクエストを拒否し、[ステータス]フィールドをnot_authorized_for_for_home_network_prefixに設定してプロキシバインディング確認メッセージを送信する必要があります。ホームネットワークのプレフィックスの要求）。
4. Upon accepting the request, the local mobility anchor MUST create a Binding Cache entry for the mobile node. It must set the fields in the Binding Cache entry to the accepted values for that registration.
4. リクエストを受け入れると、ローカルモビリティアンカーはモバイルノードのバインディングキャッシュエントリを作成する必要があります。バインディングキャッシュエントリ内のフィールドを、その登録の受け入れられた値に設定する必要があります。
5. If there is no existing bi-directional tunnel to the mobile access gateway that sent the request, the local mobility anchor MUST establish a bi-directional tunnel to that mobile access gateway. Considerations from Section 5.6.1 MUST be applied for managing the dynamically created bi-directional tunnel.
5. リクエストを送信したモバイルアクセスゲートウェイへの既存の双方向トンネルがない場合、ローカルモビリティアンカーは、そのモバイルアクセスゲートウェイに双方向トンネルを確立する必要があります。セクション5.6.1の考慮事項は、動的に作成された双方向トンネルの管理に適用する必要があります。
6. The local mobility anchor MUST create a prefix route(s) over the tunnel to the mobile access gateway for forwarding any traffic received for the mobile node's home network prefix(es) associated with this mobility session. The created tunnel and the routing state MUST result in the forwarding behavior on the local mobility anchor as specified in Section 5.6.2.
6. ローカルモビリティアンカーは、このモビリティセッションに関連付けられているモバイルノードのホームネットワークプレフィックス（ES）のトラフィックを転送するために、モバイルアクセスゲートウェイへのトンネル上にプレフィックスルートを作成する必要があります。作成されたトンネルとルーティング状態は、セクション5.6.2で指定されているように、ローカルモビリティアンカーの転送挙動につながる必要があります。
7. The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). The message MUST be constructed as specified in Section 5.3.6.
7. ローカルモビリティアンカーは、ステータスフィールドが0に設定されたプロキシバインディング確認メッセージを送信する必要があります（プロキシバインディングアップデートは受け入れられます）。メッセージは、セクション5.3.6で指定されているように構築する必要があります。
1. Upon accepting the Proxy Binding Update message for extending the binding lifetime, received from the same mobile access gateway (if the Proxy-CoA in the Binding Cache entry is the same as the Proxy-CoA in the request) that last updated the binding, the local mobility anchor MUST update the Binding Cache entry with the accepted registration values.
1. バインドキャッシュエントリのプロキシCOAがリクエストのプロキシCOAと同じである場合、同じモバイルアクセスゲートウェイから受信したバインディングライフタイムを拡張するためのプロキシバインディングアップデートメッセージを受け入れると、バインディングを最後に更新しました。ローカルモビリティアンカーは、受け入れられた登録値でバインディングキャッシュエントリを更新する必要があります。
2. The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). The message MUST be constructed as specified in Section 5.3.6.
2. ローカルモビリティアンカーは、ステータスフィールドが0に設定されたプロキシバインディング確認メッセージを送信する必要があります（プロキシバインディングアップデートは受け入れられます）。メッセージは、セクション5.3.6で指定されているように構築する必要があります。
1. Upon accepting the Proxy Binding Update message for extending the binding lifetime, received from a new mobile access gateway (if the Proxy-CoA in the Binding Cache entry does not match the Proxy-CoA in the request) where the mobile node's mobility session is handed off, the local mobility anchor MUST update the Binding Cache entry with the accepted registration values.
1. モバイルノードのモビリティセッションが渡される場所で、新しいモバイルアクセスゲートウェイ（バインディングキャッシュエントリのプロキシCOAがプロキシCOAと一致しない場合）から受け取ったバインディングライフタイムを拡張するためのプロキシバインドアップデートメッセージを受け入れるとオフ、ローカルモビリティアンカーは、受け入れられた登録値でバインディングキャッシュエントリを更新する必要があります。
2. The local mobility anchor MUST remove the previously created route(s) for the mobile node's home network prefix(es) associated with this mobility session. Additionally, if there are no other mobile nodes sharing the dynamically created bi-directional tunnel to the previous mobile access gateway, the tunnel SHOULD be deleted, applying considerations from section 5.6.1 (if the tunnel is a dynamically created tunnel and not a fixed pre-established tunnel).
2. ローカルモビリティアンカーは、このモビリティセッションに関連付けられたモバイルノードのホームネットワークプレフィックス（ES）の以前に作成されたルートを削除する必要があります。さらに、動的に作成された双方向トンネルを以前のモバイルアクセスゲートウェイに共有する他のモバイルノードがない場合、トンネルを削除して、セクション5.6.1から考慮事項を適用する必要があります（トンネルが動的に作成されたトンネルであり、固定ではない場合事前に確立されたトンネル）。
3. If there is no existing bi-directional tunnel to the mobile access gateway that sent the request, the local mobility anchor MUST establish a bi-directional tunnel to that mobile access gateway. Considerations from Section 5.6.1 MUST be applied for managing the dynamically created bi-directional tunnel.
3. リクエストを送信したモバイルアクセスゲートウェイへの既存の双方向トンネルがない場合、ローカルモビリティアンカーは、そのモバイルアクセスゲートウェイに双方向トンネルを確立する必要があります。セクション5.6.1の考慮事項は、動的に作成された双方向トンネルの管理に適用する必要があります。
4. The local mobility anchor MUST create prefix route(s) over the tunnel to the mobile access gateway for forwarding any traffic received for the mobile node's home network prefix(es) associated with that mobility session. The created tunnel and routing state MUST result in the forwarding behavior on the local mobility anchor as specified in Section 5.6.2.
4. ローカルモビリティアンカーは、そのモビリティセッションに関連付けられたモバイルノードのホームネットワークプレフィックス（ES）のトラフィックを転送するために、モバイルアクセスゲートウェイへのトンネル上にプレフィックスルートを作成する必要があります。作成されたトンネルとルーティング状態は、セクション5.6.2で指定されているように、ローカルモビリティアンカーの転送挙動につながる必要があります。
5. The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). The message MUST be constructed as specified in Section 5.3.6.
5. ローカルモビリティアンカーは、ステータスフィールドが0に設定されたプロキシバインディング確認メッセージを送信する必要があります（プロキシバインディングアップデートは受け入れられます）。メッセージは、セクション5.3.6で指定されているように構築する必要があります。
1. If the received Proxy Binding Update message with the lifetime value of zero, has a Source Address in the IPv6 header (or the address in the Alternate Care-of Address option, if the option is present) different from what is present in the Proxy-CoA field in the Binding Cache entry, the local mobility anchor MUST ignore the request.
1. ゼロのライフタイム値を持つプロキシバインディングアップデートメッセージが受信した場合、Proxy-に存在するものとは異なるIPv6ヘッダー（またはオプションが存在する場合、代替ケアオブアドレスオプションのアドレス）にソースアドレスを持っている場合 - COAフィールドバインディングキャッシュエントリでは、ローカルモビリティアンカーはリクエストを無視する必要があります。
2. Upon accepting the Proxy Binding Update message, with the lifetime value of zero, the local mobility anchor MUST wait for MinDelayBeforeBCEDelete amount of time, before it deletes the Binding Cache entry. However, it MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). The message MUST be constructed as specified in Section 5.3.6.
2. ゼロの生涯値を持つプロキシバインディングアップデートメッセージを受け入れると、ローカルモビリティアンカーは、バインディングキャッシュのエントリを削除する前に、MindElaybebebcedeleteの時間を待つ必要があります。ただし、ステータスフィールドを0に設定してプロキシバインディング確認メッセージを送信する必要があります（プロキシバインディングアップデートは受け入れられます）。メッセージは、セクション5.3.6で指定されているように構築する必要があります。
* During this wait period, the local mobility anchor SHOULD drop the mobile node's data traffic.
* この待機期間中、ローカルモビリティアンカーはモバイルノードのデータトラフィックをドロップする必要があります。
* During this wait period, if the local mobility anchor receives a valid Proxy Binding Update message for the same mobility session with the lifetime value of greater than zero, and if that request is accepted, then the Binding Cache entry MUST NOT be deleted, but must be updated with the newly accepted registration values, and the wait period should be ended.
* この待機期間中、ローカルモビリティアンカーがゼロを超えるライフタイム値と同じモビリティセッションに対して有効なプロキシバインディングアップデートメッセージを受信し、その要求が受け入れられた場合、バインディングキャッシュエントリを削除する必要はありませんが、新たに受け入れられた登録値で更新され、待機期間を終了する必要があります。
* By the end of this wait period, if the local mobility anchor did not receive any valid Proxy Binding Update messages for this mobility session, then it MUST delete the Binding Cache entry and remove the routing state created for that mobility session. The local mobility anchor can potentially reassign the prefix(es) associated with this mobility session to other mobile nodes.
* この待機期間の終わりまでに、ローカルモビリティアンカーがこのモビリティセッションの有効なプロキシバインディングアップデートメッセージを受信しなかった場合、バインディングキャッシュエントリを削除し、そのモビリティセッション用に作成されたルーティング状態を削除する必要があります。ローカルモビリティアンカーは、このモビリティセッションに関連付けられたプレフィックスを他のモバイルノードに再割り当てする可能性があります。
o The local mobility anchor, when sending the Proxy Binding Acknowledgement message to the mobile access gateway, MUST construct the message as specified below.
o ローカルモビリティアンカーは、モバイルアクセスゲートウェイにプロキシバインディング確認メッセージを送信するときに、以下に指定されたメッセージを作成する必要があります。
IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header
- BA /* P flag must be set to value of 1 */
Mobility Options
- Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional)
Figure 6: Proxy Binding Acknowledgement Message Format
図6：プロキシバインディングの確認メッセージ形式
o The Source Address field in the IPv6 header of the message MUST be set to the destination address of the received Proxy Binding Update message.
o メッセージのIPv6ヘッダーのソースアドレスフィールドは、受信したプロキシバインディングアップデートメッセージの宛先アドレスに設定する必要があります。
o The Destination Address field in the IPv6 header of the message MUST be set to the source address of the received Proxy Binding Update message. When there is no Alternate Care-of Address option present in the request, the destination address is the same as the Proxy-CoA; otherwise, the address may not be the same as the Proxy-CoA.
o メッセージのIPv6ヘッダーの宛先アドレスフィールドは、受信したプロキシバインディングアップデートメッセージのソースアドレスに設定する必要があります。リクエストに代替のケアオプションオプションが存在しない場合、宛先アドレスはプロキシCoAと同じです。それ以外の場合、アドレスはプロキシCOAと同じではない場合があります。
o The Mobile Node Identifier option [RFC4283] MUST be present. The identifier field in the option MUST be copied from the Mobile Node Identifier option in the received Proxy Binding Update message. If the option was not present in the request, the identifier in the option MUST be set to a zero length identifier.
o モバイルノード識別子オプション[RFC4283]が存在する必要があります。オプションの識別子フィールドは、受信したプロキシバインディングアップデートメッセージのモバイルノード識別子オプションからコピーする必要があります。リクエストにオプションが存在しなかった場合、オプションの識別子はゼロ長さ識別子に設定する必要があります。
o At least one Home Network Prefix option MUST be present.
o 少なくとも1つのホームネットワークプレフィックスオプションが存在する必要があります。
* If the Status field is set to a value greater than or equal to 128, i.e., if the Proxy Binding Update is rejected, all the Home Network Prefix options that were present in the request (along with their prefix values) MUST be present in the reply. But, if there was no Home Network Prefix option present in the request, then there MUST be only one Home Network Prefix option with the value in the option set to ALL_ZERO.
* ステータスフィールドが128以上の値に設定されている場合、つまりプロキシバインディングの更新が拒否された場合、リクエストに存在するすべてのホームネットワークプレフィックスオプション（プレフィックス値とともに）が存在する必要があります。返事。ただし、リクエストにホームネットワークのプレフィックスオプションが存在しない場合は、オプションの値がALL_ZEROに設定されたホームネットワークプレフィックスオプションが1つだけある必要があります。
* For all other cases, there MUST be a Home Network Prefix option for each of the assigned home network prefixes (for that mobility session), and with the prefix value in the option set to the allocated prefix value.
* 他のすべての場合、割り当てられたホームネットワークプレフィックスごとにホームネットワークプレフィックスオプション（そのモビリティセッション用）、およびオプションのプレフィックス値が割り当てられたプレフィックス値に設定されている必要があります。
o The Handoff Indicator option MUST be present. The handoff indicator field in the option MUST be copied from the Handoff Indicator option in the received Proxy Binding Update message. If the option was not present in the request, the value in the option MUST be set to zero.
o ハンドオフインジケータオプションが存在する必要があります。オプションのハンドオフインジケータフィールドは、受信したプロキシバインディングアップデートメッセージのハンドオフインジケーターオプションからコピーする必要があります。リクエストにオプションが存在しなかった場合、オプションの値はゼロに設定する必要があります。
o The Access Technology Type option MUST be present. The access technology type field in the option MUST be copied from the Access Technology Type option in the received Proxy Binding Update message. If the option was not present in the request, the value in the option MUST be set to zero.
o アクセステクノロジータイプオプションが存在する必要があります。オプションのアクセステクノロジータイプフィールドは、受信したプロキシバインディングアップデートメッセージのアクセステクノロジータイプオプションからコピーする必要があります。リクエストにオプションが存在しなかった場合、オプションの値はゼロに設定する必要があります。
o The Timestamp option MUST be present only if the same option was present in the received Proxy Binding Update message and MUST NOT be present otherwise. Considerations from Section 5.5 must be applied for constructing the Timestamp option.
o タイムスタンプオプションは、受信したプロキシバインディング更新メッセージに同じオプションが存在し、別の方法で存在しないでください。セクション5.5からの考慮事項は、タイムスタンプオプションを構築するために適用する必要があります。
o The Mobile Node Link-layer Identifier option MUST be present only if the same option was present in the received Proxy Binding Update message and MUST NOT be present otherwise. The link-layer identifier value MUST be copied from the Mobile Node Link-layer Identifier option present in the received Proxy Binding Update message.
o Mobile Node Link-Layer Identifierオプションは、受信したプロキシバインディングアップデートメッセージに同じオプションが存在し、別の方法で存在しないでください。リンク層識別子の値は、受信したプロキシバインディングアップデートメッセージに存在するモバイルノードリンクレイヤー識別子オプションからコピーする必要があります。
o The Link-local Address option MUST be present only if the same option was present in the received Proxy Binding Update message and MUST NOT be present otherwise. If the Status field in the reply is set to a value greater than or equal to 128, i.e., if the Proxy Binding Update is rejected, then the link-local address from the request MUST be copied to the Link-local Address option in the reply, otherwise the following considerations apply.
o Link-Localアドレスオプションは、受信したプロキシバインディングアップデートメッセージに同じオプションが存在し、別の方法で存在してはならない場合にのみ存在する必要があります。返信のステータスフィールドが128以上の値に設定されている場合、つまりプロキシバインディングアップデートが拒否された場合、リクエストのリンクローカルアドレスをリンクロカルアドレスオプションにコピーする必要があります。返信、それ以外の考慮事項が適用されます。
* If the received Proxy Binding Update message has the Link-local Address option with ALL_ZERO value and if there is an existing Binding Cache entry associated with this request, then the link-local address from the Binding Cache entry MUST be copied to the Link-local Address option in the reply.
* 受信したプロキシバインディングアップデートメッセージには、all_zero値を持つリンクローカルアドレスオプションがあり、このリクエストに関連付けられた既存のバインディングキャッシュエントリがある場合、バインディングキャッシュエントリのリンクローカルアドレスをリンクローカルにコピーする必要があります返信のアドレスオプション。
* If the received Proxy Binding Update message has the Link-local Address option with ALL_ZERO value and if there is no existing Binding Cache entry associated with this request, then the local mobility anchor MUST generate the link-local address that the mobile access gateway can use on the point-to-point link shared with the mobile node. This generated address MUST be copied to the Link-local Address option in the reply. The same address MUST also be copied to the link-local address field of Binding Cache entry created for this mobility session.
* 受信したプロキシバインディングアップデートメッセージには、all_zero値を持つリンクローカルアドレスオプションがあり、このリクエストに関連する既存のバインディングキャッシュエントリがない場合、ローカルモビリティアンカーは、モバイルアクセスゲートウェイが使用できるリンクローカルアドレスを生成する必要があります。モバイルノードと共有されるポイントツーポイントリンク。この生成されたアドレスは、返信のLink-Localアドレスオプションにコピーする必要があります。同じアドレスも、このモビリティセッション用に作成されたバインディングキャッシュエントリのリンクローカルアドレスフィールドにコピーする必要があります。
* If the received Proxy Binding Update message has the Link-local Address option with NON_ZERO value, then the link-local address from the request MUST be copied to the Link-local Address option in the reply. The same address MUST also be copied to the link-local address field of the Binding Cache entry associated with this request (after creating the Binding Cache entry, if one does not exist).
* 受信したプロキシバインディングアップデートメッセージにnon_zero値を持つLink-Localアドレスオプションがある場合、リクエストのリンクローカルアドレスを返信のLink-Localアドレスオプションにコピーする必要があります。同じアドレスも、この要求に関連付けられたバインディングキャッシュエントリのリンクローカルアドレスフィールドにコピーする必要があります（バインディングキャッシュエントリを作成した後、存在しない場合）。
o If IPsec is used for protecting the signaling messages, the message MUST be protected using the security association existing between the local mobility anchor and the mobile access gateway.
o IPSECが信号メッセージの保護に使用される場合、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間に存在するセキュリティアソシエーションを使用してメッセージを保護する必要があります。
o Unlike in Mobile IPv6 [RFC3775], the Type 2 Routing header MUST NOT be present in the IPv6 header of the packet.
o モバイルIPv6 [RFC3775]とは異なり、タイプ2ルーティングヘッダーは、パケットのIPv6ヘッダーに存在してはなりません。
This specification allows mobile nodes to connect to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access. The following are the key aspects of this multihoming support.
o When a mobile node connects to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access, the local mobility anchor MUST allocate a mobility session for each of the attached interfaces. Each mobility session should be managed under a separate Binding Cache entry and with its own lifetime.
o モバイルノードが複数のインターフェイスを介してプロキシモバイルIPv6ドメインに接続して同時アクセスする場合、ローカルモビリティアンカーは、添付の各インターフェイスにモビリティセッションを割り当てる必要があります。各モビリティセッションは、別のバインディングキャッシュエントリの下で、それ自体の寿命の下で管理する必要があります。
o The local mobility anchor MAY allocate more than one home network prefix for a given interface of the mobile node. However, all the prefixes associated with a given interface MUST be managed as part of one mobility session, associated with that interface.
o ローカルモビリティアンカーは、モバイルノードの特定のインターフェイスに複数のホームネットワークプレフィックスを割り当てる場合があります。ただし、特定のインターフェイスに関連付けられたすべてのプレフィックスは、そのインターフェイスに関連付けられた1つのモビリティセッションの一部として管理する必要があります。
o The local mobility anchor MUST allow for a handoff between two different interfaces of a mobile node. In such a scenario, all the home network prefixes associated with one interface (part of one mobility session) will be associated with a different interface of the mobile node. The decision on when to create a new mobility session and when to update an existing mobility session MUST be based on the Handover hint present in the Proxy Binding Update message and under the considerations specified in this section.
o ローカルモビリティアンカーは、モバイルノードの2つの異なるインターフェイス間のハンドオフを可能にする必要があります。このようなシナリオでは、1つのインターフェイス（1つのモビリティセッションの一部）に関連付けられたすべてのホームネットワークプレフィックスは、モバイルノードの異なるインターフェイスに関連付けられます。新しいモビリティセッションをいつ作成するか、いつ既存のモビリティセッションを更新するかについての決定は、プロキシバインディングアップデートメッセージに存在するハンドオーバーヒントと、このセクションで指定された考慮事項に基づいている必要があります。
There can be multiple Binding Cache entries for a given mobile node. When doing a lookup for a mobile node's Binding Cache entry for processing a received Proxy Binding Update message, the local mobility anchor MUST apply the following multihoming considerations (in the below specified order, starting with Section 5.4.1.1). These rules are chained with the processing rules specified in Section 5.3.
特定のモバイルノードには複数のバインディングキャッシュエントリがあります。受信したプロキシバインディングアップデートメッセージを処理するためにモバイルノードのバインディングキャッシュエントリを検索する場合、ローカルモビリティアンカーは、以下のマルチホームの考慮事項を適用する必要があります（以下の指定された順序で、セクション5.4.1.1から）。これらのルールは、セクション5.3で指定された処理ルールでチェーンされています。
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| At least one HNP Option with NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Key: Any of the Home Network Prefixes from the request |
+=====================================================================+
Figure 7: Binding Cache Entry (BCE) Lookup Using Home Network Prefix If there is at least one Home Network Prefix option present in the request with a NON_ZERO prefix value and irrespective of the presence of the Mobile Node Link-layer Identifier option in the request, the following considerations MUST be applied. If there is more than one instance of the Home Network Prefix option, any one of the Home Network Prefix options present in the request (with NON_ZERO prefix value) can be used for locating the Binding Cache entry.
図7：バインディングキャッシュエントリ（BCE）ルックアップホームネットワークプレフィックスを使用して、リクエストに少なくとも1つのホームネットワークプレフィックスオプションが存在する場合、リクエストにモバイルノードリンクレイヤー識別子オプションの存在に関係なく、リクエストに存在します。、以下の考慮事項を適用する必要があります。ホームネットワークのプレフィックスオプションに複数のインスタンスがある場合、リクエストに存在するホームネットワークプレフィックスオプションのいずれか（non_zeroプレフィックス値）を使用して、バインディングキャッシュエントリを見つけることができます。
1. The local mobility anchor MUST verify if there is an existing Binding Cache entry with one of its home network prefixes matching the prefix value in one of the Home Network Prefix options of the received Proxy Binding Update message.
1. ローカルモビリティアンカーは、受信したプロキシバインディングアップデートメッセージのホームネットワークプレフィックスオプションのいずれかのプレフィックス値と一致するホームネットワークのプレフィックスのいずれかを備えた既存のバインディングキャッシュエントリがあるかどうかを確認する必要があります。
2. If a Binding Cache entry does not exist (with one of its home network prefixes in the Binding Cache entry matching the prefix value in one of the Home Network Prefix options of the received Proxy Binding Update message), the request MUST be considered as a request for creating a new mobility session.
2. バインディングキャッシュエントリが存在しない場合（受信したプロキシバインディングアップデートメッセージのホームネットワークプレフィックスオプションの1つのプレフィックス値に一致するバインディングキャッシュエントリのホームネットワークプレフィックスの1つを使用）、リクエストはリクエストと見なす必要があります新しいモビリティセッションを作成するため。
3. If there exists a Binding Cache entry (with one of its home network prefixes in the Binding Cache entry matching the prefix value in one of the Home Network Prefix options of the received Proxy Binding Update message), but if the mobile node identifier in the entry does not match the mobile node identifier in the Mobile Node Identifier option of the received Proxy Binding Update message, the local mobility anchor MUST reject the request with the Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not authorized for one or more of the requesting home network prefixes).
3. バインディングキャッシュエントリが存在する場合（受信したプロキシバインディングアップデートメッセージのホームネットワークプレフィックスオプションの1つのプレフィックス値に一致するバインディングキャッシュエントリのホームネットワークプレフィックスの1つ）が、エントリ内のモバイルノード識別子は受信したプロキシバインディングアップデートメッセージのモバイルノード識別子オプションのモバイルノード識別子と一致しません。ローカルモビリティアンカーは、not_authorized_for_home_network_prefix（モバイルノードが要求の1つ以上に承認されていない[ステータス]フィールド値をnot_authorized_for_home_network_prefixに拒否する必要があります。ホームネットワークプレフィックス）。
4. If there exists a Binding Cache entry (matching MN-Identifier and one of its home network prefixes in the Binding Cache entry matching the prefix value in one of the Home Network Prefix options of the received Proxy Binding Update message), but if all the prefixes in the request do not match all the prefixes in the Binding Cache entry, or if they do not match in count, then the local mobility anchor MUST reject the request with the Status field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home network prefixes listed in the BCE do not match all the prefixes in the received PBU).
4. バインディングキャッシュエントリが存在する場合（Mn-Identifierと、受信したプロキシバインディングアップデートメッセージのホームネットワークプレフィックスオプションの1つのプレフィックス値に一致するバインディングキャッシュエントリのホームネットワークプレフィックスの1つ）が、すべてのプレフィックスの場合リクエストでは、バインディングキャッシュエントリのすべてのプレフィックスと一致しないか、カウントが一致しない場合、ローカルモビリティアンカーは、bce_pbu_prefix_set_do_not_matchに設定されたステータスフィールド値でリクエストを拒否する必要があります（すべてのホームネットワークのプレフィックスがリストされています。BCEは、受信したPBUのすべてのプレフィックスと一致しません）。
5. If there exists a Binding Cache entry (matching MN-Identifier and all the home network prefixes in the Binding Cache entry matching all the home network prefixes in the received Proxy Binding Update message) and if any one or more of these below stated conditions are true, the request MUST be considered as a request for updating that Binding Cache entry.
5. バインディングキャッシュエントリ（Mn-Identifierとバインディングキャッシュエントリ内のすべてのホームネットワークプレフィックスが、受信したプロキシバインディングアップデートメッセージのすべてのホームネットワークプレフィックスに一致するすべてのホームネットワークプレフィックスを一致させる場合）およびこれらの1つまたは複数の場合、以下の条件が真実である場合、リクエストは、そのバインディングキャッシュエントリを更新するためのリクエストと見なされる必要があります。
* If there is a Mobile Node Link-layer Identifier option present in the request and if the link-layer identifier in the option matches the link-layer identifier of the Binding Cache entry and the access technology type in the Access Technology Type option present in the request matches the access technology type in the Binding Cache entry.
* リクエストに存在するモバイルノードリンクレイヤー識別子オプションがあり、オプションのリンクレイヤー識別子がバインディングキャッシュエントリのリンクレイヤー識別子と、アクセステクノロジータイプのアクセステクノロジータイプと一致する場合リクエストは、バインディングキャッシュエントリのアクセステクノロジータイプと一致します。
* If the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 2 (Handoff between two different interfaces of the mobile node).
* リクエストに存在するハンドオフインジケーターオプションのハンドオフインジケータフィールドが2の値に設定されている場合（モバイルノードの2つの異なるインターフェイス間のハンドオフ）。
* If there is no Mobile Node Link-layer Identifier option present in the request, the link-layer identifier value in the Binding Cache entry is set to ALL_ZERO, the access technology type field in the Access Technology Type option present in the request matches the access technology type in the Binding Cache entry, and if the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 3 (Handoff between mobile access gateways for the same interface).
* リクエストに存在するモバイルノードリンクレイヤー識別子オプションがない場合、バインディングキャッシュエントリのリンクレイヤー識別子値がAll_zeroに設定されます。バインディングキャッシュエントリのテクノロジータイプ、およびリクエストに存在するハンドオフインジケーターオプションのハンドオフインジケータフィールドが3の値に設定されている場合（同じインターフェイスのモバイルアクセスゲートウェイ間のハンドオフ）。
* If the Proxy-CoA in the Binding Cache entry matches the source address of the request (or the address in the Alternate Care-of Address option, if the option is present) and if the access technology type field in the Access Technology Type option present in the request matches the access technology type in the Binding Cache entry.
* バインディングキャッシュエントリのプロキシCOAがリクエストのソースアドレス（またはオプションが存在する場合、オプションが存在する場合）のソースアドレス（またはAccessテクノロジータイプのアクセステクノロジータイプオプションのフィールドが表示される場合）の場合リクエストでは、バインディングキャッシュエントリのアクセステクノロジータイプと一致します。
6. For all other cases, the message MUST be considered as a request for creating a new mobility session. However, if the received Proxy Binding Update message has the lifetime value of zero and if the request cannot be associated with any existing mobility session, the message MUST be silently ignored.
6. 他のすべてのケースについては、メッセージは新しいモビリティセッションを作成するためのリクエストと見なされなければなりません。ただし、受信したプロキシバインディングアップデートメッセージの生涯値はゼロであり、リクエストが既存のモビリティセッションに関連付けられない場合、メッセージは静かに無視する必要があります。
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| No HNP option with a NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Option Present (NON_ZERO Value) |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) |
+=====================================================================+
Figure 8: BCE Lookup Using Link-layer Identifier
図8：リンク層識別子を使用したBCEルックアップ
If there is no Home Network Prefix option present in the request with a NON_ZERO prefix value, but if there is a Mobile Node Link-layer Identifier option present in the request, then the following considerations MUST be applied for locating the Binding Cache entry.
non_zeroプレフィックス値を持つホームネットワークのプレフィックスオプションがリクエストに存在しないが、リクエストにモバイルノードリンクレイヤー識別子オプションが存在する場合は、バインディングキャッシュエントリを見つけるために次の考慮事項を適用する必要があります。
1. The local mobility anchor MUST verify if there is an existing Binding Cache entry, with the mobile node identifier matching the identifier in the received Mobile Node Identifier option, access technology type matching the value in the received Access Technology Type option, and the link-layer identifier value matching the identifier in the received Mobile Node Link-layer Identifier option.
1. ローカルモビリティアンカーは、既存のバインディングキャッシュエントリがあるかどうかを確認する必要があります。モバイルノード識別子が受信したモバイルノード識別子オプションの識別子と一致します。識別子値は、受信したモバイルノードリンクレイヤー識別子オプションの識別子に一致します。
2. If there exists a Binding Cache entry (matching MN-Identifier, Access Technology Type (ATT), and MN-LL-Identifier), the request MUST be considered as a request for updating that Binding Cache entry.
2.
3. If there does not exist a Binding Cache entry (matching MN-Identifier, ATT, and MN-LL-Identifier) and the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 2 (Handoff between two different interfaces of the mobile node). The local mobility anchor MUST apply the following additional considerations.
3. バインディングキャッシュエントリ（Mn-Identifier、att、およびMn-ll-Identifierを一致させる）が存在しない場合、リクエストに存在するハンドオフインジケーターオプションのハンドオフインジケーターフィールドは2の値に設定されています（2つの異なる間のハンドオフモバイルノードのインターフェイス）。ローカルモビリティアンカーは、以下の追加の考慮事項を適用する必要があります。
* The local mobility anchor MUST verify if there exists one and only one Binding Cache entry with the mobile node identifier matching the identifier in the Mobile Node Identifier option present in the request and for any link-layer identifier value. If there exists only one such entry (matching the MN-Identifier), the request MUST be considered as a request for updating that Binding Cache entry.
* ローカルモビリティアンカーは、リクエストに存在するモバイルノード識別子オプションの識別子とリンク層識別子値の識別子に一致するモバイルノード識別子を持つ1つのバインディングキャッシュエントリが1つ存在するかどうかを確認する必要があります。そのようなエントリが1つしか存在しない場合（MN-Identifierと一致）、リクエストは、そのバインディングキャッシュエントリを更新するためのリクエストと見なす必要があります。
4. If there does not exist a Binding Cache entry (matching MN-Identifier, ATT, and MN-LL-Identifier) and if the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 4 (Handoff state unknown), the local mobility anchor MUST apply the following additional considerations.
4. バインディングキャッシュエントリ（MN-IDENTIFIER、ATT、およびMN-LL-IDENTIFIERを一致させる）が存在しない場合、リクエストに存在するハンドオフインジケーターオプションのハンドオフインジケータフィールドが値4に設定されている場合（ハンドオフ状態不明）、ローカルモビリティアンカーは、以下の追加の考慮事項を適用する必要があります。
* The local mobility anchor MUST verify if there exists one and only one Binding Cache entry with the mobile node identifier matching the identifier in the Mobile Node Identifier option present in the request and for any link-layer identifier value. If there exists only one such entry (matching the MN-Identifier), the local mobility anchor SHOULD wait until the existing Binding Cache entry is de-registered by the previously serving mobile access gateway, before the request can be considered as a request for updating that Binding Cache entry. However, if there is no de-registration message that is received within MaxDelayBeforeNewBCEAssign amount of time, the local mobility anchor, upon accepting the request, MUST consider the request as a request for creating a new mobility session. The local mobility anchor MAY also choose to create a new mobility session without waiting for a de-registration message, and this should be configurable on the local mobility anchor.
* ローカルモビリティアンカーは、リクエストに存在するモバイルノード識別子オプションの識別子とリンク層識別子値の識別子に一致するモバイルノード識別子を持つ1つのバインディングキャッシュエントリが1つ存在するかどうかを確認する必要があります。そのようなエントリが1つだけ存在する場合（MN-Identifierに一致）、ローカルモビリティアンカーは、既存のバインディングキャッシュエントリが以前にサービスを提供していたモバイルアクセスゲートウェイによって解除されるまで待機する必要があります。そのバインディングキャッシュエントリ。ただし、MaxdelaybeforenewBceassignの時間内に受信される登録解除メッセージがない場合、リクエストを受け入れると、ローカルモビリティアンカーは、新しいモビリティセッションを作成するためのリクエストとしてリクエストを考慮する必要があります。ローカルモビリティアンカーは、登録解除メッセージを待たずに新しいモビリティセッションを作成することもできます。これは、ローカルモビリティアンカーで構成できる必要があります。
5. For all other cases, the message MUST be considered as a request for creating a new mobility session. However, if the received Proxy Binding Update message has the lifetime value of zero and if the request cannot be associated with any existing mobility session, the message MUST be silently ignored.
5. 他のすべてのケースについては、メッセージは新しいモビリティセッションを作成するためのリクエストと見なされなければなりません。ただし、受信したプロキシバインディングアップデートメッセージの生涯値はゼロであり、リクエストが既存のモビリティセッションに関連付けられない場合、メッセージは静かに無視する必要があります。
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| No HNP option with a NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Option Not Present |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Key: (MN-Identifier) |
+=====================================================================+
Figure 9: BCE Lookup Using Mobile Node Identifier
図9：モバイルノード識別子を使用したBCEルックアップ
If there is no Home Network Prefix option present in the request with a NON_ZERO prefix value and if there is also no Mobile Node Link-layer Identifier option present in the request, then the following considerations MUST be applied for locating the Binding Cache entry.
non_zeroプレフィックス値を持つホームネットワークのプレフィックスオプションがリクエストに存在しない場合、およびリクエストにモバイルノードリンクレイヤー識別子オプションも存在しない場合は、バインディングキャッシュエントリを見つけるために次の考慮事項を適用する必要があります。
1. The local mobility anchor MUST verify if there exists one and only one Binding Cache entry with the mobile node identifier matching the identifier in the Mobile Node Identifier option present in the request.
1. ローカルモビリティアンカーは、リクエストに存在するモバイルノード識別子オプションの識別子に一致するモバイルノード識別子を使用して、1つのバインディングキャッシュエントリが存在するかどうかを確認する必要があります。
2. If there exists only one such entry (matching the MN-Identifier) and the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 2 (Handoff between two different interfaces of the mobile node) or set to a value of 3 (Handoff between mobile access gateways for the same interface), then the request MUST be considered as a request for updating that Binding Cache entry.
2. そのようなエントリ（Mn-Identifierに一致）のみが存在する場合、リクエストに存在するハンドオフインジケーターオプションのハンドオフインジケーターフィールドが2の値（モバイルノードの2つの異なるインターフェイス間のハンドオフ）に設定されるか、3（同じインターフェイスのモバイルアクセスゲートウェイ間のハンドオフ）の値は、そのバインディングキャッシュエントリを更新するためのリクエストとみなす必要があります。
3. If there exists only one such entry (matching the MN-Identifier) and the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 4 (Handoff state unknown), the local mobility anchor SHOULD wait until the existing Binding Cache entry is de-registered by the previously serving mobile access gateway before the request can be considered as a request for updating that Binding Cache entry. However, if there is no de-registration message that is received within MaxDelayBeforeNewBCEAssign amount of time, the local mobility anchor, upon accepting the request, MUST consider the request as a request for creating a new mobility session. The local mobility anchor MAY also choose to create a new mobility session without waiting for a de-registration message, and this should be configurable on the local mobility anchor.
3. そのようなエントリ（Mn-Identifierに一致する）のみが存在する場合、リクエストに存在するハンドオフインジケーターオプションのハンドオフインジケーターフィールドが4（ハンドオフ状態不明）に設定されている場合、ローカルモビリティアンカーは既存のものまで待つ必要がありますバインディングキャッシュのエントリは、リクエストがバインディングキャッシュエントリを更新するためのリクエストと見なす前に、以前に提供されたモバイルアクセスゲートウェイによって登録されます。ただし、MaxdelaybeforenewBceassignの時間内に受信される登録解除メッセージがない場合、リクエストを受け入れると、ローカルモビリティアンカーは、新しいモビリティセッションを作成するためのリクエストとしてリクエストを考慮する必要があります。ローカルモビリティアンカーは、登録解除メッセージを待たずに新しいモビリティセッションを作成することもできます。これは、ローカルモビリティアンカーで構成できる必要があります。
4. For all other cases, the message MUST be considered as a request for creating a new mobility session. However, if the received Proxy Binding Update message has the lifetime value of zero and if the request cannot be associated with any existing mobility session, the message MUST be silently ignored.
4. 他のすべてのケースについては、メッセージは新しいモビリティセッションを作成するためのリクエストと見なされなければなりません。ただし、受信したプロキシバインディングアップデートメッセージの生涯値はゼロであり、リクエストが既存のモビリティセッションに関連付けられない場合、メッセージは静かに無視する必要があります。
Mobile IPv6 [RFC3775] uses the Sequence Number field in binding registration messages as a way for the home agent to process the binding updates in the order they were sent by a mobile node. The home agent and the mobile node are required to manage this counter over the lifetime of a binding. However, in Proxy Mobile IPv6, as the mobile node moves from one mobile access gateway to another and in the absence of mechanisms such as context transfer between the mobile access gateways, the serving mobile access gateway will be unable to determine the sequence number that it needs to use in the signaling messages. Hence, the sequence number scheme, as specified in [RFC3775], will be insufficient for Proxy Mobile IPv6.
モバイルIPv6 [RFC3775]は、ホームエージェントがモバイルノードによって送信された順序でバインディングアップデートを処理する方法として、バインディング登録メッセージのシーケンス番号フィールドを使用します。ホームエージェントとモバイルノードは、バインディングの寿命にわたってこのカウンターを管理する必要があります。ただし、プロキシモバイルIPv6では、モバイルノードがあるモバイルアクセスゲートウェイから別のモバイルアクセスゲートウェイに移動し、モバイルアクセスゲートウェイ間のコンテキスト転送などのメカニズムがない場合、モバイルアクセスゲートウェイのサービングはシーケンス番号を決定できません。信号メッセージで使用する必要があります。したがって、[RFC3775]で指定されているシーケンス番号スキームは、プロキシモバイルIPv6には不十分です。
If the local mobility anchor cannot determine the sending order of the received Proxy Binding Update messages, it may potentially process an older message sent by a mobile access gateway where the mobile node was previously anchored, but delivered out of order, resulting in incorrectly updating the mobile node's Binding Cache entry and creating a routing state for tunneling the mobile node's traffic to the previous mobile access gateway.
ローカルモビリティアンカーが受信したプロキシバインディングアップデートメッセージの送信順序を決定できない場合、モバイルノードが以前に固定されていたが順序付けられたモバイルアクセスゲートウェイによって送信された古いメッセージを処理する可能性があります。モバイルノードのバインディングキャッシュエントリと、モバイルノードのトラフィックを以前のモバイルアクセスゲートウェイにトンネリングするためのルーティング状態を作成します。
For solving this problem, this specification adopts two alternative solutions. One is based on timestamps and the other based on sequence numbers, as defined in [RFC3775].
この問題を解決するために、この仕様は2つの代替ソリューションを採用しています。1つはタイムスタンプに基づいており、もう1つは[RFC3775]で定義されているように、シーケンス番号に基づいています。
The basic principle behind the use of timestamps in binding registration messages is that the node generating the message inserts the current time of day, and the node receiving the message checks that this timestamp is greater than all previously accepted timestamps. The timestamp-based solution may be used when the serving mobile access gateways in a Proxy Mobile IPv6 domain do not have the ability to obtain the last sequence number that was sent in a Proxy Binding Update message for updating a given mobile node's binding.
バインディング登録メッセージにおけるタイムスタンプの使用の背後にある基本原則は、メッセージを生成するノードが現在の時刻を挿入し、メッセージを受信するノードがこのタイムスタンプが以前に受け入れられたすべてのタイムスタンプよりも大きいことをチェックすることです。プロキシモバイルIPv6ドメインのモバイルアクセスゲートウェイを提供する場合、特定のモバイルノードのバインディングを更新するためのプロキシバインディングアップデートメッセージで送信された最後のシーケンス番号を取得する機能がない場合、タイムスタンプベースのソリューションを使用できます。
Clock drift reduces the effectiveness of the timestamp mechanism. The time required for reconnection is the total of the time required for the mobile node to roam between two mobile access gateways and the time required for the serving mobile access gateway to detect the mobile node on its access link and construct the Proxy Binding Update message. If the clock skew on any one of these two neighboring mobile access gateways (relative to the common time source used for clock synchronization) is more than half this reconnection time, the timestamp solution will not predictably work in all cases and hence SHOULD NOT be used.
クロックドリフトにより、タイムスタンプメカニズムの有効性が低下します。再接続に必要な時間は、モバイルノードが2つのモバイルアクセスゲートウェイの間でローミングするのに必要な時間と、アクセスリンクでモバイルノードを検出し、プロキシバインディングアップデートメッセージを構築するためにモバイルアクセスゲートウェイに必要な時間です。これらの2つの隣接するモバイルアクセスゲートウェイのいずれかにクロックが歪んでいる場合（クロック同期に使用される一般的な時間ソースと比較して）、この再接続時間の半分以上である場合、タイムスタンプソリューションはすべての場合に予測可能に機能しないため、使用するべきではありません。。
As an alternative to the Timestamp-based approach, the specification also allows the use of Sequence-Number-based scheme, as specified in [RFC3775]. However, for this scheme to work, the serving mobile access gateway in a Proxy Mobile IPv6 domain MUST have the ability to obtain the last sequence number that was sent in a binding registration message for that mobility session. The sequence number MUST be maintained on a mobile node's per mobility session basis and MUST be available to the serving mobile access gateway. This may be achieved by using context transfer schemes or by maintaining the sequence number in a policy store. However, the specific details on how the mobile node's sequence number is made available to the serving mobile access gateway prior to sending the Proxy Binding Update message is outside the scope of this document.
タイムスタンプベースのアプローチに代わるものとして、[RFC3775]で指定されているように、仕様により、シーケンス番号ベースのスキームを使用することもできます。ただし、このスキームが機能するためには、プロキシモバイルIPv6ドメインのモバイルアクセスゲートウェイにサービスを提供するには、そのモビリティセッションの拘束力のある登録メッセージで送信された最後のシーケンス番号を取得する機能が必要です。シーケンス番号は、モバイルノードごとのモビリティセッションベースで維持する必要があり、サービングモバイルアクセスゲートウェイで利用できる必要があります。これは、コンテキスト転送スキームを使用するか、ポリシーストアでシーケンス番号を維持することによって達成できます。ただし、プロキシバインディングアップデートメッセージを送信する前に、モバイルノードのシーケンス番号がサービングモバイルアクセスゲートウェイでどのように利用可能になるかについての具体的な詳細は、このドキュメントの範囲外です。
Using the Timestamp-Based Approach:
タイムスタンプベースのアプローチの使用：
1. A local mobility anchor implementation MUST support the Timestamp option. If the Timestamp option is present in the received Proxy Binding Update message, then the local mobility anchor MUST include a valid Timestamp option in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway.
1. ローカルモビリティアンカーの実装は、タイムスタンプオプションをサポートする必要があります。受信したプロキシバインディングアップデートメッセージにタイムスタンプオプションが存在する場合、ローカルモビリティアンカーには、モバイルアクセスゲートウェイに送信するプロキシバインド確認メッセージに有効なタイムスタンプオプションを含める必要があります。
2. All the mobility entities in a Proxy Mobile IPv6 domain that are exchanging binding registration messages using the Timestamp option MUST have adequately synchronized time-of-day clocks. This is the essential requirement for this solution to work. If this requirement is not met, the solution will not predictably work in all cases.
2. Timestampオプションを使用して拘束力のある登録メッセージを交換しているプロキシモバイルIPv6ドメインのすべてのモビリティエンティティには、日時の時刻が適切に同期されている必要があります。これは、このソリューションが機能するための重要な要件です。この要件が満たされていない場合、ソリューションはすべての場合に予測可能には機能しません。
3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD synchronize their clocks to a common time source. For synchronizing the clocks, the nodes MAY use the Network Time Protocol [RFC4330]. Deployments MAY also adopt other approaches suitable for that specific deployment. Alternatively, if there is a mobile node generated timestamp that is increasing at every attachment to the access link and if that timestamp is available to the mobile access gateway (e.g., the Timestamp option in the SEND [RFC3971] messages that the mobile node sends), the mobile access gateway can use this timestamp or sequence number in the Proxy Binding Update messages and does not have to depend on any external clock source. However, the specific details on how this is achieved are outside the scope of this document.
3. プロキシモバイルIPv6ドメインのモビリティエンティティは、クロックを共通の時間ソースに同期させる必要があります。クロックを同期するために、ノードはネットワークタイムプロトコル[RFC4330]を使用する場合があります。展開は、その特定の展開に適した他のアプローチを採用する場合があります。または、アクセスリンクへの添付すべてで増加しているモバイルノード生成タイムスタンプがある場合、およびそのタイムスタンプがモバイルアクセスゲートウェイ（たとえば、モバイルノードが送信する送信[RFC3971]メッセージのタイムスタンプオプション）が利用できる場合）、モバイルアクセスゲートウェイは、プロキシバインディングアップデートメッセージでこのタイムスタンプまたはシーケンス番号を使用でき、外部クロックソースに依存する必要はありません。ただし、これがどのように達成されるかについての具体的な詳細は、このドキュメントの範囲外です。
4. When generating the timestamp value for building the Timestamp option, the mobility entities MUST ensure that the generated timestamp is the elapsed time past the same reference epoch, as specified in the format for the Timestamp option (Section 8.8).
4. タイムスタンプオプションを構築するためのタイムスタンプ値を生成する場合、モビリティエンティティは、生成されたタイムスタンプが、タイムスタンプオプションの形式で指定されているように、同じ参照エポックを過ぎて経過した時間であることを確認する必要があります（セクション8.8）。
5. If the Timestamp option is present in the received Proxy Binding Update message, the local mobility anchor MUST ignore the sequence number field in the message. However, it MUST copy the sequence number from the received Proxy Binding Update message to the Proxy Binding Acknowledgement message.
5. 受信したプロキシバインディングアップデートメッセージにタイムスタンプオプションが存在する場合、ローカルモビリティアンカーはメッセージ内のシーケンス番号フィールドを無視する必要があります。ただし、受信したプロキシバインディングアップデートメッセージからシーケンス番号をプロキシバインディング確認メッセージにコピーする必要があります。
6. Upon receipt of a Proxy Binding Update message with the Timestamp option, the local mobility anchor MUST check the timestamp field for validity. In order for it to be considered valid, the following MUST be true.
6. タイムスタンプオプションを使用したプロキシバインディングアップデートメッセージを受信すると、ローカルモビリティアンカーはタイムスタンプフィールドの有効性を確認する必要があります。それが有効であると見なされるためには、以下が真実でなければなりません。
* The timestamp value contained in the Timestamp option MUST be close enough (within TimestampValidityWindow amount of time difference) to the local mobility anchor's time-of-day clock. However, if the flag MobileNodeGeneratedTimestampInUse is set to a value of 1, the local mobility anchor MUST ignore this check and perform only the following check.
* タイムスタンプオプションに含まれるタイムスタンプの値は、ローカルモビリティアンカーの時刻時計に十分近い（タイムスタンプバリシティウィンドウの時間差の内側）なければなりません。ただし、旗がMobilEnodegeneratedTimestampinuseが1の値に設定されている場合、ローカルモビリティアンカーはこのチェックを無視し、次のチェックのみを実行する必要があります。
* The timestamp MUST be greater than all previously accepted timestamps in the Proxy Binding Update messages sent for that mobile node.
* タイムスタンプは、そのモバイルノードに送信されたプロキシバインディングアップデートメッセージの以前に受け入れられたすべてのタイムスタンプよりも大きくなければなりません。
7. If the timestamp value in the received Proxy Binding Update is valid (validity as specified in the above considerations) or if the flag MobileNodeGeneratedTimestampInUse is set to value of 1, the local mobility anchor MUST return the same timestamp value in the Timestamp option included in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway.
7. 受信したプロキシバインディングアップデートのタイムスタンプ値が有効である場合（上記の考慮事項で指定されている妥当性）、またはフラグがMobilEnodegeneratedTimestampinuseが1の値に設定されている場合、ローカルモビリティアンカーは、タイムスタンプの同じタイムスタンプ値を返す必要があります。モバイルアクセスゲートウェイに送信するプロキシバインド確認メッセージ。
8. If the timestamp value in the received Proxy Binding Update is lower than the previously accepted timestamp in the Proxy Binding Update messages sent for that mobility binding, the local mobility anchor MUST reject the Proxy Binding Update message and send a Proxy Binding Acknowledgement message with the Status field set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than previously accepted timestamp). The message MUST also include the Timestamp option with the value set to the current time of day on the local mobility anchor.
8. 受信したプロキシバインディングアップデートのタイムスタンプ値が、そのモビリティバインディングのために送信されたプロキシバインディングアップデートメッセージの以前に受け入れられたタイムスタンプよりも低い場合、ローカルモビリティアンカーはプロキシバインディングアップデートメッセージを拒否し、ステータスのプロキシバインディング確認メッセージを送信する必要がありますフィールドセットTimestamp_lower_than_prev_accepted（以前に受け入れられたタイムスタンプよりも低いタイムスタンプ）。メッセージには、ローカルモビリティアンカーの現在の時刻に設定された値を備えたタイムスタンプオプションも含める必要があります。
9. If the timestamp value in the received Proxy Binding Update is not valid (validity as specified in the above considerations), the local mobility anchor MUST reject the Proxy Binding Update and send a Proxy Binding Acknowledgement message with the Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The message MUST also include the Timestamp option with the value set to the current time of day on the local mobility anchor.
9. 受信したプロキシバインディングアップデートのタイムスタンプ値が有効でない場合（上記の考慮事項で指定されている妥当性）、ローカルモビリティアンカーはプロキシバインディングアップデートを拒否し、タイムスタンプ_Mismatchに設定されたステータスフィールドを使用してプロキシバインディングの確認メッセージを送信する必要があります）。メッセージには、ローカルモビリティアンカーの現在の時刻に設定された値を備えたタイムスタンプオプションも含める必要があります。
Using the Sequence-Number-Based Approach:
シーケンス番号ベースのアプローチの使用：
1. If the Timestamp option is not present in the received Proxy Binding Update message, the local mobility anchor MUST fall back to the Sequence-Number-based scheme. It MUST process the sequence number field as specified in [RFC3775]. Also, it MUST NOT include the Timestamp option in the Proxy Binding Acknowledgement messages that it sends to the mobile access gateway.
1. 受信したプロキシバインディングアップデートメッセージにタイムスタンプオプションが存在しない場合、ローカルモビリティアンカーはシーケンス番号ベースのスキームに戻る必要があります。[RFC3775]で指定されているように、シーケンス番号フィールドを処理する必要があります。また、モバイルアクセスゲートウェイに送信するプロキシバインド確認メッセージにタイムスタンプオプションを含めてはなりません。
2. An implementation MUST support the Sequence-Number-based scheme, as specified in [RFC3775].
2. [RFC3775]で指定されているように、実装はシーケンス番号ベースのスキームをサポートする必要があります。
3. The Sequence-Number-based approach can be used only when there is some mechanism (such as context transfer procedure between mobile access gateways) that allows the serving mobile access gateway to obtain the last sequence number that was sent in a Proxy Binding Update message for updating a given mobile node's binding.
3. シーケンス番号ベースのアプローチは、モバイルアクセスゲートウェイに提供されるモバイルアクセスゲートウェイが提供できるメカニズム（モバイルアクセスゲートウェイ間のコンテキスト転送手順など）がある場合にのみ使用できます。特定のモバイルノードのバインディングを更新します。
The bi-directional tunnel MUST be used for routing the mobile node's data traffic between the mobile access gateway and the local mobility anchor. A tunnel hides the topology and enables a mobile node to use address(es) from its home network prefix(es) from any access link in that Proxy Mobile IPv6 domain. A tunnel may be created dynamically when needed and removed when not needed. However, implementations MAY choose to use static pre-established tunnels instead of dynamically creating and tearing them down on a need basis. The following considerations MUST be applied when using dynamically created tunnels.
双方向トンネルは、モバイルアクセスゲートウェイとローカルモビリティアンカーの間のモバイルノードのデータトラフィックをルーティングするために使用する必要があります。トンネルはトポロジーを隠し、モバイルノードがそのプロキシモバイルIPv6ドメインの任意のアクセスリンクからホームネットワークプレフィックス（ES）からアドレス（ES）を使用できるようにします。必要に応じてトンネルを動的に作成し、必要でない場合は削除できます。ただし、実装は、必要に応じて動的に作成および引き裂くのではなく、静的な事前に確立されたトンネルを使用することを選択する場合があります。動的に作成されたトンネルを使用する場合は、以下の考慮事項を適用する必要があります。
o A bi-directional tunnel MUST be established between the local mobility anchor and the mobile access gateway and the local mobility anchor with IPv6-in-IPv6 encapsulation, as described in [RFC2473]. The tunnel endpoints are the Proxy-CoA and LMAA. However, when using IPv4 transport, the endpoints of the tunnel are IPv4-LMAA and IPv4-Proxy-CoA with the encapsulation mode as specified in [IPV4-PMIP6].
o [RFC2473]に記載されているように、ローカルモビリティアンカーとモバイルアクセスゲートウェイとIPv6-in-IPV6カプセル化を備えたローカルモビリティアンカーの間に、双方向トンネルを確立する必要があります。トンネルのエンドポイントは、プロキシCoAとLMAAです。ただし、IPv4トランスポートを使用する場合、トンネルのエンドポイントは、[IPv4-PMIP6]で指定されているように、カプセル化モードを備えたIPv4-LMAAとIPv4-Proxy-CoAです。
o Implementations MAY use a software timer for managing the tunnel lifetime and a counter for keeping a count of all the mobile nodes that are sharing the tunnel. The timer value can be set to the accepted binding lifetime and can be updated after each periodic re-registration for extending the lifetime. If the tunnel is shared for multiple mobile nodes, the tunnel lifetime must be set to the highest binding lifetime that is granted to any one of those mobile nodes sharing that tunnel.
o 実装は、トンネルの寿命を管理するためのソフトウェアタイマーを使用し、トンネルを共有しているすべてのモバイルノードのカウントを維持するためのカウンターを使用する場合があります。タイマーの値は、受け入れられたバインディング寿命に設定でき、生涯を延長するための各定期的な再登録後に更新できます。トンネルが複数のモバイルノードに対して共有されている場合、トンネルの寿命は、そのトンネルを共有するモバイルノードのいずれかに付与される最高の結合寿命に設定する必要があります。
o The tunnel SHOULD be deleted when either the tunnel lifetime expires or when there are no mobile nodes sharing the tunnel.
o トンネルの寿命が切れる場合、またはトンネルを共有するモバイルノードがない場合、トンネルは削除する必要があります。
Intercepting Packets Sent to the Mobile Node's Home Network:
モバイルノードのホームネットワークに送信されるインターセプトパケット：
o When the local mobility anchor is serving a mobile node, it MUST be able to receive packets that are sent to the mobile node's home network. In order for it to receive those packets, it MUST advertise a connected route in to the Routing Infrastructure for the mobile node's home network prefix(es) or for an aggregated prefix with a larger scope. This essentially enables IPv6 routers in that network to detect the local mobility anchor as the last-hop router for the mobile node's home network prefix(es).
o ローカルモビリティアンカーがモバイルノードを提供している場合、モバイルノードのホームネットワークに送信されるパケットを受信できる必要があります。これらのパケットを受信するには、モバイルノードのホームネットワークプレフィックス（ES）のルーティングインフラストラクチャに接続されたルートを宣伝するか、より大きなスコープを持つ集約されたプレフィックスのために宣伝する必要があります。これにより、そのネットワーク内のIPv6ルーターは、モバイルノードのホームネットワークプレフィックス（ES）の最終ホップルーターとしてローカルモビリティアンカーを検出できます。
Forwarding Packets to the Mobile Node:
モバイルノードにパケットを転送します：
o On receiving a packet from a correspondent node with the destination address matching a mobile node's home network prefix(es), the local mobility anchor MUST forward the packet through the bi-directional tunnel set up for that mobile node.
o モバイルノードのホームネットワークプレフィックス（ES）と一致する宛先アドレスを持つ特派員ノードからパケットを受信すると、ローカルモビリティアンカーは、そのモバイルノードに設定された双方向トンネルを介してパケットを転送する必要があります。
o The format of the tunneled packet is shown below. Considerations from [RFC2473] MUST be applied for IPv6 encapsulation. However, when using IPv4 transport, the format of the packet is as described in [IPV4-PMIP6].
o トンネルパケットの形式を以下に示します。[RFC2473]からの考慮事項は、IPv6カプセル化に適用する必要があります。ただし、IPv4トランスポートを使用する場合、パケットの形式は[IPv4-PMIP6]に記載されているとおりです。
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 10: Tunneled Packet from LMA to MAG
図10：LMAからMAGへのトンネルパケット
o The format of the tunneled packet is shown below, when payload protection using IPsec is enabled for the mobile node's data traffic. However, when using IPv4 transport, the format of the packet is as described in [IPV4-PMIP6].
o トンネルパケットの形式は、モバイルノードのデータトラフィックに対してIPSECを使用したペイロード保護が有効になっている場合、以下に示します。ただし、IPv4トランスポートを使用する場合、パケットの形式は[IPv4-PMIP6]に記載されているとおりです。
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
ESP Header in tunnel mode /* ESP Header */
IPv6 header (src= CN, dst= MN-HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 11: Tunneled Packet from LMA to MAG with Payload Protection
図11：ペイロード保護を伴うLMAからMAGへのトンネルパケット
Forwarding Packets Sent by the Mobile Node:
モバイルノードから送信された転送パケット：
o All the reverse tunneled packets that the local mobility anchor received from the mobile access gateway, after removing the tunnel header MUST be routed to the destination specified in the inner packet header. These routed packets will have the Source Address field set to the mobile node's home address. Considerations from [RFC2473] MUST be applied for IPv6 decapsulation.
o トンネルヘッダーを取り外した後、モバイルアクセスゲートウェイからローカルモビリティアンカーが受け取ったすべての逆トンネルパケットは、内側のパケットヘッダーで指定された宛先にルーティングする必要があります。これらのルーティングされたパケットは、モバイルノードのホームアドレスにセットされたソースアドレスフィールドを備えています。[RFC2473]からの考慮事項は、IPv6脱カプセル化に適用する必要があります。
This section describes how the ECN information needs to be handled by the mobility agents at the tunnel entry and exit points. The ECN considerations for IP tunnels are specified in [RFC3168], and the same considerations apply to Proxy Mobile IPv6 tunnels (using IPv6- in-IPv6 encapsulation mode). Specifically, the full-functionality option MUST be supported. The relevant ECN considerations from [RFC3168] are summarized here for convenience.
このセクションでは、トンネルの入り口と出口ポイントのモビリティエージェントがECN情報を処理する方法について説明します。IPトンネルのECNの考慮事項は[RFC3168]で指定されており、同じ考慮事項がプロキシモバイルIPv6トンネルに適用されます（IPv6- IN-IPV6カプセル化モードを使用）。具体的には、フルファンクションオプションをサポートする必要があります。[RFC3168]からの関連するECNの考慮事項は、便利なためにここにまとめられています。
Encapsulation Considerations:
カプセル化の考慮事項：
o If the Explicit Congestion Notification (ECN) field in the inner header is set to ECT(0) or ECT(1), where ECT stands for ECN-Capable Transport (ECT), the ECN field from the inner header MUST be copied to the outer header. Additionally, when payload protection using IPsec is enabled for the mobile node's data traffic, the ECN considerations from [RFC4301] MUST be applied.
o 内側のヘッダーの明示的な混雑通知（ECN）フィールドがECT（0）またはECT（1）に設定されている場合、ECTはECN対応輸送（ECT）を表します。内側ヘッダーからのECNフィールドをコピーする必要があります。外側のヘッダー。さらに、モバイルノードのデータトラフィックに対してIPSECを使用したペイロード保護が有効になっている場合、[RFC4301]からのECN考慮事項を適用する必要があります。
Decapsulation Considerations:
脱カプセル化の考慮事項：
o If the Explicit Congestion Notification (ECN) field in the inner header is set to ECT(0) or ECT(1), and if the ECN field in the outer header is set to Congestion Experienced (CE), then the ECN field in the inner header MUST be set to CE. Otherwise, the ECN field in the inner header MUST NOT be modified. Additionally, when payload protection using IPsec is enabled for the mobile node's data traffic, the ECN considerations from [RFC4301] MUST be applied.
o 内側のヘッダーの明示的なうっ血通知（ECN）フィールドがECT（0）またはECT（1）に設定され、外側ヘッダーのECNフィールドが輻輳が発生した場合（CE）に設定されている場合、内側のヘッダーはCEに設定する必要があります。それ以外の場合、内側のヘッダーのECNフィールドを変更してはなりません。さらに、モバイルノードのデータトラフィックに対してIPSECを使用したペイロード保護が有効になっている場合、[RFC4301]からのECN考慮事項を適用する必要があります。
Dynamic Home Agent Address Discovery (DHAAD), as explained in Section 10.5 of [RFC3775], allows a mobile node to discover all the home agents on its home link by sending an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home Agent's anycast address, derived from its home network prefix.
[RFC3775]のセクション10.5で説明されているように、ダイナミックホームエージェントアドレスディスカバリー（DHAAD）により、モバイルノードは、ICMPホームエージェントアドレスアドレスディスカバリーリクエストメッセージをモバイルIPv6ホームエージェントのANYCASTに送信することにより、ホームリンクのすべてのホームエージェントを発見できます。ホームネットワークプレフィックスから派生したアドレス。
The DHAAD message in the current form cannot be used in Proxy Mobile IPv6 for discovering the address of the mobile node's local mobility anchor. In Proxy Mobile IPv6, the local mobility anchor will not be able to receive any messages sent to the Mobile IPv6 Home Agent's anycast address corresponding to the mobile node's home network prefix(es), as the prefix(es) is not hosted on any of its interfaces. Further, the mobile access gateway will not predictably be able to locate the serving local mobility anchor that has the mobile node's binding cache entry. Hence, this specification does not support Dynamic Home Agent Address Discovery protocol.
現在の形式のDHAADメッセージは、モバイルノードのローカルモビリティアンカーのアドレスを発見するためにプロキシモバイルIPv6で使用することはできません。プロキシモバイルIPv6では、ローカルモビリティアンカーは、モバイルノードのホームネットワークプレフィックス（ES）に対応するモバイルIPv6ホームエージェントのAnycastアドレスに送信されたメッセージを受信できません。そのインターフェイス。さらに、モバイルアクセスゲートウェイは、モバイルノードのバインディングキャッシュエントリを備えたサービスを提供するローカルモビリティアンカーを予想通り見つけることができません。したがって、この仕様は、動的ホームエージェントアドレスディスカバリープロトコルをサポートしていません。
In Proxy Mobile IPv6, the address of the local mobility anchor configured to serve a mobile node can be discovered by the mobility access gateway entity via other means. The LMA to be assigned to a mobile node may be a configured entry in the mobile node's policy profile, or it may be obtained through mechanisms outside the scope of this document.
プロキシモバイルIPv6では、モバイルノードを提供するように構成されたローカルモビリティアンカーのアドレスは、モビリティアクセスゲートウェイエンティティによって他の手段を介して発見できます。モバイルノードに割り当てられるLMAは、モバイルノードのポリシープロファイルで構成されたエントリである場合があります。または、このドキュメントの範囲外のメカニズムを介して取得される場合があります。
This specification does not support mobile prefix discovery. The mobile prefix discovery mechanism as specified in [RFC3775] is not applicable to Proxy Mobile IPv6.
この仕様は、モバイルプレフィックスの発見をサポートしていません。[RFC3775]で指定されているモバイルプレフィックスディスカバリーメカニズムは、プロキシモバイルIPv6には適用できません。
The Route Optimization in Mobile IPv6, as defined in [RFC3775], enables a mobile node to communicate with a correspondent node directly using its care-of address and further the Return Routability procedure enables the correspondent node to have reasonable trust that the mobile node is reachable at both its home address and care-of address.
[RFC3775]で定義されているモバイルIPv6のルート最適化により、モバイルノードはそのケアオブアドレスを使用して、特派員ノードと直接通信できます。自宅の住所とケアオブアドレスの両方で到達可能。
This specification does not support the Route Optimization specified in Mobile IPv6 [RFC3775]. However, this specification does support another form of route optimization, as specified in Section 6.10.3.
この仕様は、モバイルIPv6 [RFC3775]で指定されたルート最適化をサポートしていません。ただし、この仕様は、セクション6.10.3で指定されている別の形式のルート最適化をサポートしています。
The Proxy Mobile IPv6 protocol described in this document introduces a new functional entity, the mobile access gateway (MAG). The mobile access gateway is the entity that is responsible for detecting the mobile node's movements to and from the access link and sending the Proxy Binding Update messages to the local mobility anchor. In essence, the mobile access gateway performs mobility management on behalf of a mobile node.
このドキュメントで説明されているプロキシモバイルIPv6プロトコルは、新しい機能エンティティであるモバイルアクセスゲートウェイ（MAG）を紹介します。モバイルアクセスゲートウェイは、アクセスリンクとの間のモバイルノードの動きを検出し、プロキシバインディングアップデートメッセージをローカルモビリティアンカーに送信する責任があるエンティティです。本質的に、モバイルアクセスゲートウェイは、モバイルノードに代わってモビリティ管理を実行します。
The mobile access gateway is a function that typically runs on an access router. However, implementations MAY choose to split this function and run it across multiple systems. The specifics on how that is achieved or the signaling interactions between those functional entities are beyond the scope of this document.
モバイルアクセスゲートウェイは、通常、アクセスルーターで実行される関数です。ただし、実装はこの関数を分割し、複数のシステムで実行することを選択する場合があります。それがどのように達成されるか、またはそれらの機能エンティティ間のシグナル伝達の相互作用の詳細は、このドキュメントの範囲を超えています。
The mobile access gateway has the following key functional roles:
モバイルアクセスゲートウェイには、次の重要な機能的役割があります。
o It is responsible for detecting the mobile node's movements on the access link and for initiating the mobility signaling with the mobile node's local mobility anchor.
o アクセスリンク上のモバイルノードの動きを検出し、モバイルノードのローカルモビリティアンカーを使用したモビリティシグナル伝達を開始する責任があります。
o Emulation of the mobile node's home link on the access link by sending Router Advertisement messages containing the mobile node's home network prefix(es), each prefix carried using the Prefix Information option [RFC4861].
o モバイルノードのホームネットワークプレフィックス（ES）を含むルーター広告メッセージを送信することにより、アクセスリンクでのモバイルノードのホームリンクをエミュレーションします。各プレフィックスは、プレフィックス情報オプション[RFC4861]を使用して運ばれました。
o Responsible for setting up the forwarding for enabling the mobile node to configure one or more addresses from its home network prefix(es) and use it from the attached access link.
o モバイルノードがホームネットワークプレフィックス（ES）から1つ以上のアドレスを構成し、添付のアクセスリンクから使用できるようにするための転送を設定する責任があります。
Every mobile access gateway MUST maintain a Binding Update List. Each entry in the Binding Update List represents a mobile node's mobility binding with its local mobility anchor. The Binding Update List is a conceptual data structure, described in Section 11.1 of [RFC3775].
すべてのモバイルアクセスゲートウェイは、バインディングアップデートリストを維持する必要があります。バインディングアップデートリストの各エントリは、ローカルモビリティアンカーとのモバイルノードのモビリティバインディングを表します。バインディングアップデートリストは、[RFC3775]のセクション11.1で説明されている概念データ構造です。
For supporting this specification, the conceptual Binding Update List entry data structure needs be extended with the following additional fields.
この仕様をサポートするには、概念バインディングアップデートリストエントリデータ構造を次の追加フィールドで拡張する必要があります。
o The identifier of the attached mobile node, MN-Identifier. This identifier is acquired during the mobile node's attachment to the access link through mechanisms outside the scope of this document.
o 添付されたモバイルノード、MN-IDENTIFIERの識別子。この識別子は、このドキュメントの範囲外のメカニズムを介して、アクセスリンクへのモバイルノードのアタッチメント中に取得されます。
o The link-layer identifier of the mobile node's connected interface. This can be acquired from the received Router Solicitation messages from the mobile node or during the mobile node's attachment to the access network. This is typically a link-layer identifier conveyed by the mobile node; however, the specific details on how that is conveyed is out of scope for this specification. If this identifier is not available, this variable length field MUST be set to two (octets) and MUST be initialized to a value of ALL_ZERO.
o モバイルノードの接続インターフェイスのリンク層識別子。これは、モバイルノードからの受信したルーター勧誘メッセージから、またはモバイルノードのアクセスネットワークへの添付中に取得できます。これは通常、モバイルノードによって伝達されるリンク層識別子です。ただし、それがどのように伝えられるかについての具体的な詳細は、この仕様の範囲外です。この識別子が使用できない場合、この可変長フィールドは2つ（オクテット）に設定し、ALL_ZEROの値に初期化する必要があります。
o A list of IPv6 home network prefixes assigned to the mobile node's connected interface. The home network prefix(es) may have been statically configured in the mobile node's policy profile, or, may have been dynamically allocated by the local mobility anchor. Each of these prefix entries will also include the corresponding prefix length.
o モバイルノードの接続インターフェイスに割り当てられたIPv6ホームネットワークプレフィックスのリスト。ホームネットワークのプレフィックス（ES）は、モバイルノードのポリシープロファイルで静的に構成されている可能性があるか、ローカルモビリティアンカーによって動的に割り当てられた可能性があります。これらのプレフィックスエントリにはそれぞれ、対応するプレフィックスの長さも含まれます。
o The Link-local address of the mobile access gateway on the access link shared with the mobile node.
o モバイルノードと共有されるアクセスリンクのモバイルアクセスゲートウェイのリンクローカルアドレス。
o The IPv6 address of the local mobility anchor serving the attached mobile node. This address is acquired from the mobile node's policy profile or from other means.
o 添付されたモバイルノードを提供するローカルモビリティアンカーのIPv6アドレス。このアドレスは、モバイルノードのポリシープロファイルまたは他の手段から取得されます。
o The interface identifier (if-id) of the point-to-point link between the mobile node and the mobile access gateway. This is internal to the mobile access gateway and is used to associate the Proxy Mobile IPv6 tunnel to the access link where the mobile node is attached.
o モバイルノードとモバイルアクセスゲートウェイの間のポイントツーポイントリンクのインターフェイス識別子（IF-ID）。これはモバイルアクセスゲートウェイの内部であり、プロキシモバイルIPv6トンネルをモバイルノードが接続されているアクセスリンクに関連付けるために使用されます。
o The tunnel interface identifier (tunnel-if-id) of the bi-directional tunnel between the mobile node's local mobility anchor and the mobile access gateway. This is internal to the mobile access gateway. The tunnel interface identifier is acquired during the tunnel creation.
o モバイルノードのローカルモビリティアンカーとモバイルアクセスゲートウェイの間の双方向トンネルのトンネルインターフェイス識別子（トンネル-IF-ID）。これは、モバイルアクセスゲートウェイの内部です。トンネル界面識別子は、トンネルの作成中に取得されます。
A mobile node's policy profile contains the essential operational parameters that are required by the network entities for managing the mobile node's mobility service. These policy profiles are stored in a local or a remote policy store. The mobile access gateway and the local mobility anchor MUST be able to obtain a mobile node's policy profile. The policy profile MAY also be handed over to a serving mobile access gateway as part of a context transfer procedure during a handoff or the serving mobile access gateway MAY be able to dynamically generate this profile. The exact details on how this achieved is outside the scope of this document. However, this specification requires that a mobile access gateway serving a mobile node MUST have access to its policy profile.
モバイルノードのポリシープロファイルには、モバイルノードのモビリティサービスを管理するためにネットワークエンティティが必要とする重要な運用パラメーターが含まれています。これらのポリシープロファイルは、ローカルまたはリモートのポリシーストアに保存されています。モバイルアクセスゲートウェイとローカルモビリティアンカーは、モバイルノードのポリシープロファイルを取得できる必要があります。ポリシープロファイルは、ハンドオフ中のコンテキスト転送手順の一部として、モバイル転送手順の一部またはサービングモバイルアクセスゲートウェイがこのプロファイルを動的に生成できるため、サービングモバイルアクセスゲートウェイに引き渡すこともできます。これがどのように達成されるかの正確な詳細は、このドキュメントの範囲外です。ただし、この仕様では、モバイルノードを提供するモバイルアクセスゲートウェイがポリシープロファイルにアクセスできる必要があります。
The following are the mandatory fields of the policy profile:
以下は、ポリシープロファイルの必須フィールドです。
o The mobile node's identifier (MN-Identifier)
o モバイルノードの識別子（Mn-Identifier）
o The IPv6 address of the local mobility anchor (LMAA)
o ローカルモビリティアンカーのIPv6アドレス（LMAA）
The following are the optional fields of the policy profile:
以下は、ポリシープロファイルのオプションのフィールドです。
o The mobile node's IPv6 home network prefix(es) assigned to the mobile node's connected interface. These prefixes have to be maintained on a per-interface basis. There can be multiple unique entries for each interface of the mobile node. The specific details on how the network maintains this association between the prefix set and the interfaces, specially during the mobility session handoff between interfaces, is outside the scope of this document.
o モバイルノードのモバイルノードの接続インターフェイスに割り当てられたモバイルノードのIPv6ホームネットワークプレフィックス（ES）。これらのプレフィックスは、インターフェイスごとに維持する必要があります。モバイルノードの各インターフェイスに複数の一意のエントリがあります。特にインターフェイス間のモビリティセッションのハンドオフ中に、ネットワークがプレフィックスセットとインターフェイス間のこの関連性をどのように維持するかについての特定の詳細は、このドキュメントの範囲外です。
o The mobile node's IPv6 home network Prefix lifetime. This lifetime will be the same for all the hosted prefixes on the link, as they all are part of one mobility session. This value can also be the same for all the mobile node's mobility sessions.
o モバイルノードのIPv6ホームネットワークプレフィックスライフタイム。この寿命は、すべてが1つのモビリティセッションの一部であるため、リンク上のすべてのホストされたプレフィックスで同じです。この値は、すべてのモバイルノードのモビリティセッションでも同じです。
o Supported address configuration procedures (Stateful, Stateless, or both) for the mobile node in the Proxy Mobile IPv6 domain
o
This specification supports only point-to-point access link types, and thus, it assumes that the mobile node and the mobile access gateway are the only two nodes on the access link. The link is assumed to have multicast capability.
この仕様は、ポイントツーポイントアクセスリンクタイプのみをサポートしているため、モバイルノードとモバイルアクセスゲートウェイがアクセスリンク上の2つのノードのみであると想定しています。リンクにはマルチキャスト機能があると想定されています。
This protocol may also be used on other link types, as long as the link is configured in such a way that it emulates point-to-point delivery between the mobile node and the mobile access gateway for all the protocol traffic.
It is also necessary to be able to identify mobile nodes attaching to the link. Requirements relating to this are covered in Section 6.6.
また、リンクに接続するモバイルノードを識別できる必要があります。これに関連する要件は、セクション6.6で説明されています。
Finally, while this specification can operate without link-layer indications of node attachment and detachment to the link, the existence of such indications either on the network or mobile node side improves the resulting performance.
最後に、この仕様はリンク層の表示なしで動作しますが、ノードの添付ファイルとリンクへの分離の表示は、ネットワークまたはモバイルノード側のいずれかの存在が結果のパフォーマンスを向上させます。
A mobile node in the Proxy Mobile IPv6 domain can configure one or more global IPv6 addresses on its interface (using Stateless, Stateful address autoconfiguration procedures or manual address configuration) from the hosted prefix(es) on that link. The Router Advertisement messages sent on the access link specify the address configuration methods permitted on that access link for that mobile node. However, the advertised flags, with respect to the address configuration, will be consistent for a mobile node, on any of the access links in that Proxy Mobile IPv6 domain. Typically, these configuration settings will be based on the domain-wide policy or based on a policy specific to each mobile node.
プロキシモバイルIPv6ドメインのモバイルノードは、そのリンク上のホストされたプレフィックス（ES）からインターフェイス（Stateless、Stateful Address Autoconfiguration Procesturesまたは手動アドレス構成を使用）で1つ以上のグローバルIPv6アドレスを構成できます。アクセスリンクに送信されるルーター広告メッセージは、そのモバイルノードのアクセスリンクで許可されているアドレス構成メソッドを指定します。ただし、アドレス構成に関して広告されたフラグは、そのプロキシモバイルIPv6ドメインのアクセスリンクのいずれかで、モバイルノードで一貫しています。通常、これらの構成設定は、ドメイン全体のポリシーに基づいているか、各モバイルノードに固有のポリシーに基づいています。
When stateless address autoconfiguration is supported on the access link, the mobile node can generate one or more IPv6 addresses from the hosted prefix(es) by standard IPv6 mechanisms such as Stateless Autoconfiguration [RFC4862] or Privacy extensions [RFC4941].
ステートレスアドレスAutoconfigurationがアクセスリンクでサポートされると、モバイルノードは、Stateless Autoconfiguration [RFC4862]やプライバシー拡張[RFC4941]などの標準的なIPv6メカニズムにより、ホストされたプレフィックス（ES）から1つ以上のIPv6アドレスを生成できます。
When stateful address autoconfiguration is supported on the link, the mobile node can obtain the address configuration from the DHCP server located in the Proxy Mobile IPv6 domain, by standard DHCP mechanisms, as specified in [RFC3315]. The obtained address(es) will be from its home network prefix(es). Section 6.11 specifies the details on how this configuration can be achieved.
Stateful Address Autoconfigurationがリンクでサポートされる場合、モバイルノードは、[RFC3315]で指定されているように、標準のDHCPメカニズムにより、プロキシモバイルIPv6ドメインにあるDHCPサーバーからアドレス構成を取得できます。取得したアドレスは、ホームネットワークプレフィックス（es）からのものです。セクション6.11は、この構成の達成方法の詳細を指定します。
Additionally, other address configuration mechanisms specific to the access link between the mobile node and the mobile access gateway may also be used for delivering the address configuration to the mobile node. This specification does not modify the behavior of any of the standard IPv6 address configuration mechanisms.
さらに、モバイルノードとモバイルアクセスゲートウェイ間のアクセスリンクに固有の他のアドレス構成メカニズムも、アドレス構成をモバイルノードに配信するために使用できます。この仕様は、標準のIPv6アドレス構成メカニズムのいずれの動作を変更しません。
When a mobile node attaches to an access link connected to the mobile access gateway, the deployed access security protocols on that link SHOULD ensure that the network-based mobility management service is offered only after authenticating and authorizing the mobile node for that service. The exact specifics on how this is achieved or the interactions between the mobile access gateway and the access security service are outside the scope of this document. This specification goes with the stated assumption of having an established trust between the mobile node and the mobile access gateway before the protocol operation begins.
モバイルノードがモバイルアクセスゲートウェイに接続されたアクセスリンクに接続すると、そのリンクに展開されたアクセスセキュリティプロトコルは、そのサービスのモバイルノードを認証および承認した後にのみ、ネットワークベースのモビリティ管理サービスが提供されるようにする必要があります。これがどのように達成されるか、またはモバイルアクセスゲートウェイとアクセスセキュリティサービスの間の相互作用に関する正確な詳細は、このドキュメントの範囲外です。この仕様には、プロトコル操作が開始される前に、モバイルノードとモバイルアクセスゲートウェイの間に確立された信頼を持つという述べられた仮定があります。
All the network entities in a Proxy Mobile IPv6 domain MUST be able to identify a mobile node, using its MN-Identifier. This identifier MUST be stable and unique across the Proxy Mobile IPv6 domain. The mobility entities in the Proxy Mobile IPv6 domain MUST be able to use this identifier in the signaling messages and unambiguously identify a given mobile node. The following are some of the considerations related to this MN-Identifier.
プロキシモバイルIPv6ドメイン内のすべてのネットワークエンティティは、MN-IDENTIFIERを使用してモバイルノードを識別できる必要があります。この識別子は、プロキシモバイルIPv6ドメイン全体で安定して一意でなければなりません。プロキシモバイルIPv6ドメインのモビリティエンティティは、この識別子を信号メッセージで使用し、特定のモバイルノードを明確に識別できる必要があります。以下は、このMn-Identifierに関連する考慮事項の一部です。
o The MN-Identifier is typically obtained as part of the access authentication or from a notified network attachment event. In cases where the user identifier authenticated during access authentication uniquely identifies a mobile node, the MN-Identifier MAY be the same as the user identifier. However, the user identifier MUST NOT be used if it identifies a user account that can be used from more than one mobile node operating in the same Proxy Mobile IPv6 domain.
o Mn-Identifierは通常、アクセス認証の一部として、または通知されたネットワーク添付ファイルイベントから取得されます。アクセス認証中に認証されたユーザー識別子がモバイルノードを一意に識別する場合、MN-IDENTIFIERはユーザー識別子と同じである場合があります。ただし、同じプロキシモバイルIPv6ドメインで動作する複数のモバイルノードから使用できるユーザーアカウントを識別する場合、ユーザー識別子を使用しないでください。
o In some cases, the obtained identifier, as part of the access authentication, can be a temporary identifier and further that temporary identifier may be different at each re-authentication. However, the mobile access gateway MUST be able to use this temporary identifier and obtain the mobile node's stable identifier from the policy store. For instance, in AAA-based systems, the Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identifier [RFC4372] may be used, as long as it uniquely identifies a mobile node, and not a user account that can be used with multiple mobile nodes.
o 場合によっては、アクセス認証の一部として得られた識別子は、一時的な識別子であり、さらに一時的な識別子が再認証されている場合に異なる場合があります。ただし、モバイルアクセスゲートウェイは、この一時識別子を使用して、ポリシーストアからモバイルノードの安定した識別子を取得できる必要があります。たとえば、AAAベースのシステムでは、リモート認証ダイヤルインユーザーサービス（RADIUS）属性、充電可能なユーザー識別子[RFC4372]が使用される場合があります。複数のモバイルノードで使用できます。
o In some cases and for privacy reasons, the MN-Identifier that the policy store delivers to the mobile access gateway may not be the true identifier of the mobile node. However, the mobility access gateway MUST be able to use this identifier in the signaling messages exchanged with the local mobility anchor.
o 場合によっては、プライバシー上の理由で、ポリシーストアがモバイルアクセスゲートウェイに配信するMn-Identifierは、モバイルノードの真の識別子ではない場合があります。ただし、Mobility Access Gatewayは、ローカルモビリティアンカーと交換された信号メッセージでこの識別子を使用できる必要があります。
o The mobile access gateway MUST be able to identify the mobile node by its MN-Identifier, and it MUST be able to associate this identity to the point-to-point link shared with the mobile node.
o モバイルアクセスゲートウェイは、Mn-Identifierによってモバイルノードを識別できる必要があり、このアイデンティティをモバイルノードと共有するポイントツーポイントリンクに関連付けることができなければなりません。
One of the key functions of a mobile access gateway is to emulate the mobile node's home network on the access link. It must ensure the mobile node does not detect any change with respect to its layer-3 attachment even after it changes its point of attachment in that Proxy Mobile IPv6 domain.
モバイルアクセスゲートウェイの重要な機能の1つは、アクセスリンク上のモバイルノードのホームネットワークをエミュレートすることです。モバイルノードが、そのプロキシモバイルIPv6ドメインでの添付ポイントを変更した後でも、レイヤー3アタッチメントに関する変更を検出しないようにする必要があります。
For emulating the mobile node's home link on the access link, the mobile access gateway must be able to send Router Advertisement messages advertising the mobile node's home network prefix(es) carried using the Prefix Information option(s) [RFC4861] and with other address configuration parameters consistent with its home link properties. Typically, these configuration settings will be based on the domain-wide policy or based on a policy specific to each mobile node.
アクセスリンクでモバイルノードのホームリンクをエミュレートするために、モバイルアクセスゲートウェイは、プレフィックス情報オプション（s）[RFC4861]およびその他のアドレスを使用して運ばれるモバイルノードのホームネットワークプレフィックス（ES）を広告するルーター広告メッセージを送信できる必要があります。構成パラメータのホームリンクプロパティと一致しています。通常、これらの構成設定は、ドメイン全体のポリシーに基づいているか、各モバイルノードに固有のポリシーに基づいています。
Typically, the mobile access gateway learns the mobile node's home network prefix(es) details from the received Proxy Binding Acknowledgement message, or it may obtain them from the mobile node's policy profile. However, the mobile access gateway SHOULD send the Router Advertisements advertising the mobile node's home network prefix(es) only after successfully completing the binding registration with the mobile node's local mobility anchor.
通常、モバイルアクセスゲートウェイは、受信したプロキシバインディング確認メッセージからモバイルノードのホームネットワークプレフィックス（ES）の詳細を学習するか、モバイルノードのポリシープロファイルからそれらを取得する場合があります。ただし、モバイルアクセスゲートウェイは、モバイルノードのローカルモビリティアンカーとのバインディング登録を正常に完了した後にのみ、モバイルノードのホームネットワークプレフィックス（ES）を宣伝するルーター広告を送信する必要があります。
When advertising the home network prefix(es) in the Router Advertisement messages, the mobile access gateway MAY set the prefix lifetime value for the advertised prefix(es) to any chosen value at its own discretion. An implementation MAY choose to tie the prefix lifetime to the mobile node's binding lifetime. The prefix lifetime can also be an optional configuration parameter in the mobile node's policy profile.
ルーター広告メッセージにホームネットワークのプレフィックス（ES）を宣伝する場合、モバイルアクセスゲートウェイは、広告されたプレフィックスのプレフィックスライフタイム値を、独自の裁量で選択した値に設定する場合があります。実装は、プレフィックスの寿命をモバイルノードのバインディングライフタイムに結び付けることを選択する場合があります。プレフィックスの寿命は、モバイルノードのポリシープロファイルのオプションの構成パラメーターでもあります。
A mobile node in the Proxy Mobile IPv6 domain, as it moves from one mobile access gateway to the other, will continue to detect its home network and does not detect a change of layer-3 attachment. Every time the mobile node attaches to a new link, the event related to the interface state change will trigger the mobile node to perform Duplicate Address Detection (DAD) operation on the link-local and global address(es). However, if the mobile node is Detecting Network Attachment in IPv6 (DNAv6) enabled, as specified in [DNAV6], it may not detect the link change due to DNAv6 optimizations and may not trigger the duplicate address detection (DAD) procedure for its existing addresses, which may potentially lead to address collisions after the mobile node's handoff to a new link.
プロキシモバイルIPv6ドメインのモバイルノードは、あるモバイルアクセスゲートウェイからもう一方のモバイルアクセスゲートウェイに移動するため、ホームネットワークを検出し続け、レイヤー3アタッチメントの変更を検出しません。モバイルノードが新しいリンクに接続するたびに、インターフェイス状態の変更に関連するイベントは、モバイルノードをトリガーし、リンクローカルおよびグローバルアドレス（ES）で重複するアドレス検出（DAD）操作を実行します。ただし、[DNAV6]で指定されているように、モバイルノードがIPv6（DNAV6）の有効化のネットワークアタッチメントを検出している場合、DNAV6の最適化によりリンクの変更を検出しない場合があり、既存のアドレス検出（DAD）手順をトリガーしない場合があります。アドレスは、モバイルノードの新しいリンクへのハンドオフ後に衝突する可能性がある可能性があります。
The issue of address collision is not relevant to the mobile node's global address(es). Since the assigned home network prefix(es) are for the mobile node's exclusive usage, no other node shares an address (other than Subnet-Router anycast address that is configured by the mobile access gateway) from the prefix(es), and so the uniqueness for the mobile node's global address is assured on the access link.
アドレス衝突の問題は、モバイルノードのグローバルアドレス（ES）には関係ありません。割り当てられたホームネットワークプレフィックスはモバイルノードの排他的使用用であるため、プレフィックス（ES）からのアドレス（モバイルアクセスゲートウェイによって構成されたサブネットルーターのanyCastアドレス以外）を共有することはありません。モバイルノードのグローバルアドレスの一意性は、アクセスリンクで保証されています。
The issue of address collision is however relevant to the mobile node's link-local addresses since the mobile access gateway and the mobile node will have link-local addresses configured from the same link-local prefix (FE80::/64). This leaves a room for link-local address collision between the two neighbors (i.e., the mobile node and the mobile access gateway) on that access link. For solving this problem, this specification requires that the link-local address that the mobile access gateway configures on the point-to-point link shared with a given mobile node be generated by the local mobility anchor and be stored in the mobile node's Binding Cache entry. This address will not change for the duration of that mobile node's mobility session and can be provided to the serving mobile access gateway at every mobile node's handoff, as part of the Proxy Mobile IPv6 signaling messages. The specific method by which the local mobility anchor generates the link-local address is out of scope for this specification.
ただし、モバイルアクセスゲートウェイとモバイルノードには、同じリンクローカルプレフィックス（FE80 ::/64）から構成されたリンクローカルアドレスがあるため、アドレス衝突の問題はモバイルノードのリンクローカルアドレスに関連しています。これにより、そのアクセスリンクには、2人のネイバー（つまり、モバイルノードとモバイルアクセスゲートウェイ）の間のリンクローカルアドレスの衝突の余地が残ります。この問題を解決するには、この仕様では、特定のモバイルノードと共有されるポイントツーポイントリンクでモバイルアクセスゲートウェイが構成するリンクローカルアドレスをローカルモビリティアンカーによって生成し、モバイルノードのバインディングキャッシュに保存する必要があります。エントリ。このアドレスは、そのモバイルノードのモビリティセッションの期間中は変更されず、プロキシモバイルIPv6シグナリングメッセージの一部として、すべてのモバイルノードのハンドオフでサービングモバイルアクセスゲートウェイに提供できます。ローカルモビリティアンカーがリンクローカルアドレスを生成する特定の方法は、この仕様の範囲外です。
It is highly desirable that the access link on the mobile access gateway shared with the mobile node be provisioned in such a way that before the mobile node completes the DAD operation [RFC4862] on its link-local address, the mobile access gateway on that link is aware of its own link-local address provided by the local mobility anchor that it needs to use on that access link. This essentially requires a successful completion of the Proxy Mobile IPv6 signaling by the mobile access gateway before the mobile node completes the DAD operation. This can be achieved by ensuring that link-layer attachment does not complete until the Proxy Mobile IPv6 signaling is completed. Alternatively, network and local mobility anchor capacity and signaling retransmission timers can be provisioned in such a way that signaling is likely to complete during the default waiting period associated with the DAD process.
モバイルノードと共有されたモバイルアクセスゲートウェイのアクセスリンクは、モバイルノードがリンクローカルアドレスであるDADオペレーション[RFC4862]を完了する前に、そのリンクのモバイルアクセスゲートウェイを完了するようにプロビジョニングされることが非常に望ましいことです。そのアクセスリンクで使用する必要があるローカルモビリティアンカーによって提供される独自のリンクローカルアドレスを認識しています。これには、モバイルノードがDAD操作を完了する前に、モバイルアクセスゲートウェイによるプロキシモバイルIPv6シグナル伝達を正常に完了する必要があります。これは、プロキシモバイルIPv6シグナル伝達が完了するまで、リンク層のアタッチメントが完了しないようにすることで実現できます。あるいは、ネットワークおよびローカルモビリティのアンカー容量とシグナリング再送信タイマーは、DADプロセスに関連するデフォルトの待機期間中に信号が完了する可能性が高いようにプロビジョニングできます。
Optionally, implementations MAY choose to configure a fixed link-local address across all the access links in a Proxy Mobile IPv6 domain and without a need for carrying this address from the local mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 signaling messages. The configuration variable FixedMAGLinkLocalAddressOnAllAccessLinks determines the enabled mode in that Proxy Mobile IPv6 domain.
オプションで、実装は、プロキシモバイルIPv6ドメイン内のすべてのアクセスリンクにわたって固定リンクローカルアドレスを構成することを選択する場合があり、ローカルモビリティアンカーからプロキシモバイルIPv6シグナリングメッセージのモバイルアクセスゲートウェイにこのアドレスを運ぶ必要はありません。構成変数固定MaglinklinklocaladdressonAllAccesSlinksは、そのプロキシモバイルIPv6ドメインの有効なモードを決定します。
1. After detecting a new mobile node on its access link, the mobile access gateway MUST identify the mobile node and acquire its MN-Identifier. If it determines that the network-based mobility management service needs to be offered to the mobile node, it MUST send a Proxy Binding Update message to the local mobility anchor.
1. アクセスリンクで新しいモバイルノードを検出した後、モバイルアクセスゲートウェイはモバイルノードを識別し、そのMN-IDENTIFIERを取得する必要があります。ネットワークベースのモビリティ管理サービスをモバイルノードに提供する必要があると判断した場合、ローカルモビリティアンカーにプロキシバインディングアップデートメッセージを送信する必要があります。
2. The Proxy Binding Update message MUST include the Mobile Node Identifier option [RFC4283], carrying the MN-Identifier for identifying the mobile node.
2. プロキシバインディングアップデートメッセージには、モバイルノードを識別するためにMN-IDENTIFIERを運ぶモバイルノード識別子オプション[RFC4283]を含める必要があります。
3. The Home Network Prefix option(s) MUST be present in the Proxy Binding Update message. If the mobile access gateway learns the mobile node's home network prefix(es) either from its policy store or from other means, the mobile access gateway MAY choose to request the local mobility anchor to allocate the specific prefix(es) by including a Home Network Prefix option for each of those requested prefixes. The mobile access gateway MAY also choose to include just one Home Network Prefix option with the prefix value of ALL_ZERO, for requesting the local mobility anchor to do the prefix assignment. However, when including a Home Network Prefix option with the prefix value of ALL_ZERO, there MUST be only one instance of the Home Network prefix option in the request.
3. ホームネットワークのプレフィックスオプションは、プロキシバインディングアップデートメッセージに存在する必要があります。モバイルアクセスゲートウェイがモバイルノードのホームネットワークプレフィックスをポリシーストアまたは他の手段から学習する場合、モバイルアクセスゲートウェイは、ホームネットワークを含めることにより、特定のプレフィックスを割り当てるためにローカルモビリティアンカーを要求することを選択できます。リクエストされたプレフィックスごとにプレフィックスオプション。モバイルアクセスゲートウェイは、プレフィックスの割り当てを実行するためにローカルモビリティアンカーに要求するために、ALL_ZEROのプレフィックス値に1つのホームネットワークプレフィックスオプションのみを含めることもできます。ただし、ALL_ZEROのプレフィックス値にホームネットワークプレフィックスオプションを含める場合、リクエストにホームネットワークプレフィックスオプションのインスタンスが1つだけある必要があります。
4. The Handoff Indicator option MUST be present in the Proxy Binding Update message. The Handoff Indicator field in the Handoff Indicator option MUST be set to a value indicating the handoff hint.
4. ハンドオフインジケータオプションは、プロキシバインディングアップデートメッセージに存在する必要があります。ハンドオフインジケーターオプションのハンドオフインジケータフィールドは、ハンドオフのヒントを示す値に設定する必要があります。
* The Handoff Indicator field MUST be set to a value of 1 (Attachment over a new interface) if the mobile access gateway determines (under the Handoff Indicator considerations specified in this section) that the mobile node's current attachment to the network over this interface is not as a result of a handoff of an existing mobility session (over the same interface or through a different interface), but as a result of an attachment over a new interface. This essentially serves as a request to the local mobility anchor to create a new mobility session and not update any existing Binding Cache entry created for the same mobile node connected to the Proxy Mobile IPv6 domain through a different interface.
* モバイルアクセスゲートウェイが（このセクションで指定されているハンドオフインジケーターの考慮事項の下で）モバイルノードの現在のネットワークへの現在の添付ファイルがこのインターフェイスに添付されていない場合、ハンドオフインジケータフィールドは1（新しいインターフェイス上の添付ファイル）に設定する必要があります。既存のモビリティセッションのハンドオフの結果として（同じインターフェイスを介して、または異なるインターフェイスを介して）が、新しいインターフェイス上の添付ファイルの結果として。これは本質的に、ローカルモビリティアンカーへのリクエストとして機能し、新しいモビリティセッションを作成し、異なるインターフェイスを介してプロキシモバイルIPv6ドメインに接続された同じモバイルノードに対して作成された既存のバインディングキャッシュエントリを更新しません。
* The Handoff Indicator field MUST be set to a value of 2 (Handoff between two different interfaces of the mobile node) if the mobile access gateway definitively knows the mobile node's current attachment is due to a handoff of an existing mobility session between two different interfaces of the mobile node.
* モバイルアクセスゲートウェイがモバイルノードの現在の添付ファイルを明確に知っている場合、ハンドオフインジケータフィールドは2（モバイルノードの2つの異なるインターフェイス間のハンドオフ）に設定する必要があります。モバイルノード。
* The Handoff Indicator field MUST be set to a value of 3 (Handoff between mobile access gateways for the same interface) if the mobile access gateway definitively knows the mobile node's current attachment is due to a handoff of an existing mobility session between two mobile access gateways and for the same interface of the mobile node.
* モバイルアクセスゲートウェイがモバイルノードの現在の添付ファイルを明確に知っている場合、ハンドオフインジケーターフィールドは3（同じインターフェイスのモバイルアクセスゲートウェイ間のハンドオフ）に設定する必要があります（モバイルアクセスゲートウェイ間のハンドオフ）。モバイルノードの同じインターフェイスの場合。
* The Handoff Indicator field MUST be set to a value of 4 (Handoff state unknown) if the mobile access gateway cannot determine if the mobile node's current attachment is due to a handoff of an existing mobility session.
* モバイルアクセスゲートウェイがモバイルノードの現在の添付ファイルが既存のモビリティセッションのハンドオフによるものであるかどうかを判断できない場合、ハンドオフインジケータフィールドは4（ハンドオフ状態不明）の値に設定する必要があります。
5. The mobile access gateway MUST apply the below considerations when choosing the value for the Handoff Indicator field.
5. モバイルアクセスゲートウェイは、ハンドオフインジケータフィールドの値を選択するときに、以下の考慮事項を適用する必要があります。
* The mobile access gateway can choose to use the value 2 (Handoff between two different interfaces of the mobile node), only when it knows that the mobile node has, on purpose, switched from one interface to another, and the previous interface is going to be disabled. It may know this due to a number of factors. For instance, most cellular networks have controlled handovers where the network knows that the host is moving from one attachment to another. In this situation, the link-layer mechanism can inform the mobility functions that this is indeed a movement, not a new attachment.
* モバイルアクセスゲートウェイは、モバイルノードが意図的にあるインターフェイスから別のインターフェイスに切り替えられ、前のインターフェイスが次のインターフェイスに切り替えられていることを知っている場合にのみ、値2（モバイルノードの2つの異なるインターフェイス間のハンドオフ）を使用することを選択できます。無効になります。多くの要因のためにこれを知っているかもしれません。たとえば、ほとんどのセルラーネットワークには、ネットワークがホストがあるアタッチメントから別のアタッチメントに移動していることをネットワークが知っているハンドオーバーを制御しています。この状況では、リンク層メカニズムは、これが実際に新しい愛着ではなく、実際に動きであることをモビリティ関数に通知することができます。
* Some link layers have link-layer identifiers that can be used to distinguish (a) the movement of a particular interface to a new attachment from (b) the attachment of a new interface from the same host. Option value 3 (Handoff between mobile access gateways for the same interface) is appropriate in case (a) and a value of 1 (Attachment over a new interface) in case (b).
* 一部のリンクレイヤーには、（a）特定のインターフェイスの移動を（b）同じホストからの新しいインターフェイスのアタッチメントからの新しいアタッチメントへの移動に使用できるリンク層識別子があります。オプション値3（同じインターフェイスのモバイルアクセスゲートウェイ間のハンドオフ）は、ケース（a）とケース（b）の値（新しいインターフェイス上の添付ファイル）の値に適しています。
* The mobile access gateway MUST NOT set the option value to 2 (Handoff between two different interfaces of the mobile node) or 3 (Handoff between mobile access gateways for the same interface) if it cannot be determined that the mobile node can move the address between the interfaces involved in the handover or that it is the same interface that has moved. Otherwise, Proxy Mobile IPv6-unaware hosts that have multiple physical interfaces to the same domain may suffer unexpected failures.
* モバイルアクセスゲートウェイは、オプション値を2（モバイルノードの2つの異なるインターフェイス間のハンドオフ）または3（同じインターフェイスのモバイルアクセスゲートウェイ間のハンドオフ）に設定してはなりません。モバイルノードがアドレスを移動できることを判断できない場合は、ハンドオーバーに関係するインターフェイス、または移動したのと同じインターフェイスです。それ以外の場合、同じドメインに複数の物理インターフェイスを持つプロキシモバイルIPv6-UnaWareホストは、予期しない障害に苦しむ可能性があります。
* Where no support from the link layer exists, the host and the network would need to inform each other about the intended movement. The Proxy Mobile IPv6 protocol does not specify this and simply requires that knowledge about movements can be derived either from the link-layer or from somewhere else. The method by which this is accomplished is outside the scope of this specification.
* リンクレイヤーからのサポートが存在しない場合、ホストとネットワークは、意図した動きについて互いに通知する必要があります。プロキシモバイルIPv6プロトコルはこれを指定しておらず、単に動きに関する知識をリンク層または他の場所から導き出すことができます。これが達成される方法は、この仕様の範囲外です。
6. Either the Timestamp option or a valid sequence number maintained on a per mobile node's mobility session basis as specified in [RFC3775] (if the Sequence-Number-based scheme is in use) MUST be present. This can be determined based on the value of the configuration flag TimestampBasedApproachInUse. When Timestamp option is added to the message, the mobile access gateway SHOULD also set the Sequence Number field to a value of a monotonically increasing counter (maintained at each mobile access gateway and not to be confused with the per mobile node sequence number specified in [RFC3775]). The local mobility anchor will ignore this field when there is a Timestamp option present in the request, but will return the same value in the Proxy Binding Acknowledgement message. This will be useful for matching the reply to the request message.
6. [RFC3775]で指定されているように、モバイルノードあたりのモビリティセッションベースで維持されているタイムスタンプオプションまたは有効なシーケンス番号（シーケンス番号ベースのスキームが使用されている場合）が存在する必要があります。これは、Configuration Flag TimestAmpasedAppRoachinuseの値に基づいて決定できます。タイムスタンプオプションがメッセージに追加された場合、モバイルアクセスゲートウェイは、シーケンス番号フィールドを単調に増加させるカウンターの値に設定する必要があります（各モバイルアクセスゲートウェイで維持され、[[）]で指定されたモバイルノードシーケンス番号と混同しないようにする必要があります。RFC3775]）。ローカルモビリティアンカーは、リクエストに存在するタイムスタンプオプションがある場合、このフィールドを無視しますが、プロキシバインディング確認メッセージで同じ値を返します。これは、リクエストメッセージへの返信を一致させるのに役立ちます。
7. The Mobile Node Link-layer Identifier option carrying the link-layer identifier of the currently attached interface MUST be present in the Proxy Binding Update message, if the mobile access gateway is aware of the same. If the link-layer identifier of the currently attached interface is not known or if the identifier value is ALL_ZERO, this option MUST NOT be present.
7. モバイルアクセスゲートウェイが同じことを認識している場合、現在添付されているインターフェイスのリンク層識別子を運ぶモバイルノードリンク層識別子オプションオプションは、プロキシバインディングアップデートメッセージに存在する必要があります。現在添付されているインターフェイスのリンク層識別子が不明な場合、または識別子値がall_zeroの場合、このオプションを存在しないでください。
8. The Access Technology Type option MUST be present in the Proxy Binding Update message. The access technology type field in the option SHOULD be set to the type of access technology by which the mobile node is currently attached to the mobile access gateway.
8. アクセステクノロジータイプオプションは、プロキシバインディングアップデートメッセージに存在する必要があります。オプションのアクセステクノロジータイプフィールドは、モバイルノードが現在モバイルアクセスゲートウェイに接続されているアクセステクノロジーのタイプに設定する必要があります。
9. The Link-local Address option MUST be present in the Proxy Binding Update message only if the value of the configuration variable FixedMAGLinkLocalAddressOnAllAccessLinks is set to a value of ALL_ZERO; otherwise, the Link-local Address option MUST NOT be present in the request. Considerations from Section 6.8 MUST be applied when using the Link-local Address option.
9. Link-Localアドレスオプションは、構成変数sixedmaglinklocaladdressonalacscesslinksの値がall_zeroの値に設定されている場合にのみ、プロキシバインド更新メッセージに存在する必要があります。それ以外の場合、リクエストにLink-Localアドレスオプションが存在しないでください。Link-Localアドレスオプションを使用する場合は、セクション6.8からの考慮事項を適用する必要があります。
* For querying the local mobility anchor to provide the link-local address that it should use on the point-to-point link shared with the mobile node, this option MUST be set to ALL_ZERO value. This essentially serves as a request to the local mobility anchor to provide the link-local address that it can use on the access link shared with the mobile node.
* ローカルモビリティアンカーを照会して、モバイルノードと共有されるポイントツーポイントリンクで使用するリンクローカルアドレスを提供するには、このオプションをALL_ZERO値に設定する必要があります。これは本質的に、ローカルモビリティアンカーへのリクエストとして機能し、モバイルノードと共有されるアクセスリンクで使用できるリンクローカルアドレスを提供します。
10. The Proxy Binding Update message MUST be constructed as specified in Section 6.9.1.5.
10. プロキシバインディングアップデートメッセージは、セクション6.9.1.5で指定されているように構築する必要があります。
11. If there is no existing Binding Update List entry for that mobile node, the mobile access gateway MUST create a Binding Update List entry for the mobile node upon sending the Proxy Binding Update message.
11. そのモバイルノードの既存のバインディングアップデートリストエントリがない場合、モバイルアクセスゲートウェイは、プロキシバインディングアップデートメッセージを送信する際に、モバイルノードのバインディングアップデートリストエントリを作成する必要があります。
On receiving a Proxy Binding Acknowledgement message (format specified in Section 8.2) from the local mobility anchor, the mobile access gateway MUST process the message as specified below.
ローカルモビリティアンカーからプロキシバインド確認メッセージ（セクション8.2で指定された形式）を受信すると、モバイルアクセスゲートウェイは、以下に指定されたメッセージを処理する必要があります。
1. The received Proxy Binding Acknowledgement message (a Binding Acknowledgement message with the (P) flag set to value of 1) MUST be authenticated as described in Section 4. When IPsec is used for message authentication, the SPI in the IPsec header [RFC4306] of the received packet is needed for locating the security association, for authenticating the Proxy Binding Acknowledgement message.
1. 受信したプロキシバインディング承認メッセージ（（p）フラグを値1に設定したバインディング承認メッセージ）は、セクション4で説明するように認証する必要があります。受信したパケットは、プロキシバインディングの確認メッセージを認証するために、セキュリティ協会を見つけるために必要です。
2. The mobile access gateway MUST observe the rules described in Section 9.2 of [RFC3775] when processing Mobility Headers in the received Proxy Binding Acknowledgement message.
2. Mobile Access Gatewayは、受信したプロキシバインディング確認メッセージでモビリティヘッダーを処理するときに、[RFC3775]のセクション9.2で説明されているルールを遵守する必要があります。
3. The mobile access gateway MUST apply the considerations specified in Section 5.5 for processing the Sequence Number field and the Timestamp option (if present) in the message.
3. モバイルアクセスゲートウェイは、メッセージのシーケンス番号フィールドとタイムスタンプオプション（存在する場合）を処理するためにセクション5.5で指定された考慮事項を適用する必要があります。
4. The mobile access gateway MUST ignore any checks, specified in [RFC3775], related to the presence of a Type 2 Routing header in the Proxy Binding Acknowledgement message.
4. モバイルアクセスゲートウェイは、プロキシバインディング確認メッセージにタイプ2ルーティングヘッダーの存在に関連する[RFC3775]で指定されたチェックを無視する必要があります。
5. The mobile access gateway MAY use the mobile node identifier present in the Mobile Node Identifier option for matching the response to the request messages that it sent recently. However, if there is more than one request message in its request queue for the same mobile node, the sequence number field can be used for identifying the exact message from those messages. There are other ways to achieve this and implementations are free to adopt the best approach that suits their implementation. Additionally, if the received Proxy Binding Acknowledgement message does not match any of the Proxy Binding Update messages that it sent recently, the message MUST be ignored.
5. モバイルアクセスゲートウェイは、最近送信したリクエストメッセージへの応答を一致させるために、モバイルノード識別子オプションに存在するモバイルノード識別子を使用できます。ただし、同じモバイルノードのリクエストキューに複数の要求メッセージがある場合、それらのメッセージからの正確なメッセージを識別するためにシーケンス番号フィールドを使用できます。これを達成する他の方法があり、実装は実装に合った最良のアプローチを自由に採用することができます。さらに、受信したプロキシバインディングの確認メッセージが、最近送信したプロキシバインディングアップデートメッセージのいずれかと一致しない場合、メッセージは無視する必要があります。
6. If the received Proxy Binding Acknowledgement message has any one or more of the following options, Handoff Indicator option, Access Technology Type option, Mobile Node Link-layer Identifier option, Mobile Node Identifier option, carrying option values that are different from the option values present in the corresponding request (Proxy Binding Update) message, the message MUST be ignored as the local mobility anchor is expected to echo back all these listed options and with the same option values in the reply message. In this case, the mobile access gateway MUST NOT retransmit the Proxy Binding Update message until an administrative action is taken.
6. 受信したプロキシバインディング承認メッセージに次の1つ以上のオプション、ハンドオフインジケーターオプション、アクセステクノロジータイプオプション、モバイルノードリンクレイヤー識別子オプション、モバイルノード識別子オプション、存在するオプション値とは異なるオプション値を運ぶモバイルノード識別子オプションがある場合対応するリクエスト（プロキシバインディングアップデート）メッセージでは、ローカルモビリティアンカーがこれらすべてのリストされたオプションをエコーし、応答メッセージに同じオプション値を使用してエコーすることが期待されるため、メッセージを無視する必要があります。この場合、Mobile Access Gatewayは、管理アクションが実行されるまでプロキシバインディング更新メッセージを再送信してはなりません。
7. If the received Proxy Binding Acknowledgement message has the Status field value set to PROXY_REG_NOT_ENABLED (Proxy registration not enabled for the mobile node), the mobile access gateway SHOULD NOT send a Proxy Binding Update message again for that mobile node until an administrative action is taken. It MUST deny the mobility service to that mobile node.
7. 受信したプロキシバインド確認メッセージのステータスフィールド値がproxy_reg_not_enabledに設定されている場合（モバイルノードではプロキシ登録が有効になっていない）、モバイルアクセスゲートウェイは、そのモバイルノードのプロキシバインディング更新メッセージを再度送信してはなりません。そのモバイルノードへのモビリティサービスを拒否する必要があります。
8. If the received Proxy Binding Acknowledgement message has the Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp value lower than previously accepted value), the mobile access gateway SHOULD try to register again to reassert the mobile node's presence on its access link. The mobile access gateway is not specifically required to synchronize its clock upon receiving this error code.
8. 受信したプロキシバインディングの確認メッセージにステータスフィールド値がtimestamp_lower_than_prev_acceptedに設定されている場合（以前に受け入れられた値よりも低いタイムスタンプ値）、モバイルアクセスゲートウェイは、アクセスリンクでモバイルノードの存在を再確認するために再度登録しようとするはずです。モバイルアクセスゲートウェイは、このエラーコードを受信したときにクロックを同期するために特に必要ではありません。
9. If the received Proxy Binding Acknowledgement message has the Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp value), the mobile access gateway SHOULD try to register again only after it has synchronized its clock to a common time source that is used by all the mobility entities in that domain for their clock synchronization. The mobile access gateway SHOULD NOT synchronize its clock to the local mobility anchor's system clock, based on the timestamp present in the received message.
9. 受信したプロキシバインディング承認メッセージのステータスフィールド値がTimestamp_Mismatch（無効なタイムスタンプ値）に設定されている場合、モバイルアクセスゲートウェイは、すべてのモビリティエンティティで使用される一般的な時間ソースにクロックを同期した後にのみ再度登録する必要があります時計同期のためのそのドメイン。モバイルアクセスゲートウェイは、受信したメッセージに存在するタイムスタンプに基づいて、クロックをローカルモビリティアンカーのシステムクロックに同期させないでください。
10. If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (The mobile node is not authorized for one or more of the requesting home network prefixes), the mobile access gateway SHOULD NOT request the same prefix(es) again, but MAY request the local mobility anchor to do the assignment of prefix(es) by including only one Home Network Prefix option with the prefix value set to ALL_ZERO.
10. 受信したプロキシバインド確認メッセージのステータスフィールド値がnot_authorized_for_home_network_prefixに設定されている場合（モバイルノードは1つ以上のリクエストホームネットワークのプレフィックスに対して許可されていません）、モバイルアクセスゲートウェイは再び同じプレフィックス（es）を要求する必要はありませんが、ALL_ZEROに設定されたプレフィックス値に1つのホームネットワークプレフィックスオプションのみを含めることにより、ローカルモビリティアンカーにプレフィックス（ES）の割り当てを行うように要求する場合があります。
11. If the received Proxy Binding Acknowledgement message has the Status field value set to any value greater than or equal to 128 (i.e., if the binding is rejected), the mobile access gateway MUST NOT advertise the mobile node's home network prefix(es) in the Router Advertisement messages sent on that access link and MUST deny the mobility service to the mobile node by not forwarding any packets received from the mobile node using an address from the home network prefix(es). It MAY also tear down the point-to-point link shared with the mobile node.
11. 受信したプロキシバインディングの確認メッセージに、ステータスフィールド値が128以上の値に設定されている場合（つまり、バインディングが拒否された場合）、モバイルアクセスゲートウェイはモバイルノードのホームネットワークプレフィックス（ES）を宣伝してはなりません。そのアクセスリンクに送信されたルーター広告メッセージは、ホームネットワークプレフィックス（ES）からのアドレスを使用してモバイルノードから受信したパケットを転送しないことにより、モバイルノードへのモビリティサービスを拒否する必要があります。また、モバイルノードと共有されるポイントツーポイントリンクを取り壊す可能性があります。
12. If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted), the mobile access gateway MUST establish a bi-directional tunnel to the local mobility anchor (if there is no existing bi-directional tunnel to that local mobility anchor). Considerations from Section 5.6.1 MUST be applied for managing the dynamically created bi-directional tunnel.
12. 受信したプロキシバインディングの確認メッセージのステータスフィールド値が0に設定されている場合（プロキシバインディングアップデートが受け入れられます）、モバイルアクセスゲートウェイはローカルモビリティアンカーに双方向トンネルを確立する必要があります（その既存の双方向トンネルがない場合ローカルモビリティアンカー）。セクション5.6.1の考慮事項は、動的に作成された双方向トンネルの管理に適用する必要があります。
13. The mobile access gateway MUST set up the route for forwarding the packets received from the mobile node using address(es) from its home network prefix(es) through the bi-directional setup for that mobile node. The created tunnel and the routing state MUST result in the forwarding behavior on the mobile access gateway as specified in Section 6.10.5.
13. モバイルアクセスゲートウェイは、モバイルネットワークのプレフィックス（ES）からのアドレス（ES）を使用して、モバイルノードから受信したパケットを、そのモバイルノードの双方向セットアップを介して転送するためのルートを設定する必要があります。作成されたトンネルとルーティング状態は、セクション6.10.5で指定されているように、モバイルアクセスゲートウェイの転送動作を行う必要があります。
14. The mobile access gateway MUST also update the Binding Update List entry to reflect the accepted binding registration values. It MUST also advertise the mobile node's home network prefix(es) as the hosted on-link prefixes, by including them in the Router Advertisement messages that it sends on that access link.
14. また、モバイルアクセスゲートウェイは、バインディングアップデートリストエントリを更新して、受け入れられているバインディング登録値を反映する必要があります。また、モバイルノードのホームネットワークプレフィックス（ES）を、ホストされているオンリンクプレフィックスとして宣伝する必要があります。これは、そのアクセスリンクに送信するルーター広告メッセージにそれらを含めることで、それらを宣伝する必要があります。
15. If the received Proxy Binding Acknowledgement message has the address in the Link-local Address option set to a NON_ZERO value, the mobile access gateway SHOULD configure that link-local address on that point-to-point link and SHOULD NOT configure any other link-local address without performing a DAD operation [RFC4862]. This will avoid any potential link-local address collisions on that access link. However, if the link-local address generated by the local mobility anchor happens to be already in use by the mobile node on that link, the mobile access gateway MUST NOT use that address, but SHOULD configure a different link-local address. It SHOULD also upload this link-local address to the local mobility anchor by immediately sending a Proxy Binding Update message and by including this address in the Link-local Address option.
15. 受信したプロキシバインディング承認メッセージがlink-localアドレスオプションにnon_zero値に設定されたアドレスがある場合、モバイルアクセスゲートウェイは、そのポイントツーポイントリンクでそのリンクローカルアドレスを構成し、他のリンクを構成しないでください - お父さんの手術を実行せずにローカルアドレス[RFC4862]。これにより、そのアクセスリンクの潜在的なリンクローカルアドレスの衝突が回避されます。ただし、ローカルモビリティアンカーによって生成されたリンクローカルアドレスが、そのリンクのモバイルノードによって既に使用されている場合、モバイルアクセスゲートウェイはそのアドレスを使用してはなりませんが、別のリンクローカルアドレスを構成する必要があります。また、プロキシバインディングアップデートメッセージを直ちに送信し、このアドレスをLink-Localアドレスオプションに含めることにより、このリンクローカルアドレスをローカルモビリティアンカーにアップロードする必要があります。
1. For extending the lifetime of a currently registered mobile node (i.e., after a successful initial binding registration from the same mobile access gateway), the mobile access gateway can send a Proxy Binding Update message to the local mobility anchor with a new lifetime value. This re-registration message MUST be constructed with the same set of options as the initial Proxy Binding Update message, under the considerations specified in Section 6.9.1.1. However, the following exceptions apply.
1. 現在登録されているモバイルノードの寿命を延長するため（つまり、同じモバイルアクセスゲートウェイからの初期バインディング登録が成功した後）、モバイルアクセスゲートウェイは、新しい生涯値でローカルモビリティアンカーにプロキシバインディングアップデートメッセージを送信できます。この再登録メッセージは、セクション6.9.1.1で指定された考慮事項の下で、最初のプロキシバインディングアップデートメッセージと同じオプションセットで構築する必要があります。ただし、次の例外が適用されます。
2. There MUST be a Home Network Prefix option for each of the assigned home network prefixes assigned for that mobility session and with the prefix value in the option set to that respective prefix value.
2. そのモビリティセッションに割り当てられた割り当てられたホームネットワークプレフィックスごとに、およびそれぞれのプレフィックス値に設定されたオプションのプレフィックス値を使用して、ホームネットワークプレフィックスオプションが必要です。
3. The Handoff Indicator field in the Handoff Indicator option MUST be set to a value of 5 (Handoff state not changed - Re-Registration).
3. ハンドオフインジケーターオプションのハンドオフインジケータフィールドは、5の値に設定する必要があります（ハンドオフ状態は変更されていません - 再登録）。
1. If at any point the mobile access gateway detects that the mobile node has moved away from its access link, or if it decides to terminate the mobile node's mobility session, it SHOULD send a Proxy Binding Update message to the local mobility anchor with the lifetime value set to zero. This de-registration message MUST be constructed with the same set of options as the initial Proxy Binding Update message, under the considerations specified in Section 6.9.1.1. However, the following exceptions apply.
1. 任意の時点で、モバイルアクセスゲートウェイがモバイルノードがアクセスリンクから離れたことを検出する場合、またはモバイルノードのモビリティセッションを終了することを決定した場合、生涯価値のあるローカルモビリティアンカーにプロキシバインディングアップデートメッセージを送信する必要がありますゼロに設定します。この登録解除メッセージは、セクション6.9.1.1で指定された考慮事項の下で、最初のプロキシバインディングアップデートメッセージと同じオプションセットで構築する必要があります。ただし、次の例外が適用されます。
2. There MUST be a Home Network Prefix option for each of the assigned home network prefixes assigned for that mobility session and with the prefix value in the option set to the respective prefix value.
2. そのモビリティセッションに割り当てられた割り当てられたホームネットワークプレフィックスごとに、およびそれぞれのプレフィックス値に設定されたオプションのプレフィックス値を使用して、ホームネットワークプレフィックスオプションが必要です。
3. The Handoff Indicator field in the Handoff Indicator option MUST be set to a value of 4 (Handoff state unknown).
3. ハンドオフインジケーターオプションのハンドオフインジケータフィールドは、値4（ハンドオフ状態不明）に設定する必要があります。
Either upon receipt of a Proxy Binding Acknowledgement message from the local mobility anchor with the Status field set to 0 (Proxy Binding Update Accepted), or after INITIAL_BINDACK_TIMEOUT [RFC3775] timeout waiting for the reply, the mobile access gateway MUST do the following:
ローカルモビリティアンカーからのプロキシバインディングの確認メッセージを受信したとき、ステータスフィールドが0に設定されている（プロキシバインディングアップデートが受け入れられます）、またはinitial_bindack_timeout [rfc3775]タイムアウトを待っている場合、モバイルアクセスゲートウェイは次のことを行う必要があります。
1. It MUST remove the Binding Update List entry for the mobile node from its Binding Update List.
1. バインディングアップデートリストからモバイルノードのバインディングアップデートリストエントリを削除する必要があります。
2. It MUST remove the created routing state for tunneling the mobile node's traffic.
2. モバイルノードのトラフィックをトンネリングするために、作成されたルーティング状態を削除する必要があります。
3. If there is a dynamically created tunnel to the mobile node's local mobility anchor and if there are not other mobile nodes for which the tunnel is being used, then the tunnel MUST be deleted.
3. モバイルノードのローカルモビリティアンカーに動的に作成されたトンネルがあり、トンネルが使用されている他のモバイルノードがない場合は、トンネルを削除する必要があります。
4. It MUST tear down the point-to-point link shared with the mobile node. This action will force the mobile node to remove any IPv6 address configuration on the interface connected to this point-to-point link.
4. モバイルノードと共有されるポイントツーポイントリンクを取り壊す必要があります。このアクションにより、モバイルノードは、このポイントツーポイントリンクに接続されたインターフェイス上のIPv6アドレス構成を削除するように強制されます。
o The mobile access gateway, when sending the Proxy Binding Update message to the local mobility anchor, MUST construct the message as specified below.
o モバイルアクセスゲートウェイは、プロキシバインディングアップデートメッセージをローカルモビリティアンカーに送信するときに、以下に指定されているようにメッセージを構築する必要があります。
IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header
- BU /* P & A flags MUST be set to value 1 */
Mobility Options
- Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional)
Figure 12: Proxy Binding Update Message Format
図12：プロキシバインディング更新メッセージ形式
o The Source Address field in the IPv6 header of the message MUST be set to the global address configured on the egress interface of the mobile access gateway. When there is no Alternate Care-of Address option present in the request, this address will be considered as the Proxy-CoA for this Proxy Binding Update message. However, when there is an Alternate Care-of Address option present in the request, this address will be not be considered as the Proxy-CoA, but the address in the Alternate Care-of Address option will be considered as the Proxy-CoA.
o メッセージのIPv6ヘッダーのソースアドレスフィールドは、モバイルアクセスゲートウェイの出口インターフェイスで構成されたグローバルアドレスに設定する必要があります。リクエストに代替のケアオプションオプションが存在しない場合、このアドレスは、このプロキシバインディングアップデートメッセージのプロキシCOAと見なされます。ただし、リクエストに代替のケアオブアドレスオプションがある場合、このアドレスはプロキシCOAとは見なされませんが、代替ケアオブアドレスオプションのアドレスはプロキシCOAと見なされます。
o The Destination Address field in the IPv6 header of the message MUST be set to the local mobility anchor address.
o メッセージのIPv6ヘッダーの宛先アドレスフィールドは、ローカルモビリティアンカーアドレスに設定する必要があります。
o The Mobile Node Identifier option [RFC4283] MUST be present.
o モバイルノード識別子オプション[RFC4283]が存在する必要があります。
o At least one Home Network Prefix option MUST be present.
o 少なくとも1つのホームネットワークプレフィックスオプションが存在する必要があります。
o The Handoff Indicator option MUST be present.
o ハンドオフインジケータオプションが存在する必要があります。
o The Access Technology Type option MUST be present.
o アクセステクノロジータイプオプションが存在する必要があります。
o The Timestamp option MAY be present.
o タイムスタンプオプションが存在する場合があります。
o The Mobile Node Link-layer Identifier option MAY be present.
o モバイルノードリンク層識別子オプションが存在する場合があります。
o The Link-local Address option MAY be present.
o Link-Localアドレスオプションが存在する場合があります。
o If IPsec is used for protecting the signaling messages, the message MUST be protected, using the security association existing between the local mobility anchor and the mobile access gateway.
o IPSECが信号メッセージの保護に使用される場合、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間に存在するセキュリティアソシエーションを使用して、メッセージを保護する必要があります。
o Unlike in Mobile IPv6 [RFC3775], the Home Address option [RFC3775] MUST NOT be present in the IPv6 Destination Options extension header of the Proxy Binding Update message.
o モバイルIPv6 [RFC3775]とは異なり、ホームアドレスオプション[RFC3775]は、プロキシバインディングアップデートメッセージのIPv6宛先オプションエクステンションヘッダーに存在してはなりません。
A mobile node may send a Router Solicitation message on the access link shared with the mobile access gateway. The Router Solicitation message that the mobile node sends is as specified in [RFC4861]. The mobile access gateway, on receiving the Router Solicitation message or before sending a Router Advertisement message, MUST apply the following considerations.
モバイルノードは、モバイルアクセスゲートウェイと共有されるアクセスリンクにルーター勧誘メッセージを送信する場合があります。モバイルノードが送信するルーター勧誘メッセージは、[RFC4861]で指定されているとおりです。ルーターの勧誘メッセージを受信するとき、またはルーター広告メッセージを送信する前に、モバイルアクセスゲートウェイは、以下の考慮事項を適用する必要があります。
1. The mobile access gateway, on receiving the Router Solicitation message, SHOULD send a Router Advertisement message containing the mobile node's home network prefix(es) as the on-link prefix(es). However, before sending the Router Advertisement message containing the mobile node's home network prefix(es), it SHOULD complete the binding registration process with the mobile node's local mobility anchor.
1. ルーターの勧誘メッセージを受信すると、モバイルアクセスゲートウェイは、モバイルノードのホームネットワークプレフィックス（ES）を含むルーター広告メッセージをオンリンクプレフィックス（ES）として送信する必要があります。ただし、モバイルノードのホームネットワークプレフィックス（ES）を含むルーター広告メッセージを送信する前に、モバイルノードのローカルモビリティアンカーでバインディング登録プロセスを完了するはずです。
2. If the local mobility anchor rejects the Proxy Binding Update message, or, if the mobile access gateway failed to complete the binding registration process for whatever reason, the mobile access gateway MUST NOT advertise the mobile node's home network prefix(es) in the Router Advertisement messages that it sends on the access link. However, it MAY choose to advertise a local visited network prefix to enable the mobile node for regular IPv6 access.
2. ローカルモビリティアンカーがプロキシバインディングアップデートメッセージを拒否した場合、またはモバイルアクセスゲートウェイが何らかの理由でバインディング登録プロセスを完了できなかった場合、モバイルアクセスゲートウェイは、ルーター広告のモバイルノードのホームネットワークプレフィックス（ES）を宣伝してはなりません。アクセスリンクで送信するメッセージ。ただし、通常のIPv6アクセスのためにモバイルノードを有効にするために、ローカル訪問ネットワークプレフィックスを宣伝することを選択できます。
3. The mobile access gateway SHOULD add the MTU option, as specified in [RFC4861], to the Router Advertisement messages that it sends on the access link. This will ensure the mobile node on the link uses the advertised MTU value. The MTU value SHOULD reflect the tunnel MTU for the bi-directional tunnel between the mobile access gateway and the local mobility anchor. Considerations from Section 6.9.5 SHOULD be applied for determining the tunnel MTU value.
3. モバイルアクセスゲートウェイは、[RFC4861]で指定されているように、アクセスリンクに送信するルーター広告メッセージにMTUオプションを追加する必要があります。これにより、リンク上のモバイルノードが広告されたMTU値を使用します。MTU値は、モバイルアクセスゲートウェイとローカルモビリティアンカーの間の双方向トンネルのトンネルMTUを反映する必要があります。セクション6.9.5の考慮事項は、トンネルMTU値を決定するために適用する必要があります。
In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default-router for the mobile node on the access link. However, as the mobile node moves from one access link to another, the serving mobile access gateway on those respective links will send the Router Advertisement messages. If these Router Advertisements are sent using a different link-local address or a different link-layer address, the mobile node will always detect a new default-router after every handoff. For solving this problem, this specification requires all the mobile access gateways in the Proxy Mobile IPv6 domain to use the same link-local and link-layer address on any of the access links wherever the mobile node attaches. These addresses can be fixed addresses across the entire Proxy Mobile IPv6 domain, and all the mobile access gateways can use these globally fixed address on any of the point-to-point links. The configuration variables FixedMAGLinkLocalAddressOnAllAccessLinks and FixedMAGLinkLayerAddressOnAllAccessLinks SHOULD be used for this purpose. Additionally, this specification allows the local mobility anchor to generate the link-local address and provide it to the mobile access gateway as part of the signaling messages.
プロキシモバイルIPv6では、モバイルアクセスゲートウェイは、アクセスリンク上のモバイルノードのIPv6デフォルトルーターです。ただし、モバイルノードが1つのアクセスリンクから別のアクセスリンクに移動すると、それらのリンクのサービングモバイルアクセスゲートウェイがルーター広告メッセージを送信します。これらのルーター広告が別のリンクローカルアドレスまたは異なるリンク層アドレスを使用して送信される場合、モバイルノードは、ハンドオフごとに常に新しいデフォルトルーターを検出します。この問題を解決するには、この仕様には、プロキシモバイルIPv6ドメイン内のすべてのモバイルアクセスゲートウェイが必要であり、モバイルノードが添付されている場所にアクセスリンクのいずれかで同じリンクローカルとリンクレイヤーアドレスを使用します。これらのアドレスは、プロキシモバイルIPv6ドメイン全体にわたって固定アドレスを固定できます。すべてのモバイルアクセスゲートウェイは、ポイントツーポイントリンクのいずれかでこれらのグローバルに固定されたアドレスを使用できます。構成変数固定MAGLINKLINKLOCALADDRESSONALACCESSLINKSおよびMAGLINKLINKLINKLINKLINKLAYERADDRESONALCCESSLINKSをこの目的に使用する必要があります。さらに、この仕様により、ローカルモビリティアンカーがリンクローカルアドレスを生成し、信号メッセージの一部としてモバイルアクセスゲートウェイに提供できます。
However, both of these approaches (a link-local address generated by the local mobility anchor or when using a globally fixed link-local address) have implications on the deployment of SEcure Neighbor Discovery (SEND) [RFC3971]. In SEND, routers have certificates and public key pairs, and their Router Advertisements are signed with the private keys of these key pairs. When a number of different routers use the same addresses, the routers either all have to be able to construct these signatures for the same key pair, or the used key pair and the router's cryptographic identity must change after a movement. Both approaches are problematic. Sharing of private key information across multiple nodes in a PMIP6 domain is poor design from a security perspective. And changing even the cryptographic identity of the router goes against the general idea of the Proxy Mobile IPv6 being as invisible to the hosts as possible.
ただし、これらのアプローチ（ローカルモビリティアンカーによって生成されるリンクローカルアドレスまたはグローバルに固定されたリンクローカルアドレスを使用する場合）は、安全な近隣発見（SEND）[RFC3971]の展開に影響を及ぼします。送信では、ルーターには証明書と公開キーのペアがあり、それらのルーター広告はこれらのキーペアのプライベートキーで署名されています。多数の異なるルーターが同じアドレスを使用する場合、ルーターはすべて同じキーペアまたは使用されているキーペアのこれらの署名を作成できる必要があります。どちらのアプローチにも問題があります。PMIP6ドメイン内の複数のノードにわたる秘密のキー情報の共有は、セキュリティの観点からの設計が不十分です。また、ルーターの暗号化のアイデンティティでさえも、プロキシモバイルIPv6がホストには可能な限り見えないという一般的な考え方に反します。
There is, however, ongoing work in the IETF to revise the SEND specifications. It is suggested that these revisions also address the above problem. Other revisions are needed to deal with other problematic cases (such as Neighbor Discovery proxies) before wide-spread deployment of SEND.
ただし、送信仕様を修正するために、IETFで進行中の作業があります。これらの修正は上記の問題にも対処することが示唆されています。Sendの広範な展開の前に、他の問題のあるケース（近隣発見プロキシなど）に対処するには、その他の改訂が必要です。
The mobile access gateway is responsible for retransmissions and rate limiting the Proxy Binding Update messages that it sends to the local mobility anchor. The Retransmission and the Rate Limiting rules are as specified in [RFC3775]. However, the following considerations MUST be applied.
モバイルアクセスゲートウェイは、再送信とレートを担当し、ローカルモビリティアンカーに送信するプロキシバインディングアップデートメッセージを制限します。再送信とレート制限ルールは、[RFC3775]で指定されているとおりです。ただし、次の考慮事項を適用する必要があります。
1. When the mobile access gateway sends a Proxy Binding Update message, it should use the constant, INITIAL_BINDACK_TIMEOUT [RFC3775], for configuring the retransmission timer, as specified in Section 11.8 [RFC3775]. However, the mobile access gateway is not required to use a longer retransmission interval of InitialBindackTimeoutFirstReg, as specified in [RFC3775], for the initial Proxy Binding Update message.
1. モバイルアクセスゲートウェイがプロキシバインディングアップデートメッセージを送信する場合、セクション11.8 [RFC3775]で指定されているように、再送信タイマーを構成するために、定数initial_bindack_timeout [rfc3775]を使用する必要があります。ただし、[RFC3775]で指定されているように、初期プロキシバインディングアップデートメッセージには、Mobile Access Gatewayは、[RFC3775]で指定されているように、initialbindacktimeoutfirstregのより長い再送信間隔を使用する必要はありません。
2. If the mobile access gateway fails to receive a valid matching response for a registration or re-registration message within the retransmission interval, it SHOULD retransmit the message until a response is received. However, the mobile access gateway MUST ensure the mobile node is still attached to the connected link before retransmitting the message.
2. モバイルアクセスゲートウェイが再送信間隔内で登録または再登録メッセージに対して有効なマッチング応答を受信できない場合、応答が受信されるまでメッセージを再送信する必要があります。ただし、モバイルアクセスゲートウェイは、メッセージを再送信する前に、モバイルノードが接続されたリンクにまだ接続されていることを確認する必要があります。
3. As specified in Section 11.8 of [RFC3775], the mobile access gateway MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT [RFC3775]. The mobile access gateway MAY continue to send these messages at this slower rate indefinitely.
3. [RFC3775]のセクション11.8で指定されているように、モバイルアクセスゲートウェイは、ノードが応答を受信するか、タイムアウト期間が値MAX_BINDACK_TIMEOUT [RFC3775に到達するまで、各再送信時にタイムアウト期間を2倍にする指数バックオフプロセスを使用する必要があります。]。モバイルアクセスゲートウェイは、この遅いレートで無期限にこれらのメッセージを送信し続ける場合があります。
4. If the Timestamp-based scheme is in use, the retransmitted Proxy Binding Update messages MUST use the latest timestamp. If the Sequence Number scheme is in use, the retransmitted Proxy Binding Update messages MUST use a Sequence Number value greater than that was used for the previous transmission of this Proxy Binding Update message, just as specified in [RFC3775].
4. タイムスタンプベースのスキームが使用されている場合、再送信されたプロキシバインディング更新メッセージは最新のタイムスタンプを使用する必要があります。シーケンス番号スキームが使用されている場合、再送信されたプロキシバインディング更新メッセージは、[RFC3775]で指定されているように、このプロキシバインディング更新メッセージの以前の送信に使用されたシーケンス番号値を使用する必要があります。
It is important that mobile node, mobile access gateway, and local mobility anchor have a correct understanding of MTUs. When the mobile node uses the correct MTU, it can send packets that do not exceed the local link MTU and do not cause the tunneled packets from the mobile access gateway to be fragmented. This is important both from the perspective of efficiency, as well as preventing hard-to-diagnose MTU problems. The following are some of the considerations related to Path MTU discovery.
モバイルノード、モバイルアクセスゲートウェイ、ローカルモビリティアンカーがMTUを正しく理解することが重要です。モバイルノードが正しいMTUを使用すると、ローカルリンクMTUを超えないパケットを送信でき、モバイルアクセスゲートウェイのトンネルパケットが断片化されません。これは、効率性の観点からも重要であり、診断が困難なMTUの問題を防ぐこともできます。以下は、Path MTU発見に関連する考慮事項の一部です。
o The local mobility anchor and mobile access gateway MAY use the Path MTU discovery mechanisms, as specified in [RFC1981] or in [RFC4821], for determining the Path MTU (PMTU) for the (LMA-MAG) paths. The specific discovery mechanism to be used in a given deployment can be configurable.
o ローカルモビリティアンカーおよびモバイルアクセスゲートウェイは、[RFC1981]または[RFC4821]で指定されているパスMTU発見メカニズムを使用して、（LMA-Mag）パスのパスMTU（PMTU）を決定することができます。特定の展開で使用される特定の発見メカニズムは、構成可能です。
o The mobility entities MUST implement and SHOULD support ICMP-based Path MTU discovery mechanism, as specified in [RFC1981]. However, this mechanism may not work correctly if the Proxy Mobile IPv6 network does not deliver or process ICMP Packet Too Big messages.
o モビリティエンティティは、[RFC1981]で指定されているように、ICMPベースのPATH MTU発見メカニズムを実装する必要があり、サポートする必要があります。ただし、プロキシモバイルIPv6ネットワークがICMPパケットを配信または処理しない場合、このメカニズムは正しく機能しない場合があります。
o The mobility entities MAY implement Packetization Layer Path MTU discovery mechanisms, as specified in [RFC4821], and use any application traffic as a payload for the PMTU discovery. Neither the Proxy Mobile IPv6 protocol or the tunnel between the mobile access gateway and local mobility agent can easily be used for this purpose. However, implementations SHOULD support at least the use of an explicit ICMP Echo Request/Response for this purpose.
o モビリティエンティティは、[RFC4821]で指定されているように、パケット化レイヤーパスMTU発見メカニズムを実装し、PMTU発見のペイロードとしてアプリケーショントラフィックを使用する場合があります。モバイルアクセスゲートウェイとローカルモビリティエージェントの間のプロキシモバイルIPv6プロトコルまたはトンネルも、この目的に簡単に使用できません。ただし、実装は、少なくともこの目的のために明示的なICMPエコー要求/応答の使用をサポートする必要があります。
o The mobility entities MAY choose to perform Path MTU discovery for all the (LMA-MAG) paths at the boot time and may repeat this operation periodically to ensure the Path MTU values have not changed for those paths. If the dynamic PMTU discovery mechanisms fail to determine the Path MTU, an administratively configured default value MUST be used.
o モビリティエンティティは、ブート時間にすべての（LMA-Mag）パスに対してPATH MTUディスカバリーを実行することを選択し、これらのパスのパスMTU値が変更されていないことを確認するために、この操作を定期的に繰り返すことができます。動的なPMTU発見メカニズムがパスMTUの決定に失敗した場合、管理上構成されたデフォルト値を使用する必要があります。
o The IPv6 tunnel MTU for an established tunnel between the local mobility anchor and the mobile access gateway MUST be computed based on the determined Path MTU value for that specific path and the computation should be as specified in Section 6.7 of [RFC2473].
o ローカルモビリティアンカーとモバイルアクセスゲートウェイの間の確立されたトンネルのIPv6トンネルMTUは、その特定のパスの決定されたパスMTU値に基づいて計算する必要があり、計算は[RFC2473]のセクション6.7で指定されているようにする必要があります。
o The mobile access gateway SHOULD use the determined tunnel Path MTU value (for the tunnel established with the mobile node's local mobility anchor) as the MTU value in the MTU option that it sends in the Router Advertisements on the access link shared with the mobile node. But, if the MTU value of the access link shared with the mobile node is lower than the determined Path MTU value, then the MTU of the access link MUST be used in the MTU option.
o モバイルアクセスゲートウェイは、モバイルノードと共有されるアクセスリンクのルーター広告に送信するMTUオプションのMTU値として、決定されたトンネルパスMTU値（モバイルノードのローカルモビリティアンカーで確立されたトンネル用）を使用する必要があります。ただし、モバイルノードと共有されるアクセスリンクのMTU値が決定されたパスMTU値よりも低い場合、MTUオプションでアクセスリンクのMTUを使用する必要があります。
o If the mobile access gateway detects a change in the MTU value for any of the paths (LMA-MAG) and at any point of time, the corresponding tunnel MTU value MUST be updated to reflect the change in Path MTU value. The adjusted tunnel MTU value (lower of the Path MTU and the access link MTU) SHOULD be notified to the impacted mobile nodes by sending additional Router Advertisement messages. Additionally, the adjusted tunnel MTU value MUST be used in all the subsequent Router Advertisement messages as well.
o モバイルアクセスゲートウェイが、パス（LMA-Mag）のいずれかのMTU値の変更を検出し、いつでも任意の時点で、PATH MTU値の変化を反映するために対応するトンネルMTU値を更新する必要があります。調整されたトンネルMTU値（PATH MTUの下部とアクセスリンクMTUの低い）は、追加のルーター広告メッセージを送信して、影響を受けたモバイルノードに通知する必要があります。さらに、調整されたトンネルMTU値も、後続のすべてのルーター広告メッセージで使用する必要があります。
This section describes how the mobile access gateway handles the traffic to/from the mobile node that is attached to one of its access interfaces.
このセクションでは、モバイルアクセスゲートウェイが、アクセスインターフェイスの1つに接続されているモバイルノードとの間のトラフィックをどのように処理するかについて説明します。
Proxy-CoA LMAA
| |
+--+ +---+ +---+ +--+
|MN|----------|MAG|======================|LMA|----------|CN|
+--+ +---+ +---+ +--+
IPv6 Tunnel
Figure 13: Proxy Mobile IPv6 Tunnel
図13：プロキシモバイルIPv6トンネル
As per this specification, the transport network between the local mobility anchor and the mobile access gateway is an IPv6 network. The document [IPV4-PMIP6] specifies the required extensions for negotiating IPv4 transport and the corresponding encapsulation mode.
この仕様に従って、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間のトランスポートネットワークはIPv6ネットワークです。ドキュメント[IPv4-PMIP6]は、IPv4トランスポートと対応するカプセル化モードを交渉するために必要な拡張機能を指定します。
An IPv6 address that a mobile node uses from its home network prefix(es) is topologically anchored at the local mobility anchor. For a mobile node to use this address from an access network attached to a mobile access gateway, proper tunneling techniques have to be in place. Tunneling hides the network topology and allows the mobile node's IPv6 datagram to be encapsulated as a payload of another IPv6 packet and to be routed between the local mobility anchor and the mobile access gateway. The Mobile IPv6 base specification [RFC3775] defines the use of IPv6-over-IPv6 tunneling [RFC2473] between the home agent and the mobile node, and this specification extends the use of the same tunneling mechanism for use between the local mobility anchor and the mobile access gateway.
モバイルノードがホームネットワークプレフィックス（ES）から使用するIPv6アドレスは、ローカルモビリティアンカーにトポロジカルに固定されています。モバイルノードがモバイルアクセスゲートウェイに接続されているアクセスネットワークからこのアドレスを使用するには、適切なトンネリング技術を配置する必要があります。トンネリングはネットワークトポロジを隠し、モバイルノードのIPv6データグラムを別のIPv6パケットのペイロードとしてカプセル化し、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間でルーティングできるようにします。モバイルIPv6ベース仕様[RFC3775]は、ホームエージェントとモバイルノードの間でIPv6-Over-IPV6トンネル[RFC2473]の使用を定義し、この仕様はローカルモビリティアンカーとローカルモビリティアンカーとの間で使用するための同じトンネルメカニズムの使用を拡張します。モバイルアクセスゲートウェイ。
On most operating systems, a tunnel is implemented as a virtual point-to-point interface. The source and the destination address of the two endpoints of this virtual interface along with the encapsulation mode are specified for this virtual interface. Any packet that is routed over this interface gets encapsulated with the outer header as specified for that point-to-point tunnel interface.
ほとんどのオペレーティングシステムでは、トンネルが仮想ポイントツーポイントインターフェイスとして実装されています。この仮想インターフェイスとともに、この仮想インターフェイスの2つのエンドポイントのソースと宛先アドレスは、この仮想インターフェイスに指定されています。このインターフェイス上にルーティングされるパケットは、そのポイントツーポイントトンネルインターフェイスに指定されているように、外側のヘッダーでカプセル化されます。
For creating a point-to-point tunnel to any local mobility anchor, the mobile access gateway may implement a tunnel interface with the Source Address field set to a global address on its egress interface (Proxy-CoA) and the destination address field set to the global address of the local mobility anchor (LMAA).
ローカルモビリティアンカーにポイントツーポイントトンネルを作成するために、モバイルアクセスゲートウェイは、Egressインターフェイス（Proxy-Coa）のグローバルアドレスに設定されたソースアドレスフィールドと、宛先アドレスフィールドに設定されたトンネルインターフェイスを実装できます。ローカルモビリティアンカー（LMAA）のグローバルアドレス。
The following is the supported packet encapsulation mode that can be used by the mobile access gateway and the local mobility anchor for routing mobile node's IPv6 datagrams.
以下は、モバイルアクセスゲートウェイとモバイルノードのIPv6データグラムをルーティングするためのローカルモビリティアンカーで使用できるサポートされているパケットカプセル化モードです。
o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC2473].
o IPv6-in-IPV6-IPv6パケット[RFC2473]にカプセル化されたIPv6データグラム。
The companion document [IPV4-PMIP6] specifies other encapsulation modes for supporting IPv4 transport.
コンパニオンドキュメント[IPv4-PMIP6]は、IPv4トランスポートをサポートするための他のカプセル化モードを指定します。
o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The details on how this mode is negotiated are specified in [IPV4-PMIP6].
o IPv6-in-ipv4-IPv4パケットでのIPv6データグラムのカプセル化。このモードのネゴシエーションの詳細は、[IPv4-PMIP6]で指定されています。
o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP packet. This mode is specified in [IPV4-PMIP6].
o IPv6-in-ipv4-udp-ipv4 udpパケットでのIPv6データグラムのカプセル化。このモードは[IPv4-PMIP6]で指定されています。
o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP packet with a TLV header. This mode is specified in [IPV4-PMIP6].
o IPv6-in-ipv4-udp-tlv-ipv6 datagram TLVヘッダーを備えたIPv4 UDPパケットでのカプセル化。このモードは[IPv4-PMIP6]で指定されています。
If there is data traffic between a visiting mobile node and a correspondent node that is locally attached to an access link connected to the mobile access gateway, the mobile access gateway MAY optimize on the delivery efforts by locally routing the packets and by not reverse tunneling them to the mobile node's local mobility anchor. The flag EnableMAGLocalRouting MAY be used for controlling this behavior. However, in some systems, this may have an implication on the mobile node's accounting and policy enforcement as the local mobility anchor is not in the path for that traffic and it will not be able to apply any traffic policies or do any accounting for those flows.
モバイルアクセスゲートウェイに接続されたアクセスリンクにローカルに接続されているアクセスリンクに局所的に接続されている対応者ノードとの間にデータトラフィックがある場合、モバイルアクセスゲートウェイは、パケットをローカルにルーティングし、それらを逆トンネルにしないことにより、配信の取り組みを最適化する場合があります。モバイルノードのローカルモビリティアンカーに。この動作を制御するために、Flag EnablemaglocalRoutingを使用できます。ただし、一部のシステムでは、ローカルモビリティのアンカーがそのトラフィックのパスになく、トラフィックポリシーを適用したり、それらのフローの会計を行うことができないため、これはモバイルノードの会計とポリシー施行に影響を与える可能性があります。。
This decision of path optimization SHOULD be based on the policy configured on the mobile access gateway, but enforced by the mobile node's local mobility anchor. The specific details on how this is achieved are beyond of the scope of this document.
パス最適化のこの決定は、モバイルアクセスゲートウェイで構成されたポリシーに基づいている必要がありますが、モバイルノードのローカルモビリティアンカーによって実施されます。これがどのように達成されるかに関する具体的な詳細は、このドキュメントの範囲を超えています。
All the considerations mentioned in Section 5.6.1 for the tunnel management on the local mobility anchor apply for the mobile access gateway as well.
ローカルモビリティアンカーのトンネル管理に関するセクション5.6.1で言及されているすべての考慮事項も、モバイルアクセスゲートウェイに適用されます。
Forwarding Packets Sent to the Mobile Node's Home Network:
モバイルノードのホームネットワークに送信されるパケットを転送します。
o On receiving a packet from the bi-directional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST use the destination address of the inner packet for forwarding it on the interface where the destination network prefix is hosted. The mobile access gateway MUST remove the outer header before forwarding the packet. Considerations from [RFC2473] MUST be applied for IPv6 decapsulation. If the mobile access gateway cannot find the connected interface for that destination address, it MUST silently drop the packet. For reporting an error in such a scenario, in the form of an ICMP control message, the considerations from [RFC2473] MUST be applied.
o モバイルノードのローカルモビリティアンカーで確立された双方向トンネルからパケットを受信すると、モバイルアクセスゲートウェイは、インナーパケットの宛先アドレスを使用して、宛先ネットワークのプレフィックスがホストされているインターフェイスに転送する必要があります。モバイルアクセスゲートウェイは、パケットを転送する前に外側のヘッダーを削除する必要があります。[RFC2473]からの考慮事項は、IPv6脱カプセル化に適用する必要があります。モバイルアクセスゲートウェイがその宛先アドレスの接続されたインターフェイスを見つけることができない場合、パケットを静かにドロップする必要があります。ICMP制御メッセージの形で、このようなシナリオのエラーを報告するには、[RFC2473]からの考慮事項を適用する必要があります。
o On receiving a packet from a correspondent node that is connected to the mobile access gateway as a regular IPv6 host (see Section 6.14) destined to a mobile node that is also locally attached, the mobile access gateway MUST check the flag EnableMAGLocalRouting to determine if the packet can be delivered directly to the mobile node. If the mobile access gateway is not allowed to route the packet directly, it MUST route the packet towards the local mobility anchor where the destination address is topologically anchored, else it can route the packet directly to the mobile node.
o モバイルアクセスゲートウェイに接続されている特派員ノードから、通常のIPv6ホストとしてモバイルアクセスゲートウェイに接続されている場合（セクション6.14を参照）、モバイルアクセスゲートウェイは、ローカルに添付されているモバイルノードに向けられています。パケットはモバイルノードに直接配信できます。モバイルアクセスゲートウェイがパケットを直接ルーティングできない場合は、宛先アドレスがトポロジカルに固定されているローカルモビリティアンカーにパケットをルーティングする必要があります。それ以外の場合は、パケットをモバイルノードに直接ルーティングできます。
Forwarding Packets Sent by the Mobile Node:
モバイルノードから送信された転送パケット：
o On receiving a packet from a mobile node connected to its access link, the mobile access gateway MUST ensure that there is an established binding for that mobile node with its local mobility anchor before forwarding the packet directly to the destination or before tunneling the packet to the mobile node's local mobility anchor.
o アクセスリンクに接続されたモバイルノードからパケットを受信すると、モバイルアクセスゲートウェイは、パケットを宛先に直接転送する前、またはパケットをトンネリングする前に、ローカルモビリティアンカーを使用してそのモバイルノードに確立されたバインディングがあることを確認する必要があります。モバイルノードのローカルモビリティアンカー。
o On receiving a packet from a mobile node connected to its access link for a destination that is locally connected, the mobile access gateway MUST check the flag EnableMAGLocalRouting, to ensure the mobile access gateway is allowed to route the packet directly to the destination. If the mobile access gateway is not allowed to route the packet directly, it MUST route the packet through the bi-directional tunnel established between itself and the mobile node's local mobility anchor. Otherwise, it MUST route the packet directly to the destination.
o 局所的に接続されている宛先のアクセスリンクに接続されたモバイルノードからパケットを受信すると、モバイルアクセスゲートウェイは、モバイルアクセスゲートウェイがパケットを直接宛先に直接ルーティングできるように、フラグのイネーブロカルルーティングを確認する必要があります。モバイルアクセスゲートウェイがパケットを直接ルーティングできない場合、それ自体とモバイルノードのローカルモビリティアンカーの間に確立された双方向トンネルにパケットをルーティングする必要があります。それ以外の場合は、パケットを宛先に直接ルーティングする必要があります。
o On receiving a packet from a mobile node connected to its access link, to a destination that is not directly connected, the packet MUST be forwarded to the local mobility anchor through the bi-directional tunnel established between itself and the mobile node's local mobility anchor. However, the packets that are sent with the link-local source address MUST NOT be forwarded.
o アクセスリンクに接続されたモバイルノードから直接接続されていない宛先にパケットを受信すると、パケットは、それ自体とモバイルノードのローカルモビリティアンカーの間に確立された双方向トンネルを介してローカルモビリティアンカーに転送する必要があります。ただし、Link-Local Sourceアドレスで送信されるパケットを転送してはなりません。
o The format of the tunneled packet is shown below. Considerations from [RFC2473] MUST be applied for IPv6 encapsulation. However, when using IPv4 transport, the format of the tunneled packet is as described in [IPV4-PMIP6].
o トンネルパケットの形式を以下に示します。[RFC2473]からの考慮事項は、IPv6カプセル化に適用する必要があります。ただし、IPv4トランスポートを使用する場合、トンネルパケットの形式は[IPv4-PMIP6]に記載されているとおりです。
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 14: Tunneled Packet from MAG to LMA
図14：MAGからLMAへのトンネルパケット
o The format of the tunneled packet is shown below, when payload protection using IPsec is enabled for the mobile node's data traffic. However, when using IPv4 transport, the format of the packet is as described in [IPV4-PMIP6].
o トンネルパケットの形式は、モバイルノードのデータトラフィックに対してIPSECを使用したペイロード保護が有効になっている場合、以下に示します。ただし、IPv4トランスポートを使用する場合、パケットの形式は[IPv4-PMIP6]に記載されているとおりです。
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
ESP Header in tunnel mode /* ESP Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 15: Tunneled Packet from MAG to LMA with Payload Protection
図15：ペイロード保護を備えたMAGからLMAへのトンネルパケット
This section explains how Stateful Address Configuration using DHCP support can be enabled in a Proxy Mobile IPv6 domain. It also identifies the required configuration in DHCP and mobility infrastructures for supporting this address configuration mode and also identifies the protocol interactions between these two systems.
このセクションでは、プロキシモバイルIPv6ドメインでDHCPサポートを使用した状態のアドレス構成をどのように有効にするかについて説明します。また、このアドレス構成モードをサポートするためにDHCPおよびモビリティインフラストラクチャの必要な構成を識別し、これら2つのシステム間のプロトコルの相互作用も識別します。
o For supporting Stateful Address Configuration using DHCP, the DHCP relay agent [RFC3315] service MUST be supported on all the mobile access gateways in the Proxy Mobile IPv6 domain. Further, as specified in Section 20 of [RFC3315], the DHCP relay agent should be configured to use a list of destination addresses, which MAY include unicast addresses, the All_DHCP_Servers multicast address, or other addresses as required in a given deployment.
o DHCPを使用したステートフルアドレス構成をサポートするには、プロキシモバイルIPv6ドメインのすべてのモバイルアクセスゲートウェイでDHCPリレーエージェント[RFC3315]サービスをサポートする必要があります。さらに、[RFC3315]のセクション20で指定されているように、DHCPリレーエージェントは、ユニキャストアドレス、ALL_DHCP_SERVERSマルチキャストアドレス、または特定の展開で必要なその他のアドレスを含む宛先アドレスのリストを使用するように構成する必要があります。
o The DHCP infrastructure needs to be configured to assign addresses from each of the prefixes assigned to a link in that Proxy Mobile IPv6 domain. The DHCP relay agent indicates the link to which the mobile node is attached by including an IPv6 address from any of the prefixes assigned to that link in the link-address field of the Relay Forward message. Therefore, for each link in the Mobile IPv6 domain, the DHCP infrastructure will:
o DHCPインフラストラクチャは、そのプロキシモバイルIPv6ドメインのリンクに割り当てられた各プレフィックスからアドレスを割り当てるように構成する必要があります。DHCPリレーエージェントは、リレーフォワードメッセージのリンクアドレスフィールドにそのリンクに割り当てられたプレフィックスのいずれかからIPv6アドレスを含めることにより、モバイルノードが添付されるリンクを示します。したがって、モバイルIPv6ドメインの各リンクについて、DHCPインフラストラクチャは次のとおりです。
* be configured with a list of all of the prefixes associated with that link;
* そのリンクに関連付けられたすべてのプレフィックスのリストで構成されています。
* identify the link to which the mobile node is attached by looking up the prefix for the link-address field in the Relay Forward message in the list of prefixes associated with each link;
* 各リンクに関連付けられたプレフィックスのリストにあるリレーフォワードメッセージのリンクアドレスフィールドのプレフィックスを調べて、モバイルノードが添付されるリンクを識別します。
* assign to the host an address from each prefix associated with the link to which the mobile node is attached.
* モバイルノードが添付されているリンクに関連付けられた各プレフィックスのアドレスをホストに割り当てます。
This DHCP infrastructure configuration requirement is identical to other IPv6 networks; other than receiving DHCP messages from a mobile node through different relay agents (MAGs) over time, the DHCP infrastructure will be unaware of the mobile node's capability with respect to mobility support.
このDHCPインフラストラクチャ構成要件は、他のIPv6ネットワークと同じです。時間の経過とともに、異なるリレーエージェント（MAGS）を介してモバイルノードからDHCPメッセージを受信する以外に、DHCPインフラストラクチャは、モビリティサポートに関するモバイルノードの機能を認識しません。
o The local mobility anchor needs to have the same awareness with respect to the links along with the associated prefixes in a Proxy Mobile IPv6 domain. When a local mobility anchor assigns prefix(es) to a mobile node, it MUST assign all the prefixes associated with a given link and all of those assigned prefixes will remain as the home network prefixes for that mobile node throughout the life of that mobility session. The serving mobile access gateway that hosts these prefixes is physically connected to that link and can function as the DHCP relay agent. This common understanding between DHCP and mobility entities about all the links in the domain along with the associated prefixes provides the required coordination for allowing mobility entities to perform prefix assignment dynamically to a mobile node and still allow the DHCP infrastructure to perform address assignment for that mobile node only from its home network prefixes.
o ローカルモビリティアンカーは、プロキシモバイルIPv6ドメインの関連するプレフィックスとともに、リンクに関して同じ意識を持つ必要があります。ローカルモビリティアンカーがプレフィックスをモバイルノードに割り当てる場合、特定のリンクに関連付けられたすべてのプレフィックスを割り当てる必要があり、それらの割り当てられたプレフィックスはすべて、そのモビリティセッションの寿命を通じてそのモバイルノードのホームネットワークプレフィックスとして残ります。これらのプレフィックスをホストするサービングモバイルアクセスゲートウェイは、そのリンクに物理的に接続されており、DHCPリレーエージェントとして機能できます。DHCPとモビリティエンティティの間のこの共通の理解と、関連するプレフィックスとともにドメイン内のすべてのリンクに関するエンティティは、モビリティエンティティがモバイルノードに動的にプレフィックス割り当てを実行し、DHCPインフラストラクチャがそのモバイルのアドレス割り当てを実行できるようにするために必要な調整を提供しますホームネットワークのプレフィックスからのみノード。
o When a mobile node sends a DHCP request message, the DHCP relay agent function on the mobile access gateway will set the link-address field in the DHCP message to an address in the mobile node's home network prefix (any one of the mobile node's home network prefixes assigned to that mobile node's attached interface). The mobile access gateway can generate an autoconfiguration address from one of the mobile node's home network prefixes [RFC4862] and can use this address link-address option, so as to provide a hint to the DHCP Server for the link identification. The DHCP server, on receiving the request from the mobile node, will allocate addresses from all the prefixes associated with that link (identified using the link-address field of the request).
o モバイルノードがDHCPリクエストメッセージを送信すると、モバイルアクセスゲートウェイのDHCPリレーエージェント関数は、DHCPメッセージのリンクアドレスフィールドをモバイルノードのホームネットワークプレフィックス（モバイルノードのホームネットワークのいずれか）のアドレスに設定しますそのモバイルノードに添付されたインターフェイスに割り当てられたプレフィックス）。モバイルアクセスゲートウェイは、モバイルノードのホームネットワークプレフィックス[RFC4862]のいずれかからオートコンチュレーションアドレスを生成し、このアドレスリンクアドレスオプションを使用して、リンク識別用のDHCPサーバーにヒントを提供することができます。DHCPサーバーは、モバイルノードからリクエストを受信すると、そのリンクに関連付けられたすべてのプレフィックス（リクエストのリンクアドレスフィールドを使用して識別）からアドレスを割り当てます。
o Once the mobile node obtains address(es), moves to a different link, and sends a DHCP request (at any time) for extending the DHCP lease, the DHCP relay agent on the new link will set the link-address field in the DHCP Relay Forward message to one of the mobile node's home network prefixes. The DHCP server will identify the client from the Client-DUID option and will identify the link from the link-address option present in the request and will allocate the same address(es) as before.
o モバイルノードがアドレスを取得し、別のリンクに移動し、DHCPリースを延長するために（いつでも）DHCPリクエストを送信すると、新しいリンクのDHCPリレーエージェントがDHCPにリンクアドレスフィールドを設定しますモバイルノードのホームネットワークプレフィックスの1つにフォワードメッセージを中継します。DHCPサーバーは、クライアントDUIDオプションからクライアントを識別し、リクエストに存在するリンクアドレスオプションからリンクを識別し、以前と同じアドレスを割り当てます。
o For correct operation of the model of network-based mobility management in which the host does not participate in any mobility management, the mobile node MUST always be assigned an identical set of IPv6 addresses regardless of the access link to which the mobile node is attached. For example, the mobile access gateways in the Proxy Mobile IPv6 domain should be configured so that DHCP messages from a mobile node will always be handled by the same DHCP server or by a server from the same group of coordinated DHCP servers serving that domain. DHCP-based address configuration is not recommended for deployments in which the local mobility anchor and the mobile access gateway are located in different administrative domains.
o ホストがモビリティ管理に参加しないネットワークベースのモビリティ管理のモデルを正しく操作するには、モバイルノードが添付されているアクセスリンクに関係なく、モバイルノードに常にIPv6アドレスの同一のセットを割り当てる必要があります。たとえば、プロキシモバイルIPv6ドメインのモバイルアクセスゲートウェイは、モバイルノードからのDHCPメッセージが常に同じDHCPサーバーによって、またはそのドメインを提供する同じ調整されたDHCPサーバーのグループからのサーバーから常に処理されるように構成する必要があります。DHCPベースのアドレス構成は、ローカルモビリティアンカーとモバイルアクセスゲートウェイが異なる管理ドメインにある展開には推奨されません。
If the mobile node's home network prefix(es) gets renumbered or becomes invalid during the middle of a mobility session, the mobile access gateway MUST withdraw the prefix(es) by sending a Router Advertisement message on the access link with zero prefix lifetime for the prefix(es) that is being renumbered. Also, the local mobility anchor and the mobile access gateway MUST delete the created routing state for the renumbered prefix(es). However, the specific details on how the local mobility anchor notifies the mobile access gateway about the mobile node's home network prefix(es) renumbering are outside the scope of this document.
モバイルノードのホームネットワークプレフィックス（ES）がモビリティセッションの途中で変更されるか、無効になった場合、モバイルアクセスゲートウェイは、ゼロプレフィックスライフタイムのアクセスリンクにルーター広告メッセージを送信して、プレフィックス（ES）を引き出しなければなりません。名前を変更されているプレフィックス（es）。また、ローカルモビリティアンカーとモバイルアクセスゲートウェイは、変更されたプレフィックス（ES）の作成されたルーティング状態を削除する必要があります。ただし、ローカルモビリティアンカーがモバイルノードのホームネットワークプレフィックス（ES）の変更に関するモバイルアクセスゲートウェイにどのように通知されるかについての具体的な詳細は、このドキュメントの範囲外です。
Before sending a Proxy Binding Update message to the local mobility anchor for extending the lifetime of a currently existing binding of a mobile node, the mobile access gateway MUST make sure the mobile node is still attached to the connected link by using some reliable method. If the mobile access gateway cannot predictably detect the presence of the mobile node on the connected link, it MUST NOT attempt to extend the registration lifetime of the mobile node. Further, in such a scenario, the mobile access gateway SHOULD terminate the binding of the mobile node by sending a Proxy Binding Update message to the mobile node's local mobility anchor with lifetime value set to 0. It MUST also remove any local state such as the Binding Update List entry created for that mobile node.
モバイルノードの現在既存のバインディングの寿命を延長するためのローカルモビリティアンカーにプロキシバインディング更新メッセージを送信する前に、モバイルアクセスゲートウェイは、信頼できる方法を使用して、モバイルノードが接続されたリンクにまだ接続されていることを確認する必要があります。モバイルアクセスゲートウェイが接続されたリンク上のモバイルノードの存在を予測可能に検出できない場合、モバイルノードの登録寿命を延長しようとしてはなりません。さらに、このようなシナリオでは、モバイルノードのローカルモビリティアンカーにプロキシバインディングアップデートメッセージを0に設定して、モバイルアクセスゲートウェイがモバイルノードのバインディングを終了する必要があります。そのモバイルノード用に作成されたバインディングアップデートリストエントリ。
The specific detection mechanism of the loss of a visiting mobile node on the connected link is specific to the access link between the mobile node and the mobile access gateway and is outside the scope of this document. Typically, there are various link-layer-specific events specific to each access technology that the mobile access gateway can depend on for detecting the node loss. In general, the mobile access gateway can depend on one or more of the following methods for the detection presence of the mobile node on the connected link: o Link-layer event specific to the access technology
接続されたリンク上のアクセスモバイルノードの損失の特定の検出メカニズムは、モバイルノードとモバイルアクセスゲートウェイの間のアクセスリンクに固有であり、このドキュメントの範囲外です。通常、モバイルアクセスゲートウェイがノード損失を検出するために依存できる各アクセステクノロジーに固有のさまざまなリンク層固有のイベントがあります。一般に、モバイルアクセスゲートウェイは、接続されたリンク上のモバイルノードの検出のための次の1つ以上の方法に依存できます。Oアクセステクノロジーに固有のリンクレイヤーイベント
o Session termination event on point-to-point link types
o ポイントツーポイントリンクタイプに関するセッション終了イベント
o IPv6 Neighbor Unreachability Detection event from IPv6 stack
o IPv6スタックからのIPv6ネイバーの到達不能検出イベント
o Notification event from the local mobility anchor
o ローカルモビリティアンカーからの通知イベント
In some Proxy Mobile IPv6 deployments, network operators may provision the mobile access gateway to offer network-based mobility management service only to some visiting mobile nodes and enable just regular IP access to some other nodes. This requires the network to have control on when to enable network-based mobility management service to a mobile node and when to enable regular IPv6 access. This specification does not disallow such configuration.
一部のプロキシモバイルIPv6の展開では、ネットワークオペレーターはモバイルアクセスゲートウェイをプロビジョニングして、ネットワークベースのモビリティ管理サービスをいくつかのモバイルノードにのみ提供し、他のノードへの定期的なIPアクセスのみを有効にすることができます。これには、ネットワークがモバイルノードにネットワークベースのモビリティ管理サービスを有効にする時期と、通常のIPv6アクセスを有効にするタイミングを制御する必要があります。この仕様では、そのような構成は禁止されていません。
Upon detecting a mobile node on its access link and after policy considerations, the mobile access gateway MUST determine if network-based mobility management service should be offered to that mobile node. If the mobile node is entitled to network-based mobility management service, then the mobile access gateway must ensure the mobile node does not detect any change with respect to its layer-3 attachment, as explained in various sections of this specification.
アクセスリンクでモバイルノードを検出し、ポリシーに関する考慮事項の後、モバイルアクセスゲートウェイは、ネットワークベースのモビリティ管理サービスをそのモバイルノードに提供するかどうかを判断する必要があります。モバイルノードがネットワークベースのモビリティ管理サービスを受ける資格がある場合、モバイルアクセスゲートウェイは、この仕様のさまざまなセクションで説明されているように、モバイルノードがレイヤー3アタッチメントに関する変更を検出しないようにする必要があります。
If the mobile node is not entitled to the network-based mobility management service, as determined from the policy considerations, the mobile access gateway MAY choose to offer regular IPv6 access to the mobile node, and in such a scenario, the normal IPv6 considerations apply. If IPv6 access is enabled, the mobile node SHOULD be able to obtain IPv6 address(es) using the normal IPv6 address configuration procedures. The obtained address(es) must be from a local visitor network prefix(es). This essentially ensures that the mobile access gateway functions as a normal access router to a mobile node attached to its access link and without impacting its host-based mobility protocol operation.
ポリシーの考慮事項から決定されたように、モバイルノードがネットワークベースのモビリティ管理サービスの資格がない場合、モバイルアクセスゲートウェイはモバイルノードへの定期的なIPv6アクセスを提供することを選択できます。。IPv6アクセスが有効になっている場合、モバイルノードは、通常のIPv6アドレス構成手順を使用してIPv6アドレスを取得できるはずです。取得したアドレスは、ローカルビジターネットワークプレフィックス（ES）からのものでなければなりません。これにより、Mobile Access Gatewayは、アクセスリンクに接続されたモバイルノードへの通常のアクセスルーターとして機能し、ホストベースのモビリティプロトコル操作に影響を与えることができます。
This non-normative section explains the mobile node's operation in a Proxy Mobile IPv6 domain.
この非規範的なセクションでは、プロキシモバイルIPv6ドメインでのモバイルノードの動作について説明します。
When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access network, the mobile access gateway on the access link detects the attachment of the mobile node and completes the binding registration with the mobile node's local mobility anchor. If the binding update operation is successfully performed, the mobile access gateway will create the required state and set up the forwarding for the mobile node's data traffic.
モバイルノードがプロキシモバイルIPv6ドメインに入り、アクセスネットワークに接続すると、アクセスリンクのモバイルアクセスゲートウェイがモバイルノードの添付ファイルを検出し、モバイルノードのローカルモビリティアンカーでのバインディング登録を完了します。バインディングアップデート操作が正常に実行された場合、モバイルアクセスゲートウェイは必要な状態を作成し、モバイルノードのデータトラフィックの転送を設定します。
When a mobile node attaches to the access link, it will typically send a Router Solicitation message [RFC4861]. The mobile access gateway on the access link will respond to the Router Solicitation message with a Router Advertisement message. The Router Advertisement message will carry the mobile node's home network prefix(es), default-router address, and other address configuration parameters.
モバイルノードがアクセスリンクに接続されると、通常、ルーター勧誘メッセージ[RFC4861]が送信されます。アクセスリンクのモバイルアクセスゲートウェイは、ルーター広告メッセージを使用してルーター勧誘メッセージに応答します。ルーター広告メッセージには、モバイルノードのホームネットワークプレフィックス（ES）、デフォルトルーターアドレス、およびその他のアドレス構成パラメーターが含まれます。
If the mobile access gateway on the access link receives a Router Solicitation message from the mobile node, before it completes the signaling with the mobile node's local mobility anchor, the mobile access gateway may not know the mobile node's home network prefix(es) and may not be able to emulate the mobile node's home link on the access link. In such a scenario, the mobile node may notice a delay before it receives a Router Advertisement message. This will also affect mobile nodes that would be capable of handling their own mobility, or mobile nodes that do not need to maintain the same IP address through movements.
アクセスリンクのモバイルアクセスゲートウェイがモバイルノードからルーター勧誘メッセージを受信した場合、モバイルノードのローカルモビリティアンカーで信号を完了する前に、モバイルアクセスゲートウェイはモバイルノードのホームネットワークプレフィックス（ES）と5月を知らない場合があります。アクセスリンクのモバイルノードのホームリンクをエミュレートできません。このようなシナリオでは、モバイルノードがルーター広告メッセージを受信する前に遅延に気付く場合があります。これは、独自のモビリティを処理できるモバイルノード、または同じIPアドレスを動きを介して維持する必要のないモバイルノードにも影響します。
If the received Router Advertisement message has the Managed Address Configuration flag set, the mobile node, as it would normally do, will send a DHCP Request [RFC3315]. The DHCP relay service enabled on that access link will ensure the mobile node can obtain one or more addresses from its home network prefix(es).
受信したルーター広告メッセージにマネージドアドレス構成フラグが設定されている場合、通常のようにモバイルノードはDHCPリクエスト[RFC3315]を送信します。そのアクセスリンクで有効にされるDHCPリレーサービスにより、モバイルノードがホームネットワークプレフィックス（ES）から1つ以上のアドレスを取得できるようにします。
If the received Router Advertisement message does not have the Managed Address Configuration flag set and if the mobile node is allowed to use autoconfigured address(es), the mobile node will be able to obtain IPv6 address(es) from each of its home network prefixes using any of the standard IPv6 address configuration mechanisms permitted for that mode.
受信したルーター広告メッセージにマネージドアドレス構成フラグが設定されておらず、モバイルノードがAutoConfiguredアドレス（ES）を使用できる場合、モバイルノードは各ホームネットワークプレフィックスからIPv6アドレスを取得できるようになります。そのモードで許可されている標準のIPv6アドレス構成メカニズムのいずれかを使用します。
If the mobile node is IPv4-enabled and if the network permits, it will be able to obtain the IPv4 address configuration, as specified in the companion document [IPV4-PMIP6].
モバイルノードがIPv4対応であり、ネットワークが許可されている場合、コンパニオンドキュメント[IPv4-PMIP6]で指定されているように、IPv4アドレス構成を取得できます。
Once the address configuration is complete, the mobile node can continue to use this address configuration as long as it is attached to the network that is in the scope of that Proxy Mobile IPv6 domain.
アドレス構成が完了すると、モバイルノードは、そのプロキシモバイルIPv6ドメインの範囲内にあるネットワークに添付されている限り、このアドレス構成を引き続き使用できます。
After obtaining the address configuration in the Proxy Mobile IPv6 domain, as the mobile node moves and changes its point of attachment from one mobile access gateway to the other, it can still continue to use the same address configuration. As long as the attached access link is in the scope of that Proxy Mobile IPv6 domain, the mobile node will always detect the same router advertising itself as a default-router and advertising the mobile node's home network prefix(es) on each connected link. If the mobile node has address configuration that it obtained using DHCP, it will be able to retain the address configuration and extend the lease lifetime.
プロキシモバイルIPv6ドメインでアドレス構成を取得した後、モバイルノードが移動して添付のポイントを1つのモバイルアクセスゲートウェイからもう一方のモバイルに変更すると、同じアドレス構成を引き続き使用できます。添付のアクセスリンクがそのプロキシモバイルIPv6ドメインの範囲内にある限り、モバイルノードは常にデフォルトルーターと同じルーター広告を検出し、各接続されたリンクのモバイルノードのホームネットワークプレフィックス（ES）を宣伝します。モバイルノードにDHCPを使用して取得したアドレス構成がある場合、アドレス構成を保持し、リース寿命を延長することができます。
This section defines extensions to the Mobile IPv6 [RFC3775] protocol messages.
このセクションでは、モバイルIPv6 [RFC3775]プロトコルメッセージへの拡張機能を定義します。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Binding Update message that is sent by a mobile access gateway to a local mobility anchor is referred to as the "Proxy Binding Update" message. A new flag (P) is included in the Binding Update message. The rest of the Binding Update message format remains the same as defined in [RFC3775] and with the additional (R) and (M) flags, as specified in [RFC3963] and [RFC4140], respectively.
ローカルモビリティアンカーにモバイルアクセスゲートウェイによって送信されるバインディングアップデートメッセージは、「プロキシバインディングアップデート」メッセージと呼ばれます。新しいフラグ（P）がバインディングアップデートメッセージに含まれています。バインディングアップデートメッセージ形式の残りの部分は、[RFC3775]で定義されているのと同じままで、[RFC3963]および[RFC4140]でそれぞれ指定されている追加（R）および（M）フラグがあります。
Proxy Registration Flag (P)
プロキシ登録フラグ（P）
A new flag (P) is included in the Binding Update message to indicate to the local mobility anchor that the Binding Update message is a proxy registration. The flag MUST be set to the value of 1 for proxy registrations and MUST be set to 0 for direct registrations sent by a mobile node.
新しいフラグ（P）がバインディングアップデートメッセージに含まれており、バインディングアップデートメッセージがプロキシ登録であることをローカルモビリティアンカーに示します。フラグは、プロキシ登録に対して1の値に設定する必要があり、モバイルノードから送信された直接登録の場合は0に設定する必要があります。
Mobility Options
モビリティオプション
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC3775]. The local mobility anchor MUST ignore and skip any options that it does not understand.
完全なモビリティヘッダーが長さ8オクターの整数倍であるような長さの可変長いフィールド。このフィールドには、ゼロ以上のTLVエンコードモビリティオプションが含まれています。定義されたオプションのエンコーディングと形式は、[RFC3775]のセクション6.2で説明されています。ローカルモビリティアンカーは、理解できないオプションを無視してスキップする必要があります。
As per this specification, the following mobility options are valid in a Proxy Binding Update message. These options can be present in the message in any order. There can be one or more instances of the Home Network Prefix options present in the message. However, there cannot be more than one instance of any of the following options.
この仕様に従って、次のモビリティオプションは、プロキシバインディングアップデートメッセージで有効です。これらのオプションは、任意の順序でメッセージに存在することができます。メッセージに存在するホームネットワークのプレフィックスオプションの1つ以上のインスタンスがあります。ただし、以下のオプションのいずれにも複数のインスタンスがあることはありません。
Mobile Node Identifier option
モバイルノード識別子オプション
Home Network Prefix option
ホームネットワークプレフィックスオプション
Handoff Indicator option
ハンドオフインジケータオプション
Access Technology Type option
アクセステクノロジータイプオプション
Timestamp option
タイムスタンプオプション
Mobile Node Link-layer Identifier option
モバイルノードリンクレイヤー識別子オプション
Link-local Address option
リンクローカルアドレスオプション
Additionally, there can be one or more instances of the Vendor-Specific Mobility option [RFC5094].
さらに、ベンダー固有のモビリティオプション[RFC5094]の1つ以上のインスタンスがある場合があります。
For descriptions of other fields present in this message, refer to Section 6.1.7 of [RFC3775].
このメッセージに存在する他のフィールドの説明については、[RFC3775]のセクション6.1.7を参照してください。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Binding Acknowledgement message that is sent by a local mobility anchor to a mobile access gateway is referred to as the "Proxy Binding Acknowledgement" message. A new flag (P) is included in the Binding Acknowledgement message. The rest of the Binding Acknowledgement message format remains the same as defined in [RFC3775] and with the additional (R) flag as specified in [RFC3963].
ローカルモビリティアンカーによってモバイルアクセスゲートウェイに送信される拘束力のある承認メッセージは、「プロキシバインディング確認」メッセージと呼ばれます。新しいフラグ（P）は、バインディング承認メッセージに含まれています。[RFC3775]で定義されているものと[RFC3963]で指定されている追加（r）フラグを使用して、バインディング承認メッセージ形式の残りは同じままです。
Proxy Registration Flag (P)
プロキシ登録フラグ（P）
A new flag (P) is included in the Binding Acknowledgement message to indicate that the local mobility anchor that processed the corresponding Proxy Binding Update message supports proxy registrations. The flag is set to a value of 1 only if the corresponding Proxy Binding Update had the Proxy Registration Flag (P) set to value of 1.
新しいフラグ（P）がバインディング承認メッセージに含まれており、対応するプロキシバインディングアップデートメッセージを処理したローカルモビリティアンカーがプロキシ登録をサポートしていることを示します。フラグは、対応するプロキシバインディングアップデートにプロキシ登録フラグ（p）が値1に設定されている場合にのみ、1の値に設定されます。
Mobility Options
モビリティオプション
A variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC3775]. The mobile access gateway MUST ignore and skip any options that it does not understand.
完全なモビリティヘッダーが長さ8オクターの整数倍であるような長さの可変長いフィールド。このフィールドには、ゼロ以上のTLVエンコードモビリティオプションが含まれています。定義されたオプションのエンコーディングと形式は、[RFC3775]のセクション6.2で説明されています。モバイルアクセスゲートウェイは、理解できないオプションを無視してスキップする必要があります。
As per this specification, the following mobility options are valid in a Proxy Binding Acknowledgement message. These options can be present in the message in any order. There can be one or more instances of the Home Network Prefix options present in the message. However, there cannot be more than one instance of any of the following options.
この仕様によると、次のモビリティオプションは、プロキシバインディングの確認メッセージで有効です。これらのオプションは、任意の順序でメッセージに存在することができます。メッセージに存在するホームネットワークのプレフィックスオプションの1つ以上のインスタンスがあります。ただし、以下のオプションのいずれにも複数のインスタンスがあることはありません。
Mobile Node Identifier option
モバイルノード識別子オプション
Home Network Prefix option
Handoff Indicator option
ハンドオフインジケータオプション
Access Technology Type option
アクセステクノロジータイプオプション
Timestamp option
タイムスタンプオプション
Mobile Node Link-layer Identifier option
モバイルノードリンクレイヤー識別子オプション
Link-local Address option
リンクローカルアドレスオプション
Additionally, there can be one or more instances of the Vendor-Specific Mobility option [RFC5094].
さらに、ベンダー固有のモビリティオプション[RFC5094]の1つ以上のインスタンスがある場合があります。
Status
スターテス
An 8-bit unsigned integer indicating the disposition of the Proxy Binding Update. Values of the Status field less than 128 indicate that the Proxy Binding Update was accepted by the local mobility anchor. Values greater than or equal to 128 indicate that the Proxy Binding Update message was rejected by the local mobility anchor. Section 8.9 defines the Status values that can used in Proxy Binding Acknowledgement message.
プロキシバインディングアップデートの処分を示す8ビットの非署名整数。128未満のステータスフィールドの値は、プロキシバインディングアップデートがローカルモビリティアンカーによって受け入れられたことを示しています。128以上の値は、プロキシバインディングアップデートメッセージがローカルモビリティアンカーによって拒否されたことを示しています。セクション8.9は、プロキシバインディング確認メッセージで使用できるステータス値を定義します。
For descriptions of other fields present in this message, refer to Section 6.1.8 of [RFC3775].
このメッセージに存在する他のフィールドの説明については、[RFC3775]のセクション6.1.8を参照してください。
A new option, Home Network Prefix option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile node's home network prefix information. There can be multiple Home Network Prefix options present in the message.
新しいオプションであるホームネットワークプレフィックスオプションは、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間で交換されるプロキシバインディングアップデートおよびプロキシバインディング確認メッセージで使用するために定義されています。このオプションは、モバイルノードのホームネットワークプレフィックス情報の交換に使用されます。メッセージには複数のホームネットワークプレフィックスオプションが存在する可能性があります。
The Home Network Prefix Option has an alignment requirement of 8n+4. Its format is as follows:
ホームネットワークプレフィックスオプションのアラインメント要件は8n 4です。その形式は次のとおりです。
0 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 | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 22
タイプ22
Length
長さ
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18.
タイプフィールドと長さフィールドを除く、オクテットのオプションの長さを示す8ビットの非署名整数。このフィールドは18に設定する必要があります。
Reserved (R)
予約済み（r）
This 8-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
この8ビットフィールドは今のところ使用されていません。値は送信者によって0に初期化され、レシーバーが無視する必要があります。
Prefix Length
プレフィックスの長さ
8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option.
オプションに含まれるIPv6プレフィックスのプレフィックスの長さを示す8ビットの非署名整数。
Home Network Prefix
ホームネットワークプレフィックス
A sixteen-byte field containing the mobile node's IPv6 Home Network Prefix.
モバイルノードのIPv6ホームネットワークプレフィックスを含む16バイトのフィールド。
A new option, Handoff Indicator option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile node's handoff-related hints.
新しいオプション、ハンドオフインジケーターオプションは、ローカルモビリティアンカーとモバイルアクセスゲートウェイの間で交換されるプロキシバインディングアップデートおよびプロキシバインディングの確認メッセージで使用するために定義されます。このオプションは、モバイルノードのハンドオフ関連のヒントを交換するために使用されます。
The Handoff Indicator option has no alignment requirement. Its format is as follows:
ハンドオフインジケーターオプションには、アライメント要件がありません。その形式は次のとおりです。
0 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 | Length | Reserved (R) | HI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 23
タイプ23
Length
長さ
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 2.
タイプフィールドと長さフィールドを除く、オクテットのオプションの長さを示す8ビットの非署名整数。このフィールドは2に設定する必要があります。
Reserved (R)
予約済み（r）
This 8-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
この8ビットフィールドは今のところ使用されていません。値は送信者によって0に初期化され、レシーバーが無視する必要があります。
Handoff Indicator (HI)
ハンドオフインジケーター（こんにちは）
An 8-bit field that specifies the type of handoff. The values (0 - 255) will be allocated and managed by IANA. The following values are currently defined.
ハンドオフのタイプを指定する8ビットフィールド。値（0-255）は、IANAによって割り当てられ、管理されます。現在、次の値が定義されています。
0: Reserved 1: Attachment over a new interface 2: Handoff between two different interfaces of the mobile node 3: Handoff between mobile access gateways for the same interface 4: Handoff state unknown 5: Handoff state not changed (Re-registration)
0：予約済み1：新しいインターフェイス上の添付ファイル2：モバイルノードの2つの異なるインターフェイス間のハンドオフ3：同じインターフェイスのモバイルアクセスゲートウェイ間のハンドオフ4：ハンドオフ状態不明5：ハンドオフ状態が変更されていない（再登録）
A new option, Access Technology Type option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the type of the access technology by which the mobile node is currently attached to the mobile access gateway.
新しいオプションであるアクセステクノロジータイプオプションは、ローカルモビリティアンカーとモバイルアクセスゲートウェイとの間で交換されるプロキシバインディングアップデートおよびプロキシバインディング確認メッセージで使用するために定義されます。このオプションは、モバイルノードが現在モバイルアクセスゲートウェイに添付されているアクセステクノロジーのタイプを交換するために使用されます。
The Access Technology Type Option has no alignment requirement. Its format is as follows:
アクセステクノロジータイプオプションには、アライメント要件がありません。その形式は次のとおりです。
0 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 | Length | Reserved (R) | ATT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 24
タイプ24
Length
長さ
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 2.
タイプフィールドと長さフィールドを除く、オクテットのオプションの長さを示す8ビットの非署名整数。このフィールドは2に設定する必要があります。
Reserved (R)
予約済み（r）
This 8-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
この8ビットフィールドは今のところ使用されていません。値は送信者によって0に初期化され、レシーバーが無視する必要があります。
Access Technology Type (ATT)
アクセステクノロジータイプ（att）
An 8-bit field that specifies the access technology through which the mobile node is connected to the access link on the mobile access gateway.
モバイルノードがモバイルアクセスゲートウェイのアクセスリンクに接続されるアクセステクノロジーを指定する8ビットフィールド。
The values (0 - 255) will be allocated and managed by IANA. The following values are currently reserved for the below specified access technology types.
値（0-255）は、IANAによって割り当てられ、管理されます。現在、以下の指定されたアクセステクノロジーの種類には、以下の値が予約されています。
0: Reserved ("Reserved") 1: Virtual ("Logical Network Interface") 2: PPP ("Point-to-Point Protocol") 3: IEEE 802.3 ("Ethernet") 4: IEEE 802.11a/b/g ("Wireless LAN") 5: IEEE 802.16e ("WIMAX")
0：予約（ "予約済み"）1：仮想（ "論理ネットワークインターフェイス"）2：PPP（ "ポイントツーポイントプロトコル"）3：IEEE 802.3（ "イーサネット"）4：IEEE 802.11a/b/g（「ワイヤレスLAN」）5：IEEE 802.16E（ "Wimax"）
A new option, Mobile Node Link-layer Identifier option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile node's link-layer identifier.
新しいオプションであるモバイルノードリンクレイヤー識別子オプションは、ローカルモビリティアンカーとモバイルアクセスゲートウェイとの間で交換されるプロキシバインディングアップデートおよびプロキシバインディング確認メッセージで使用するために定義されます。このオプションは、モバイルノードのリンク層識別子の交換に使用されます。
The format of the Link-layer Identifier option is shown below. Based on the size of the identifier, the option MUST be aligned appropriately, as per mobility option alignment requirements specified in [RFC3775].
リンク層識別子オプションの形式を以下に示します。識別子のサイズに基づいて、[RFC3775]で指定されたモビリティオプションアライメント要件に従って、オプションを適切に整列する必要があります。
0 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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Link-layer Identifier +
. ... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 25
タイプ25
Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
長さ8ビットの符号なし整数は、タイプと長さのフィールドを除く、オクテットのオプションの長さを示します。
Reserved
予約済み
This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
このフィールドは今のところ使用されていません。値は送信者によって0に初期化され、レシーバーが無視する必要があります。
Link-layer Identifier
リンク層識別子
A variable length field containing the mobile node's link-layer identifier.
モバイルノードのリンク層識別子を含む可変長フィールド。
The content and format of this field (including byte and bit ordering) is as specified in Section 4.6 of [RFC4861] for carrying link-layer addresses. On certain access links, where the link-layer address is not used or cannot be determined, this option cannot be used.
このフィールドのコンテンツと形式（BYTEおよびBIT順序付けを含む）は、リンク層アドレスを運ぶために[RFC4861]のセクション4.6で指定されているとおりです。リンク層アドレスを使用していない、または決定できない特定のアクセスリンクでは、このオプションは使用できません。
A new option, Link-local Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the link-local address of the mobile access gateway.
新しいオプションであるLink-Localアドレスオプションは、ローカルモビリティアンカーとモバイルアクセスゲートウェイとの間で交換されるプロキシバインディングアップデートおよびプロキシバインド確認メッセージで使用するために定義されます。このオプションは、モバイルアクセスゲートウェイのリンクローカルアドレスを交換するために使用されます。
The Link-local Address option has an alignment requirement of 8n+6. Its format is as follows:
Link-Local Addressオプションには、8N 6のアライメント要件があります。その形式は次のとおりです。
0 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-local Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 26
タイプ26
Length
長さ
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16.
タイプフィールドと長さフィールドを除く、オクテットのオプションの長さを示す8ビットの非署名整数。このフィールドは16に設定する必要があります。
Link-local Address
リンクローカルアドレス
A sixteen-byte field containing the link-local address.
Link-Localアドレスを含む16バイトのフィールド。
A new option, Timestamp option is defined for use in the Proxy Binding Update and Proxy Binding Acknowledgement messages.
新しいオプションであるTimestampオプションは、プロキシバインディングアップデートおよびプロキシバインディング確認メッセージで使用するために定義されています。
The Timestamp option has an alignment requirement of 8n+2. Its format is as follows:
タイムスタンプオプションには、8n 2のアライメント要件があります。その形式は次のとおりです。
0 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 27
タイプ27
Length
長さ
8-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. The value for this field MUST be set to 8.
タイプフィールドと長さフィールドを除く、オプションのオクテットの長さを示す8ビットの非署名整数。このフィールドの値は8に設定する必要があります。
Timestamp
タイムスタンプ
A 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/65536 fractions of a second.
タイムスタンプを含む64ビットの署名されていない整数フィールド。値は、固定点形式を使用して、1970年1月1日、00:00 UTC以降の秒数を示しています。この形式では、整数秒数はフィールドの最初の48ビットに含まれ、残りの16ビットは1/65536秒数の数を示します。
This document defines the following new Status values for use in Proxy Binding Acknowledgement messages. These values are to be allocated from the same number space, as defined in Section 6.1.8 of [RFC3775].
このドキュメントでは、プロキシバインディング承認メッセージで使用するための次の新しいステータス値を定義します。これらの値は、[RFC3775]のセクション6.1.8で定義されているように、同じ数のスペースから割り当てられます。
Status values less than 128 indicate that the Proxy Binding Update message was accepted by the local mobility anchor. Status values greater than 128 indicate that the Proxy Binding Update was rejected by the local mobility anchor.
128未満のステータス値は、プロキシバインディングアップデートメッセージがローカルモビリティアンカーによって受け入れられたことを示しています。128を超えるステータス値は、プロキシバインディングアップデートがローカルモビリティアンカーによって拒否されたことを示しています。
PROXY_REG_NOT_ENABLED: 152
proxy_reg_not_enabled：152
Proxy registration not enabled for the mobile node
モバイルノードのプロキシ登録は有効になっていません
NOT_LMA_FOR_THIS_MOBILE_NODE: 153
not_lma_for_this_mobile_node：153
Not local mobility anchor for this mobile node
このモバイルノードのローカルモビリティアンカーではありません
MAG_NOT_AUTHORIZED_FOR_PROXY_REG: 154
mag_not_authorized_for_proxy_reg：154
The mobile access gateway is not authorized to send proxy binding updates
モバイルアクセスゲートウェイは、プロキシバインディングの更新を送信する権限がありません
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: 155
not_authorized_for_home_network_prefix：155
The mobile node is not authorized for one or more of the requesting home network prefixes
モバイルノードは、1つ以上のリクエストホームネットワークプレフィックスに対して許可されていません
TIMESTAMP_MISMATCH: 156
timestamp_mismatch：156
Invalid timestamp value (the clocks are out of sync)
TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: 157
timestamp_lower_than_prev_accepted：157
The timestamp value is lower than the previously accepted value
タイムスタンプの値は、以前に受け入れられた値よりも低い
MISSING_HOME_NETWORK_PREFIX_OPTION: 158
Missing_home_network_prefix_option：158
Missing home network prefix option
ホームネットワークのプレフィックスオプションがありません
BCE_PBU_PREFIX_SET_DO_NOT_MATCH: 159
bce_pbu_prefix_set_do_not_match：159
All the home network prefixes listed in the BCE do not match all the prefixes in the received PBU
BCEにリストされているすべてのホームネットワークプレフィックスは、受信したPBUのすべてのプレフィックスと一致しません
MISSING_MN_IDENTIFIER_OPTION: 160
Missing_mn_identifier_option：160
Missing mobile node identifier option
モバイルノード識別子がありませんオプション
MISSING_HANDOFF_INDICATOR_OPTION: 161
Missing_handoff_indicator_option：161
Missing handoff indicator option
ハンドオフインジケータオプションがありません
MISSING_ACCESS_TECH_TYPE_OPTION: 162
Missing_access_tech_type_option：162
Missing access technology type option
アクセステクノロジータイプの欠落オプション
Additionally, the following Status values defined in [RFC3775] can also be used in a Proxy Binding Acknowledgement message.
さらに、[RFC3775]で定義されている次のステータス値は、プロキシバインド確認メッセージでも使用できます。
0 Proxy Binding Update accepted
0プロキシバインディングアップデートが受け入れられました
128 Reason unspecified
128理由不特定
129 Administratively prohibited
129管理上禁止
130 Insufficient resources
130不十分なリソース
The local mobility anchor MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts.
ローカルモビリティアンカーは、システム管理によって次の変数を構成できるようにする必要があります。これらのプロトコル変数の構成値は、サーバーの再起動とサービスの再起動に耐える必要があります。
MinDelayBeforeBCEDelete
Mindelaybeforebcedelete
This variable specifies the amount of time in milliseconds the local mobility anchor MUST wait before it deletes a Binding Cache entry of a mobile node, upon receiving a Proxy Binding Update message from a mobile access gateway with a lifetime value of 0. During this wait time, if the local mobility anchor receives a Proxy Binding Update for the same mobility binding, with a lifetime value greater than 0, then it must update the binding cache entry with the accepted binding values. By the end of this wait-time, if the local mobility anchor did not receive any valid Proxy Binding Update message for that mobility binding, it MUST delete the Binding Cache entry. This delay essentially ensures a mobile node's Binding Cache entry is not deleted too quickly and allows some time for the new mobile access gateway to complete the signaling for the mobile node.
この変数は、ミリ秒単位での時間を指定します。ローカルモビリティアンカーは、モバイルノードのバインディングキャッシュエントリを削除する前に待機する必要があります。、ローカルモビリティアンカーが、同じモビリティバインディングのプロキシバインディングアップデートを受信し、寿命の値が0を超える場合、受け入れられたバインディング値でバインディングキャッシュエントリを更新する必要があります。この待機時間の終わりまでに、ローカルモビリティアンカーがそのモビリティバインディングの有効なプロキシバインディングアップデートメッセージを受け取らなかった場合、バインディングキャッシュエントリを削除する必要があります。この遅延により、本質的にモバイルノードのバインディングキャッシュエントリが削除されなくなり、新しいモバイルアクセスゲートウェイがモバイルノードの信号を完了するのに時間がかかります。
The default value for this variable is 10000 milliseconds.
この変数のデフォルト値は10000ミリ秒です。
MaxDelayBeforeNewBCEAssign
maxdelaybeforenewbceassign
This variable specifies the amount of time in milliseconds the local mobility anchor MUST wait for the de-registration message for an existing mobility session before it decides to create a new mobility session.
この変数は、新しいモビリティセッションの作成を決定する前に、既存のモビリティセッションの登録解除メッセージを待機する必要があるミリ秒単位での時間を指定します。
The default value for this variable is 1500 milliseconds.
この変数のデフォルト値は1500ミリ秒です。
Note that there is a dependency between this value and the values used in the retransmission algorithm for Proxy Binding Updates. The retransmissions need to happen before MaxDelayBeforeNewBCEAssign runs out, as otherwise there are situations where a de-registration from a previous mobile access gateway may be lost, and the local mobility anchor creates, needlessly, a new mobility session and new prefixes for the mobile node. However, this affects situations where there is no information from the lower layers about the type of a handoff or other parameters that can be used for identifying the mobility session.
この値と、プロキシバインディングの更新のために再送信アルゴリズムで使用される値との間には依存関係があることに注意してください。MaxdelaybeforenewbceasSignがなくなる前に再送信が発生する必要があります。そうしないと、以前のモバイルアクセスゲートウェイからの解体が失われ、ローカルモビリティアンカーが不必要に、モバイル節の新しいモビリティセッションと新しいプレフィックスを作成する状況があります。。ただし、これは、モビリティセッションの識別に使用できるハンドオフまたはその他のパラメーターの種類に関する下層からの情報がない状況に影響します。
TimestampValidityWindow
TimestAmpalidityWindow
This variable specifies the maximum amount of time difference in milliseconds between the timestamp in the received Proxy Binding Update message and the current time of day on the local mobility anchor, that is allowed by the local mobility anchor for the received message to be considered valid.
この変数は、受信したプロキシバインディングアップデートメッセージのタイムスタンプと、ローカルモビリティアンカーの現在の時刻の間のミリ秒の時間差の最大量を指定します。
The default value for this variable is 300 milliseconds. This variable must be adjusted to suit the deployments.
この変数のデフォルト値は300ミリ秒です。この変数は、展開に合わせて調整する必要があります。
The mobile access gateway MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts.
モバイルアクセスゲートウェイは、システム管理によって次の変数を構成する必要があります。これらのプロトコル変数の構成値は、サーバーの再起動とサービスの再起動に耐える必要があります。
EnableMAGLocalRouting
EnablemaglocalRouting
This flag indicates whether or not the mobile access gateway is allowed to enable local routing of the traffic exchanged between a visiting mobile node and a correspondent node that is locally connected to one of the interfaces of the mobile access gateway. The correspondent node can be another visiting mobile node as well, or a local fixed node.
The default value for this flag is set to a value of 0, indicating that the mobile access gateway MUST reverse tunnel all the traffic to the mobile node's local mobility anchor.
このフラグのデフォルト値は0の値に設定されており、モバイルアクセスゲートウェイがモバイルノードのローカルモビリティアンカーへのすべてのトラフィックを逆転させる必要があることを示しています。
When the value of this flag is set to a value of 1, the mobile access gateway MUST route the traffic locally.
このフラグの値が1の値に設定されている場合、モバイルアクセスゲートウェイはトラフィックをローカルにルーティングする必要があります。
This aspect of local routing MAY be defined as policy on a per mobile basis and when present will take precedence over this flag.
ローカルルーティングのこの側面は、モバイルごとのポリシーとして定義される場合があり、存在する場合はこのフラグよりも優先されます。
All the mobile entities (local mobility anchors and mobile access gateways) in a Proxy Mobile IPv6 domain MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts. These variables MUST be globally fixed for a given Proxy Mobile IPv6 domain resulting in the same values being enforced on all the mobility entities in that domain.
プロキシモバイルIPv6ドメインのすべてのモバイルエンティティ（ローカルモビリティアンカーとモバイルアクセスゲートウェイ）は、システム管理によって次の変数を構成する必要があります。これらのプロトコル変数の構成値は、サーバーの再起動とサービスの再起動に耐える必要があります。これらの変数は、特定のプロキシモバイルIPv6ドメインに対してグローバルに固定する必要があり、その結果、そのドメインのすべてのモビリティエンティティで同じ値が施行されます。
TimestampBasedApproachInUse
TimestampasedApproachinuse
This flag indicates whether or not the timestamp-based approach for message ordering is in use in that Proxy Mobile IPv6 domain. When the value for this flag is set to 1, all the mobile access gateways in that Proxy Mobile IPv6 domain MUST apply the timestamp-based considerations listed in Section 5.5. When the value of this flag is set to 0, sequence-number-based considerations listed in Section 5.5 MUST be applied. The default value for this flag is set to value of 1, indicating that the timestamp-based mechanism is in use in that Proxy Mobile IPv6 domain.
このフラグは、そのプロキシモバイルIPv6ドメインでメッセージ順序付けのためのタイムスタンプベースのアプローチが使用されているかどうかを示します。このフラグの値が1に設定されている場合、そのプロキシモバイルIPv6ドメインのすべてのモバイルアクセスゲートウェイは、セクション5.5にリストされているタイムスタンプベースの考慮事項を適用する必要があります。このフラグの値が0に設定されている場合、セクション5.5にリストされているシーケンス番号ベースの考慮事項を適用する必要があります。このフラグのデフォルト値は1の値に設定されており、そのプロキシモバイルIPv6ドメインでタイムスタンプベースのメカニズムが使用されていることを示しています。
MobileNodeGeneratedTimestampInUse
This flag indicates whether or not the mobile-node-generated timestamp approach is in use in that Proxy Mobile IPv6 domain. When the value for this flag is set to 1, the local mobility anchors and mobile access gateways in that Proxy Mobile IPv6 domain MUST apply the mobile node generated timestamp considerations as specified in Section 5.5.
このフラグは、モバイルノードで生成されたタイムスタンプアプローチがそのプロキシモバイルIPv6ドメインで使用されているかどうかを示します。このフラグの値が1に設定されている場合、そのプロキシモバイルIPv6ドメインのローカルモビリティアンカーとモバイルアクセスゲートウェイは、セクション5.5で指定されているように、モバイルノード生成タイムスタンプの考慮事項を適用する必要があります。
This flag is relevant only when timestamp-based approach is in use. The value for this flag MUST NOT be set to value of 1, if the value of the TimestampBasedApproachInUse flag is set to 0.
このフラグは、タイムスタンプベースのアプローチが使用されている場合にのみ関連します。このフラグの値は、タイムスタンプベースのアプローチン化フラグの値が0に設定されている場合、値を1の値に設定してはなりません。
The default value for this flag is set to value of 0, indicating that the mobile node generated timestamp mechanism is not in use in that Proxy Mobile IPv6 domain.
このフラグのデフォルト値は0に設定されており、モバイルノード生成されたタイムスタンプメカニズムがそのプロキシモバイルIPv6ドメインで使用されていないことを示しています。
FixedMAGLinkLocalAddressOnAllAccessLinks
This variable indicates the link-local address value that all the mobile access gateways SHOULD use on any of the access links shared with any of the mobile nodes in that Proxy Mobile IPv6 domain. If this variable is initialized to ALL_ZERO value, it implies the use of fixed link-local address mode is not enabled for that Proxy Mobile IPv6 domain.
この変数は、すべてのモバイルアクセスゲートウェイが、そのプロキシモバイルIPv6ドメインのモバイルノードのいずれかと共有されるアクセスリンクのいずれかで使用すべきリンクローカルアドレス値を示します。この変数がALL_ZERO値に初期化されている場合、そのプロキシモバイルIPv6ドメインでは、固定リンクローカルアドレスモードの使用が有効になっていないことを意味します。
FixedMAGLinkLayerAddressOnAllAccessLinks
This variable indicates the link-layer address value that all the mobile access gateways SHOULD use on any of the access links shared with any of the mobile nodes in that Proxy Mobile IPv6 domain. For access technologies where there is no link-layer address, this variable MUST be initialized to ALL_ZERO value.
この変数は、すべてのモバイルアクセスゲートウェイが、そのプロキシモバイルIPv6ドメインのモバイルノードのいずれかと共有されるアクセスリンクのいずれかで使用するリンク層アドレス値を示します。リンク層アドレスがないアクセステクノロジーの場合、この変数はALL_ZERO値に初期化する必要があります。
This document defines six new Mobility Header options, the Home Network Prefix Option, Handoff Indicator Option, Access Technology Type Option, Mobile Node Link-layer Identifier Option, Link-local Address Option, and Timestamp Option. These options are described in Section 8. The Type value for these options has been assigned from the same numbering space as allocated for the other mobility options, as defined in [RFC3775].
このドキュメントでは、6つの新しいモビリティヘッダーオプション、ホームネットワークプレフィックスオプション、ハンドオフインジケーターオプション、アクセステクノロジータイプオプション、モバイルノードリンク層識別子オプション、リンクローカルアドレスオプション、およびタイムスタンプオプションを定義します。これらのオプションはセクション8で説明されています。これらのオプションのタイプ値は、[RFC3775]で定義されているように、他のモビリティオプションに割り当てられたのと同じ番号付けスペースから割り当てられています。
The Handoff Indicator Option, defined in Section 8.4 of this document, introduces a new Handoff Indicator (HI) numbering space, where the values from 0 to 5 have been reserved by this document. Approval of new Handoff Indicator type values are to be made through IANA Expert Review.
このドキュメントのセクション8.4で定義されているハンドオフインジケータオプションは、0〜5の値がこのドキュメントによって予約されている新しいハンドオフインジケーター（HI）番号のスペースを導入します。新しいハンドオフインジケータータイプの値の承認は、IANA Expert Reviewを通じて行われます。
The Access Technology Type Option, defined in Section 8.5 of this document, introduces a new Access Technology type (ATT) numbering space, where the values from 0 to 5 have been reserved by this document. Approval of new Access Technology type values are to be made through IANA Expert Review.
このドキュメントのセクション8.5で定義されているアクセステクノロジータイプのオプションは、0〜5の値がこのドキュメントによって予約されている新しいアクセステクノロジータイプ（ATT）の番号付けスペースを導入します。新しいアクセステクノロジータイプの値の承認は、IANA Expert Reviewを通じて行われます。
This document also defines new Binding Acknowledgement status values, as described in Section 8.9. The status values MUST be assigned from the same number space used for Binding Acknowledgement status values, as defined in [RFC3775]. The allocated values for each of these status values must be greater than 128.
このドキュメントは、セクション8.9で説明されているように、新しいバインディング確認ステータス値も定義します。[RFC3775]で定義されているように、ステータス値は、拘束力のある確認ステータス値に使用される同じ数値スペースから割り当てる必要があります。これらの各ステータス値の割り当てられた値は、128を超える必要があります。
This document creates a new registry for the flags in the Binding Update message called the "Binding Update Flags".
このドキュメントは、「バインディングアップデートフラグ」と呼ばれるバインディングアップデートメッセージにフラグの新しいレジストリを作成します。
The following flags are reserved:
次のフラグが予約されています。
(A) 0x8000 [RFC3775]
（a）0x8000 [RFC3775]
(H) 0x4000 [RFC3775]
（H）0x4000 [RFC3775]
(L) 0x2000 [RFC3775]
（l）0x2000 [RFC3775]
(K) 0x1000 [RFC3775]
（k）0x1000 [RFC3775]
(M) 0x0800 [RFC4140]
（M）0x0800 [RFC4140]
(R) 0x0400 [RFC3963]
（R）0x0400 [RFC3963]
This document reserves a new flag (P) as follows:
このドキュメントは、次のように新しいフラグ（P）を留保します。
(P) 0x0200
（P）0x0200
The rest of the values in the 16-bit field are reserved. New values can be assigned by Standards Action or IESG approval.
16ビットフィールドの残りの値は予約されています。新しい値は、標準アクションまたはIESGの承認によって割り当てることができます。
This document also creates a new registry for the flags in the Binding Acknowledgment message called the "Binding Acknowledgment Flags". The following values are reserved.
このドキュメントでは、「拘束力のある確認フラグ」と呼ばれる拘束力のある承認メッセージにフラグの新しいレジストリも作成されます。次の値は予約されています。
(K) 0x80 [RFC3775]
（k）0x80 [RFC3775]
(R) 0x40 [RFC3963]
（R）0x40 [RFC3963]
This document reserves a new flag (P) as follows:
このドキュメントは、次のように新しいフラグ（P）を留保します。
(P) 0x20
（p）0x20
The rest of the values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG approval.
8ビットフィールドの残りの値は予約されています。新しい値は、標準アクションまたはIESGの承認によって割り当てることができます。
The potential security threats against any network-based mobility management protocol are described in [RFC4832]. This section explains how Proxy Mobile IPv6 protocol defends itself against those threats.
ネットワークベースのモビリティ管理プロトコルに対する潜在的なセキュリティの脅威は、[RFC4832]で説明されています。このセクションでは、プロキシモバイルIPv6プロトコルがこれらの脅威からどのように擁護するかについて説明します。
Proxy Mobile IPv6 protocol recommends the signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor to be protected using IPsec using the established security association between them. This essentially eliminates the threats related to the impersonation of the mobile access gateway or the local mobility anchor.
プロキシモバイルIPv6プロトコルは、モバイルアクセスゲートウェイとローカルモビリティアンカーとの間で交換され、それらの間の確立されたセキュリティアソシエーションを使用してIPSECを使用して保護されるシグナリングメッセージ、プロキシバインディングアップデート、およびプロキシバインディングバインディングの確認を推奨します。これにより、モバイルアクセスゲートウェイまたはローカルモビリティアンカーのなりすましに関連する脅威が本質的に排除されます。
This specification allows a mobile access gateway to send binding registration messages on behalf of a mobile node. If proper authorization checks are not in place, a malicious node may be able to hijack a mobile node's mobility session or may carry out a denial-of-service attack. To prevent this attack, this specification requires the local mobility anchor to allow only authorized mobile access gateways that are part of that Proxy Mobile IPv6 domain to send Proxy Binding Update messages on behalf of a mobile node.
この仕様により、モバイルアクセスゲートウェイがモバイルノードに代わってバインディング登録メッセージを送信できます。適切な承認チェックが整っていない場合、悪意のあるノードはモバイルノードのモビリティセッションをハイジャックできるか、サービス拒否攻撃を実行する可能性があります。この攻撃を防ぐために、この仕様では、ローカルモビリティアンカーに、そのプロキシモバイルIPv6ドメインの一部である認定されたモバイルアクセスゲートウェイのみが、モバイルノードに代わってプロキシバインディングアップデートメッセージを送信できるようにする必要があります。
To eliminate the threats on the interface between the mobile access gateway and the mobile node, this specification requires an established trust between the mobile access gateway and the mobile node and to authenticate and authorize the mobile node before it is allowed to access the network. Further, the established authentication mechanisms enabled on that access link will ensure that there is a secure binding between the mobile node's identity and its link-layer address. The mobile access gateway will definitively identify the mobile node from the packets that it receives on that access link.
モバイルアクセスゲートウェイとモバイルノードの間のインターフェイスの脅威を排除するには、この仕様には、モバイルアクセスゲートウェイとモバイルノードの間に確立された信頼が必要であり、ネットワークにアクセスする前にモバイルノードを認証および承認する必要があります。さらに、そのアクセスリンクで有効になっている確立された認証メカニズムにより、モバイルノードのIDとそのリンク層アドレスの間に安全なバインディングがあることが保証されます。モバイルアクセスゲートウェイは、そのアクセスリンクで受信するパケットからモバイルノードを明確に識別します。
To address the threat related to a compromised mobile access gateway, the local mobility anchor, before accepting a Proxy Binding Update message for a given mobile node, may ensure that the mobile node is attached to the mobile access gateway that sent the Proxy Binding Update message. This may be accomplished by contacting a trusted entity, which is able to track the mobile node's current point of attachment. However, the specific details of the actual mechanisms for achieving this is outside the scope of this document.
侵害されたモバイルアクセスゲートウェイに関連する脅威に対処するために、特定のモバイルノードのプロキシバインディングアップデートメッセージを受け入れる前に、ローカルモビリティアンカーは、プロキシバインディングアップデートメッセージを送信するモバイルアクセスゲートウェイにモバイルノードが添付されていることを確認することができます。これは、モバイルノードの現在の添付ポイントを追跡できる信頼できるエンティティに連絡することで実現できます。ただし、これを達成するための実際のメカニズムの特定の詳細は、このドキュメントの範囲外です。
The authors would like to specially thank Jari Arkko, Julien Laganier, Christian Vogt, Dave Thaler, Pasi Eronen, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi, and Elwyn Davies for their thorough reviews of this document.
著者は、この文書の徹底的なレビューについて、ジャリ・アークコ、ジュリエン・ラガニエ、クリスチャン・ヴォイト、デイブ・ターラー、パシ・エロネン、ピート・マッキャン、アフマド・ムハンナ、ジンヒヨック・チェ、エルウィン・デイヴィスに特別に感謝したいと思います。
The authors would also like to thank Alex Petrescu, Alice Qinxia, Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Charles Perkins, Domagoj Premec, Fred Templin, Genadi Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham Soliman, James Kempf, Jean-Michel Combes, John Jason Brzozowski, Jun Awano, John Zhao, Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian Weniger, Lars Eggert, Magnus Westerlund, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Pierrick Seite, Phil Roberts, Ralph Droms, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Tero Kauppinen, Uri Blumenthal, Ved Kafle, Vidya Narayanan, Youn-Hee Han, and many others for their passionate discussions in the working group mailing list on the topic of localized mobility management solutions. These discussions stimulated much of the thinking and shaped the document to the current form and we acknowledge that!
著者はまた、アレックス・ペトレスク、アリス・チンキシア、アルパー・イギン、アシュトシュ・ダッタ、ベーチェット・サリカヤ、チャールズ・パーキンス、ドマゴジ・プレムク、フレッド・テンプリン、ジェナディ・ヴェレフ、ジョージ・トジルツシス、ジェラルド・ジアレッタ、ヘンリク・レヴコウェッツ、ジェームス・ソレッタに感謝したいと思います。-Michel Combes、John Jason Brzozowski、Jun Awano、John Zhao、Jong-Hyouk Lee、Jonne Soininen、Jouni Korhonen、Kalin Getov、Kilian Weniger、Lars Eggert、Magnus Westerlund、Marco Liebsch、Mohamed Khalil、Philatロバーツ、ラルフ・ドロム、リュジ・ワキカワ、サンジン・ジョン、スレシュ・クリシュナン、テロ・カウピネン、ウリ・ブルーメンタル、ヴェド・カフル、ヴィディヤ・ナラヤナン、ヤング・ヒー・ハン、その他多くの人が、ローカライズされたモビリティのトピックのトピックでの作業グループの郵送リストでの情熱的な議論のために管理ソリューション。これらの議論は思考の多くを刺激し、文書を現在のフォームに形作り、私たちはそれを認めます！
The authors would also like to thank Ole Troan, Akiko Hattori, Parviz Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer, Tim Stammers, Bernie Volz, and Josh Littlefield for their input on this document.
著者はまた、この文書への入力について、Ole Troan、Akiko Hattori、Akiko hattori、Parviz Yegeri、Mark Grayson、Michael Hammer、Vojislav Vucetic、Jay Iyer、Tim Stammers、Bernie Volz、Josh Littlefieldにも感謝したいと思います。
[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月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[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月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6（MIPV6）のモバイルノード識別子オプション」、RFC 4283、2005年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[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月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[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月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[RFC4140] Soliman、H.、Castelluccia、C.、El Malki、K。、およびL. Bellier、「階層モバイルIPv6モビリティ管理（HMIPV6）」、RFC 4140、2005年8月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（SNTP）バージョン4」、RFC 4330、2006年1月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
[RFC4372] Adrangi、F.、Lior、A.、Korhonen、J。、およびJ. Loughney、「chargeable user Identity」、RFC 4372、2006年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC4830] Kempf, J., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007.
[RFC4830] Kempf、J。、「ネットワークベースのローカライズされたモビリティ管理（NetLMM）の問題ステートメント」、RFC 4830、2007年4月。
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.
[RFC4831] KEMPF、J。、「ネットワークベースのローカライズされたモビリティ管理（NETLMM）の目標」、RFC 4831、2007年4月。
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
[RFC4832] Vogt、C。およびJ. Kempf、「ネットワークベースのローカライズされたモビリティ管理（NetLMM）に対するセキュリティの脅威」、RFC 4832、2007年4月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007.
[RFC5094] Devarapalli、V.、Patel、A。、およびK. Leung、「モバイルIPv6ベンダー固有のオプション」、RFC 5094、2007年12月。
[IPV4-PMIP6] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", Work in Progress, May 2008.
[IPv4-PMIP6] Wakikawa、R。およびS. Gundavelli、「Proxy Mobile IPv6のIPv4サポート」、2008年5月の作業。
[DNAV6] Narayanan, S., Ed., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Work in Progress, February 2008.
[dnav6] Narayanan、S.、ed。、「IPv6ネットワーク（DNAV6）のネットワーク添付ファイルの検出」、2008年2月、進行中の作業。
Every mobile node that roams in a proxy Mobile IPv6 domain would typically be identified by an identifier, MN-Identifier, and that identifier will have an associated policy profile that identifies the mobile node's home network prefix(es) on a per-interface basis, permitted address configuration modes, roaming policy, and other parameters that are essential for providing network-based mobility management service. This information is typically configured in AAA. In some cases, the home network prefix(es) may be dynamically assigned to the mobile node's interface, after its initial attachment to the Proxy Mobile IPv6 domain over that interface and may not be configured in the mobile node's policy profile.
プロキシモバイルIPv6ドメインをローミングするすべてのモバイルノードは、通常、識別子であるMN-IDENTIFIERによって識別され、その識別子には、モバイルノードのホームネットワークプレフィックス（ES）がインターフェイスごとに識別される関連するポリシープロファイルがあります。許可されたアドレス構成モード、ローミングポリシー、およびネットワークベースのモビリティ管理サービスを提供するために不可欠なその他のパラメーター。この情報は通常、AAAで構成されています。場合によっては、ホームネットワークのプレフィックス（ES）は、そのインターフェイス上のプロキシモバイルIPv6ドメインへの最初の添付ファイルの後、モバイルノードのインターフェイスに動的に割り当てられ、モバイルノードのポリシープロファイルで構成されない場合があります。
The network entities in the proxy Mobile IPv6 domain, while serving a mobile node, will have access to the mobile node's policy profile and these entities can query this information using RADIUS [RFC2865] or DIAMETER [RFC3588] protocols.
プロキシモバイルIPv6ドメインのネットワークエンティティは、モバイルノードを提供しますが、モバイルノードのポリシープロファイルにアクセスでき、これらのエンティティはRADIUS [RFC2865]または直径[RFC3588]プロトコルを使用してこの情報を照会できます。
The following section explains the routing state created for a mobile node on the mobile access gateway. This routing state reflects only one specific way of implementation, and one MAY choose to implement it in other ways. The policy based route defined below acts as a traffic selection rule for routing a mobile node's traffic through a specific tunnel created between the mobile access gateway and that mobile node's local mobility anchor and with the specific encapsulation mode, as negotiated.
次のセクションでは、モバイルアクセスゲートウェイのモバイルノード用に作成されたルーティング状態について説明します。このルーティング状態は、特定の実装方法のみを反映しており、他の方法で実装することを選択できます。以下に定義されているポリシーベースのルートは、モバイルアクセスゲートウェイとそのモバイルノードのローカルモビリティアンカーの間に作成された特定のトンネルを介してモバイルノードのトラフィックをルーティングするためのトラフィック選択ルールとして機能します。
The below example identifies the routing state for two visiting mobile nodes, MN1 and MN2, with their respective local mobility anchors, LMA1 and LMA2.
以下の例は、それぞれのローカルモビリティアンカー、LMA1およびLMA2を使用して、2つの訪問モバイルノード、MN1とMN2のルーティング状態を識別します。
For all traffic from the mobile node, identified by the mobile node's MAC address, ingress interface or source prefix (MN-HNP) to _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA.
モバイルノードのMACアドレス、イングレスインターフェイスまたはソースプレフィックス（MN-HNP）で識別されるモバイルノードからのすべてのトラフィックについて、インターフェイスTunnel0、Next-HOP LMAAを介して_ANY_DESTINATION_ルートへ。
+==================================================================+
| Packet Source | Destination Address | Destination Interface |
+==================================================================+
| MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 |
| (IPv6 Prefix or |----------------------------------------------|
| Input Interface) | Locally Connected | Tunnel0 |
+------------------------------------------------------------------+
| MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 |
+ (IPv6 Prefix or -----------------------------------------------|
| Input Interface | Locally Connected | direct |
+------------------------------------------------------------------+
Example - Policy-Based Route Table
例 - ポリシーベースのルートテーブル
+==================================================================+
| Interface | Source Address | Destination Address | Encapsulation |
+==================================================================+
| Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 |
+------------------------------------------------------------------+
| Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 |
+------------------------------------------------------------------+
Example - Tunnel Interface Table
例 - トンネルインターフェイステーブル
Authors' Addresses
著者のアドレス
Sri Gundavelli (editor) Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Sri Gundavelli（編集者）Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: sgundave@cisco.com
Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Kent Leung Cisco 170 West Tasman Drive San Jose、CA 95134 USA
EMail: kleung@cisco.com
Vijay Devarapalli Wichorus 3590 North First Street San Jose, CA 95134 USA
Vijay Devarapalli Wichorus 3590 North First Street San Jose、CA 95134 USA
EMail: vijay@wichorus.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury、MA
EMail: kchowdhury@starentnetworks.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia 6000 Connection Drive Irving、TX 75039 USA
EMail: basavaraj.patil@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。