RFC5213 日本語訳
5213 Proxy Mobile IPv6. S. Gundavelli, Ed., K. Leung, V. Devarapalli,K. Chowdhury, B. Patil. August 2008. (Format: TXT=226902 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
ワーキンググループS.Gundavelli、エドをネットワークでつないでください。コメントのために以下を要求してください。 5213年のK.レオンカテゴリ: 規格はB.パティルノキア2008年8月にコクチマスV.Devarapalli Wichorus K.チョードリStarentネットワークを追跡します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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の移動性を管理するのに責任があります。 ネットワークにおける移動性実体はホストの動きを追跡して、そのに代わって必要な移動性シグナリングを開始するのに原因となります。 この仕様は、ネットワークベースの移動性管理プロトコルについて説明して、ProxyのモバイルIPv6と呼ばれます。
Gundavelli, et al. Standards Track [Page 1] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[1ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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
1. 序論… 4 2. コンベンションと用語… 5 2.1. このドキュメントで中古のコンベンション… 5 2.2. 用語… 5 3. プロキシのモバイルIPv6は概要について議定書の中で述べます… 9 4. プロキシのモバイルIPv6はセキュリティについて議定書の中で述べます… 15 4.1. 同輩承認データベース(パッド)例のエントリー… 16 4.2. 安全保障政策データベース(SPD)例のエントリー… 17 5. 地方の移動性アンカー操作… 17 5.1. 結合への拡大はエントリーデータ構造をキャッシュします… 18 5.2. サポートしているホームネットワーク接頭語はモデル化されます… 19 5.3. シグナリング問題… 20 5.3.1. プロキシの拘束力があるアップデートを処理します… 20 5.3.2. 拘束力がある登録(新しい移動性セッション)に頭文字をつけてください。 22 5.3.3. 拘束力がある生涯拡大(移管がありません)… 23 5.3.4. 拘束力がある生涯拡大(移管の後の)… 24 5.3.5. 拘束力がある反-登録… 24 5.3.6. プロキシの拘束力がある確認メッセージを構成します… 25 5.4. マルチホーミングサポート… 27 5.4.1. キャッシュエントリールックアップ問題を縛ります… 28 5.5. メッセージ注文のためのタイムスタンプオプション… 34 5.6. ルート設定問題… 37 5.6.1. 双方向のトンネル管理… 37 5.6.2. 推進問題… 38 5.6.3. プロキシのモバイルIPv6Tunnelsのための明白な混雑通知(電子証券取引ネットワーク)問題… 39 5.7. 地方の移動性アンカーアドレス発見… 40 5.8. モバイル接頭語発見問題… 40 5.9. 最適化問題を発送してください… 41 6. モバイルアクセスゲートウェイ操作… 41 6.1. 結合への拡大はリストエントリーデータ構造をアップデートします… 42 6.2. モバイルノードの方針プロフィール… 43 6.3. サポートしているアクセスリンクはタイプされます… 44 6.4. アドレス構成モードであるとサポートされます… 44 6.5. 認証とモバイルノード識別にアクセスしてください… 45 6.6. モバイルノードの識別子を取得します… 45 6.7. ホームネットワークエミュレーション… 46 6.8. リンク地方とグローバルアドレスユニークさ… 46 6.9. シグナリング問題… 48 6.9.1. 拘束力がある登録証明書… 48 6.9.2. ルータ懇願メッセージ… 56 6.9.3. デフォルトルータ… 57 6.9.4. Retransmissionsとレート制限… 58 6.9.5. 経路MTU発見… 59 6.10. ルート設定問題… 60
Gundavelli, et al. Standards Track [Page 2] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[2ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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
6.10.1. ネットワークを輸送してください… 60 6.10.2. トンネリングとカプセル化モード… 61 6.10.3. 地方のルート設定… 62 6.10.4. 管理にトンネルを堀ってください… 62 6.10.5. 推進は統治されます… 62 6.11. DHCPベースのアドレスがアクセスでの構成であるとサポートして、リンクしてください… 64 6.12. ホームネットワーク接頭語の番号を付け替えること… 66 6.13. モバイルノード分離検出とリソースクリーンアップ… 66 6.14. ネットワークを許容して、他のIPv6にノードにアクセスしてください… 67 7. モバイルノード手術… 67 7.1. プロキシのモバイルIPv6ドメインに移行します… 67 7.2. プロキシのモバイルIPv6ドメインでは、移動します… 69 8. メッセージ形式… 69 8.1. プロキシの拘束力があるアップデートメッセージ… 69 8.2. プロキシの拘束力がある確認メッセージ… 71 8.3. ホームネットワーク接頭語オプション… 72 8.4. 移管インディケータオプション… 73 8.5. 技術タイプオプションにアクセスしてください… 74 8.6. モバイルノードリンクレイヤ識別子オプション… 76 8.7. リンクローカルアドレスオプション… 77 8.8. タイムスタンプオプション… 77 8.9. 状態値… 78 9. 構成変数について議定書の中で述べてください… 80 9.1. 地元の移動性アンカー--構成変数… 80 9.2. モバイルアクセスゲートウェイ--構成変数… 81 9.3. プロキシのモバイルIPv6ドメイン--構成変数… 82 10. IANA問題… 83 11. セキュリティ問題… 84 12. 承認… 85 13. 参照… 86 13.1. 標準の参照… 86 13.2. 有益な参照… 87 AAAインフラストラクチャとの付録のA.のプロキシのモバイルIPv6相互作用… 89 付録B.ルート設定状態… 89
Gundavelli, et al. Standards Track [Page 3] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[3ページ]RFC5213のプロキシのモバイルIPv6 August 2008
1. Introduction
1. 序論
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スタックでクライアントの機能性を必要とします。 そして、モバイルノードとホームのエージェントの間のシグナリングメッセージの交換がモバイルノードのホームアドレスの間のa結合の作成とメインテナンスを可能にする、それ、注意、-、アドレス [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移動性挑戦を解決することへの別のアプローチです。 IPv6ノードのためにホストかかわり合いなしでネットワーク・ノードとホームのエージェントの間のメッセージに合図しながらモバイルIPv6[RFC3775]を広げることによって移動性をサポートするのは可能です。 移動性をサポートすることへのこのアプローチは、モバイルノードがそれ自体とホームのエージェントの間のシグナリングメッセージの交換にかかわるのを必要としません。 ネットワークのプロキシ移動性エージェントは、ホームのエージェントと共にシグナリングを実行して、ネットワークに添付されたモバイルノードを代表して移動性管理をします。 モバイルIPv6シグナリングとホームエージェントの機能性の使用と拡大のために、このプロトコルはProxyのモバイル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の移動性、ネットワークでProxyのモバイル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はこれらの問題と要件を扱うソリューションです。
Gundavelli, et al. Standards Track [Page 4] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[4ページ]RFC5213のプロキシのモバイルIPv6 August 2008
2. Conventions and Terminology
2. コンベンションと用語
2.1. Conventions Used in This Document
2.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2.2. Terminology
2.2. 用語
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 Goalsドキュメント[RFC4831]から用語、Local Mobility Anchor(LMA)、およびモバイルAccessゲートウェイ(MAG)を採用します。 また、このドキュメントは本書では使用される次の用語まで以下の文脈特有の説明を提供します。
Proxy Mobile IPv6 Domain (PMIPv6-Domain)
プロキシのモバイルIPv6ドメイン(PMIPv6-ドメイン)
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ドメインはモバイルノードの移動性管理がこの仕様に基づき定義されるようにProxyのモバイルIPv6プロトコルを使用することで扱われるネットワークを示します。 ProxyのモバイルIPv6ドメインはセキュリティ協会を設立できて、モバイルノードを代表してProxy Binding Updatesを送るための承認を確実にすることができる地元の移動性アンカーとモバイルアクセスゲートウェイを含んでいます。
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.
地方のMobility AnchorはProxyのモバイルIPv6ドメインのモバイルノードのためのホームのエージェントです。 それは、モバイルノードのホームネットワーク接頭語(es)のための位相的なアンカー・ポイントであり、モバイルノードの拘束力がある状態を経営する実体です。 地元の移動性アンカーには、ホームのエージェントの機能的な能力が追加能力がこの仕様に基づき定義されるようにProxyのモバイルIPv6がプロトコルであるとサポートするのに必要である状態でモバイルIPv6基礎仕様[RFC3775]に基づき定義されるようにあります。
Mobile Access Gateway (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.
モバイルAccessゲートウェイはアクセスリンクに添付されるモバイルノードのために移動性関連のシグナリングを管理するアクセスルータでの機能です。 それはリンクとアクセスリンクからのモバイルノードの動きを追跡して、モバイルノードの地元の移動性アンカーに合図するのに責任があります。
Gundavelli, et al. Standards Track [Page 5] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[5ページ]RFC5213のプロキシのモバイルIPv6 August 2008
Mobile Node (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だけノード、またはデュアルスタックノードであるかもしれなく、そのProxyのモバイル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].
地元の移動性アンカーのインタフェースで構成されて、地元の移動性アンカーとモバイルアクセスゲートウェイの間で確立された両性愛者の方向のトンネルの輸送終点であるグローバルアドレス。 これはモバイルアクセスゲートウェイがProxy Binding Updateメッセージを送るアドレスです。 すなわち、地元の移動性アンカーとモバイルアクセスゲートウェイの間のネットワークがIPv4ネットワークであるときに、IPv4が縦断であるとサポートするとき、このアドレスは、IPv4アドレスであり、IPv4-LMAAと呼ばれるでしょう、[IPV4-PMIP6]で指定されるように。
Proxy Care-of Address (Proxy-CoA)
プロキシ、注意、-、アドレス(プロキシ-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].
プロキシ-CoAはモバイルアクセスゲートウェイの出口のインタフェースで構成されたグローバルアドレスであり、地元の移動性アンカーとモバイルアクセスゲートウェイの間のトンネルの輸送終点です。 地元の移動性アンカーがこのアドレスを見る、注意、-、それはそのモバイルノードのためのBinding Cacheエントリーでモバイルノードとレジスタを扱います。 そして、モバイルアクセスゲートウェイと地元の移動性アンカーの間の転送ネットワークがIPv4ネットワークである、注意、-、地元の移動性アンカーに登録されるアドレスはIPv4アドレス、IPv4というプロキシ-CoAが使用されている用語です、[IPV4-PMIP6]で指定されるように。
Mobile Node's Home Network Prefix (MN-HNP)
モバイルノードのホームネットワーク接頭語(ミネソタ-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
ミネソタ-HNPはモバイルノードとモバイルアクセスゲートウェイとのリンクに割り当てられた接頭語です。 モバイルノードとモバイルアクセスゲートウェイとのリンクに1つ以上の接頭語を割り当てることができます、その場合、セットが移動性セッションと交際したので、割り当てられた接頭語のすべてが管理されます。 モバイルノードはホームネットワーク接頭語(es)からの1つ以上のアドレスとのインタフェースを構成します。 モバイルノードが複数のインタフェースを通してProxyのモバイルIPv6ドメインに接続すると、同時にユニークなセットのホームネットワーク接頭語はそれぞれの付属インタフェースに割り当てられるでしょう、そして、モバイルノードの与えられたインタフェースに割り当てられたすべての接頭語が1つの移動性セッションで管理されるでしょう。 例えば、ホームネットワークはP1と割り当てられたP2を前に置きます。
Gundavelli, et al. Standards Track [Page 6] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[6ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
インタフェースI1は1つの移動性セッションで管理されるでしょう、そして、モバイルノードのI2を連結するように割り当てられた接頭語のP3、P4、およびP5は異なった移動性セッションで管理されるでしょう。 さらに、いくつかの構成では、割り当てられた接頭語は128ビットの接頭語の長さのものであることができます。
Mobile Node's Home Address (MN-HoA)
モバイルノードのホームアドレス(ミネソタ-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.
ミネソタ-HoAはモバイルノードのホームネットワーク接頭語からのアドレスです。 それがそのProxyのモバイルIPv6ドメインの範囲にあるアクセスネットワークに付けられている限り、モバイルノードはこのアドレスを使用できるでしょう。 モバイルノードがホームネットワーク接頭語(es)からの1つ以上のアドレスを使用するなら、これらのアドレスのいずれもモバイルノードのホームアドレスと呼ばれます。 ホームのエージェントがモバイルノードに関するホームアドレスを意識しているモバイルIPv6、ProxyのモバイルIPv6などと異なって、移動性実体は、モバイルノードのホームネットワーク接頭語(es)を意識しているだけであり、いつも、モバイルノードがインタフェースでホームネットワーク接頭語(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.
これはそのProxyのモバイルIPv6ドメインに移行した後にモバイルノードが層-3アドレス構成を付属インタフェースとして得たリンクです。 これは概念的にモバイルノードに従うリンクです。 ネットワークは、モバイルノードがいつも層-3ネットワーク・コンフィギュレーションに関してこのリンクを見るのを確実にするでしょう、それがそのProxyのモバイルIPv6ドメインで付くどんなアクセスリンクの上にも。
Multihomed Mobile Node
モバイルノードをMultihomedしました。
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.
1つ以上のインタフェースを通して同じProxyのモバイルIPv6ドメインに接続して、同時にこれらのインタフェースを使用するモバイルノードは「マルチ-家へ帰」っているモバイルノードと呼ばれます。
Mobile Node 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.
ProxyのモバイルIPv6ドメインのモバイルノードのアイデンティティ。 これはProxyのモバイルIPv6ドメインの移動性実体が予想どおりにモバイルノードを特定するのにいつも帯びて、使用できるモバイルノードの安定した識別子です。 これは、通常Network Access Identifier(NAI)[RFC4282]などの識別子かメディアAccess Control(MAC)アドレスなどの他の識別子です。
Gundavelli, et al. Standards Track [Page 7] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[7ページ]RFC5213のプロキシのモバイルIPv6 August 2008
Mobile Node Link-layer Identifier (MN-LL-Identifier)
モバイルノードリンクレイヤ識別子(Mn LL識別子)
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.
モバイルノードの付属インタフェースを特定する識別子。 リンクレイヤ識別子を持っているそれらのインタフェースに関しては、この識別子はそれに基づくことができます。 いくつかの場合、リンクレイヤ識別子は、モバイルノードによって生成されて、モバイルアクセスゲートウェイに伝えられます。 付属インタフェースのこの識別子は安定しているに違いありません、与えられたProxyモバイルIPv6ドメインのモバイルアクセスゲートウェイのどれかによって見られるように。 ある他の場合には、モバイルノードのインタフェースに関連しているどんなリンクレイヤ識別子もないかもしれません。 _ZEROの識別子値を有効な識別子であると考えないで、インタフェース識別子として使用できません。
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.
方針Profileは、与えられたモバイルノードのために構成される1セットの設定パラメータを示すための抽象名辞です。 Proxyのモバイル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)とその電流の間の結合を確立するためにモバイルアクセスゲートウェイによってモバイルノードの地元の移動性アンカーに送られた要求メッセージ、注意、-、(プロキシ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.
モバイルアクセスゲートウェイから受信したというProxy Binding Updateメッセージに対応して地元の移動性アンカーによって送られた応答メッセージ。
Per-MN-Prefix and Shared-Prefix Models
Mn接頭語、共有された接頭語モデル
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ミネソタ接頭語モデルは、ユニークなネットワーク接頭語があるアドレシングモデルか各ノードのために選任された接頭語について言及するのに使用されます。 用語Shared-接頭語モデルは、接頭語(es)が1つ以上のノードによって共有されるアドレシングモデルについて言及するのに使用されます。 この仕様は、Perミネソタ接頭語モデルをサポートして、Shared-接頭語モデルはサポートしません。
Gundavelli, et al. Standards Track [Page 8] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[8ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
Proxyのモバイル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
ゼロと非_が合っているゼロすべての_
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つのコネがあるIPv6アドレスの0に優に16バイトセットしました。 逆に、NON_ZEROという用語は、すべての_ZERO価値以外のどんな値についても言及するのに使用されます。
3. Proxy Mobile IPv6 Protocol Overview
3. プロキシのモバイルIPv6プロトコル概要
This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 [RFC3775].
この仕様はネットワークベースの移動性管理プロトコルについて説明します。 それは、Proxyのモバイル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インフラストラクチャにおけるコアの機能的な実体は、Local Mobility Anchor(LMA)とモバイルAccessゲートウェイ(MAG)です。 地元の移動性アンカーは、モバイルノードの可到達性状態を維持するのに責任があって、モバイルノードのホームネットワーク接頭語(es)のための位相的なアンカー・ポイントです。 モバイルアクセスゲートウェイはモバイルノードを代表して移動性管理を実行する実体です、そして、それはモバイルノードが据えつけられるアクセスリンクの上に住んでいます。 モバイルアクセスゲートウェイはリンクとアクセスリンクからモバイルノードの動きを検出して、モバイルノードの地元の移動性アンカーに拘束力がある登録証明書を開始するのに原因となります。 複数の地元の移動性アンカーがそれぞれモバイルノードの異なったグループに役立つProxyのモバイルIPv6ドメインにいることができます。 ProxyのモバイルIPv6ドメインのアーキテクチャは図1に示されます。
Gundavelli, et al. Standards Track [Page 9] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[9ページ]RFC5213のプロキシのモバイルIPv6 August 2008
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
LMAA1 -> | | <-- LMAA2
| |
\\ //\\
\\ // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
| | |
MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4
{MN1} {MN3}
+----+ +----+ |LMA1| |LMA2| +----+ +----+ LMAA1->。| | <-- LMAA2| | \\ //\\ \\ // \\ \\ // \\ +---\\------------- //------\\----+ (\\IPv4/IPv6 //\\)(\\ネットワーク//\\)+------\\--------//------------\\+\\//\\\\//\\\\//\\プロキシ-CoA1-->。| | <-- プロキシ-CoA2+----+ +----+ |MAG1|-----MN2|MAG2| +----+ | +----+ | | | ミネソタ-HNP1-->。| ミネソタ-HNP2| <-- ミネソタ-HNP3、ミネソタ-HNP4MN1MN3
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.
モバイルノードがProxyのモバイル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.
ネットワークが、モバイルノードがネットワークベースの移動性サービスのために認可されることを決定すると、ネットワークは、ネットワークによって受入れられたアドレス構成メカニズムのいずれも使用するモバイルノードが接続インタフェースでアドレス構成を得て、そのProxyのモバイルIPv6ドメインでどこでも移行できるのを確実にするでしょう。 得られたアドレス構成はホームネットワーク接頭語(es)(リンクの、そして、他の関連する設定パラメータに関するデフォルトルータアドレス)からのアドレス(es)を含んでいます。 それぞれのモバイルノードの見解から、全体のProxyモバイルIPv6ドメインは単一のリンクとして見えて、ネットワークは、ネットワークで接着点を変えた後にさえモバイルノードが層-3付属に関して少しの変化も検出しないのを確実にします。
Gundavelli, et al. Standards Track [Page 10] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[10ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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アドレスを入手して、そのProxyのモバイル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.
モバイルノードが複数のインタフェースを通して複数のアクセスネットワークの上でProxyのモバイルIPv6ドメインに接続すると、ネットワークはユニークなセットのホームネットワーク接頭語をそれぞれの接続インタフェースに割り当てるでしょう。 モバイルノードはそれぞれのホームネットワーク接頭語(es)からそれらのインタフェースに関するアドレス(es)を構成できるでしょう。 しかしながら、モバイルノードが1つのインタフェースからもう片方までアドレス構成を動かすことによって移管を実行して、地元の移動性アンカーが給仕モバイルアクセスゲートウェイから移管ヒントをほぼ同じくらい受けると、地元の移動性アンカーはそれが移管の前に以前に割り当てたのと同じホームネットワーク接頭語(es)を割り当てるでしょう。 モバイルノードは、また、異なったモバイルアクセスゲートウェイへの1モバイルアクセス門から同じインタフェースを使用することで接着点を変えることによって移管を実行できて、付属インタフェースでアドレス構成を保有できるでしょう。
Gundavelli, et al. Standards Track [Page 11] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[11ページ]RFC5213のプロキシのモバイルIPv6 August 2008
+-----+ +-----+ +-----+
| 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 | |
| | |
+-----+ +-----+ +-----+ | ミネソタ| | 雑誌| | LMA| +-----+ +-----+ +-----+ | | | 添付のミネソタ| | | | | | ミネソタはミネソタ/ネットワークからイベントを付けました。| | (ミネソタ-イドとプロフィールを入手します) | | | | |--- Rtrソ--------->|、|、|、|、|、| |--- PBU------------->|、|、|、|、|、| PBUを受け入れてください。| | (ミネソタ-HNP(s)を割り当ててください、そして、BCEをセットアップしてください、そして、トンネルを堀ってください) | | | | | <、-、-、-、-、-、-、-、-、-、-、-、-- PBA---| | | | | PBAを受け入れてください。| | (トンネルとルート設定を設立します) | | | | | |==== 両性愛者のディルトンネル===| | | | | <、-、-、-、-、-、-、-、-- Rtr Adv---| | | | | IPアドレス| | 構成| | | | |
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は、モバイルノードがいつProxyのモバイルIPv6ドメインに入るかをシグナリング呼び出し流動に示します。 モバイルノードからのRouter Solicitationメッセージは、モバイルノードの付属の後にいつでも、到着するかもしれなくて、呼び出し流動における他のメッセージと共にどんな厳しい注文関係も持っていません。
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.
モバイルノードの現在の位置に関して地元の移動性アンカーをアップデートするために、モバイルアクセスゲートウェイはモバイルノードの地元の移動性アンカーにProxy Binding Updateメッセージを送ります。 このProxy Binding Updateメッセージを受け入れると、地元の移動性アンカーはモバイルノードのホームネットワーク接頭語(es)を含むProxy Binding Acknowledgementメッセージを送ります。 それは、モバイルアクセスゲートウェイにまた、Binding Cacheエントリーを作成して、双方向のトンネルの終点をセットアップします。
Gundavelli, et al. Standards Track [Page 12] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[12ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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).
Proxy Binding Acknowledgementメッセージを受け取るときのモバイルアクセスゲートウェイは、地元の移動性アンカーに双方向のトンネルの終点をセットアップして、また、モバイルノードのトラフィックのために推進をセットアップします。 ここに、モバイルアクセスゲートウェイで、モバイルノードのホームを見習うためのすべての必須情報がリンクされます。 それはモバイルノードのアクセスリンク広告ホームネットワーク接頭語(es)のときにリンクの上の接待された接頭語(es)としてモバイルノードへのメッセージをRouter Advertisementに送ります。
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).
アクセスリンクに関するこれらのRouter Advertisementメッセージを受け取るとき、モバイルノードは、statefulか状態がないアドレス構成モードのどちらかを使用することでインタフェースを構成するのを試みます、Router Advertisementメッセージにみられるようにそのアクセスリンクの上に受入れられるモードに基づいて。 うまくいっているアドレス構成手順の終わりでは、モバイルノードはホームネットワーク接頭語(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つ以上の有効なアドレスを持っています。 また、給仕モバイルアクセスゲートウェイと地元の移動性アンカーには、トラフィックがいくらか1つを使用するモバイルノードからノードと、そして、送った取り扱いのための適切なルーティング州かホームネットワーク接頭語(es)からの一層のアドレスがあります。
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)のための位相的なアンカー・ポイントであり地元の移動性アンカーはどんなノードによってもモバイルノードに送られるどんなパケットもドメイン、または、Proxyのモバイル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を参照してください)。
Gundavelli, et al. Standards Track [Page 13] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[13ページ]RFC5213のプロキシのモバイルIPv6 August 2008
+-----+ +-----+ +-----+ +-----+
| 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)
| | | |
+-----+ +-----+ +-----+ +-----+ | ミネソタ| |p-雑誌| | LMA| |n-雑誌| +-----+ +-----+ +-----+ +-----+ | | | | | |==両性愛者のディルトンネル=| | 取り外されたミネソタ| | | | ミネソタはイベントを取り外しました。| | | | | | | |-- DeReg PBU-->|、|、|、|、|、|、|、| PBUを受け入れてください。| | | (スタートMinDelayBeforeBCEDeleteタイマ) | | | | | | <、-、-、-、-、-、-、-- PBA--| | | | | | 添付のミネソタ| | | | | | ミネソタAttachedイベントは受信されました。| | | ミネソタかネットワーク| | | (ミネソタ-イドとプロフィールを入手します) | | | | |--- Rtrソ------------------------------------->| .... 登録は図2のように踏まれます。 .... | | |==両性愛者のディルトンネル=| | | | | |<------------------------------------ Rtr Adv----| | | | | ミネソタは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
モバイルノードが接着点を変えるならProxyのモバイルIPv6ドメインで初期のアドレス構成を得た後に、前のリンクの上のモバイルアクセスゲートウェイはリンクからモバイルノードの分離を検出するでしょう。 それは、地元の移動性アンカーに合図して、そのモバイルノードのために結合とルーティング状態を取り除くでしょう。 この要求を受け取るとき、地元の移動性アンカーは要求がそうであった対応する移動性セッションを特定するでしょう。
Gundavelli, et al. Standards Track [Page 14] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[14ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
それが新しいリンクの上のモバイルアクセスゲートウェイを許容するある時間結合をアップデートするのを待つ要求を受け取って、受け入れます。 しかしながら、与えられた時間中にどんなProxy Binding Updateメッセージも受け取らないと、それは拘束力があるキャッシュエントリーを削除するでしょう。
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)を含むRouter Advertisementsを送るでしょう、そして、これはモバイルノードがインタフェースの層-3付属に関して少しの変化も検出しないのを確実にするでしょう。
4. Proxy Mobile IPv6 Protocol Security
4. プロキシのモバイルIPv6プロトコルセキュリティ
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.
発生源認証を保全とデータに提供しながら終わりから終わりへのセキュリティ協会を使用して、モバイルアクセスゲートウェイと地元の移動性アンカーの間で交換されたシグナリングメッセージ、Proxy Binding Update、およびProxy Binding Acknowledgementを保護しなければなりません。
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.
モバイルアクセスゲートウェイと地元の移動性アンカーは、ProxyのモバイルIPv6シグナリングメッセージ[RFC4301]を保護するためにIPsecを実装しなければなりません。 IPsecは実装するために義務的なセキュリティー対策です。 しかしながら、追加ドキュメントは代替のメカニズムを指定するかもしれません、そして、移動性実体はProxyのモバイル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.
義務的な保全保護SHOULDがシグナリングメッセージを保護するのに使用されている交通機関によるIPsec Encapsulating Security有効搭載量(超能力)[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.
[というRFC4303] トンネルモードが使用されているかもしれないコネがモバイルノードのものを保護する超能力のトンネルを堀られたデータがデータ通信量の保護がそうなら取引するIPsecが必要です。
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]SHOULD、使用されて、モバイルアクセスゲートウェイと地元の移動性アンカーとのセキュリティ仲間をセットアップして、Proxy Binding UpdateとProxy Binding Acknowledgementメッセージを保護してください。 モバイルアクセスゲートウェイと地元の移動性アンカーは認証機構のどれかを使用できます、[RFC4306]で指定されるように、互いの認証のために。
Gundavelli, et al. Standards Track [Page 15] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[15ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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]は、ホームのエージェントが、モバイルノードが別のモバイルノードのホームアドレスのためにセキュリティ協会を創設するか、または拘束力があるキャッシュエントリーを作成するのを防ぐのを必要とします。 本書では説明されたプロトコルでは、モバイルノードはシグナリングメッセージを保護するか、または拘束力があるアップデートを送るためにセキュリティ協会を創設するのにかかわりません。 したがって、地元の移動性アンカーはプロキシ結合の作成と操作を明確に認可されたモバイルアクセスゲートウェイと接頭語に制限しなければなりません。 地元の移動性アンカーはそのような特定の組み合わせを認可するのにおいて局所的に構成可能でなければなりません。 方針店やAuthenticationや、Authorizationや、Accountingなどの追加メカニズム(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]などと異なって、これらのシグナリングメッセージがホームAddress目的地オプションかType2ルート設定ヘッダーのどちらかを運ばないで、したがって、方針エントリーとセキュリティ協会セレクタは、同じ状態で滞在していて、どんな特別なIPsec関連する問題も必要としません。
4.1. Peer Authorization Database (PAD) Example Entries
4.1. 同輩承認データベース(パッド)例のエントリー
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.
このセクションはモバイルアクセスゲートウェイと地元の移動性アンカーの上でPADエントリー[RFC4301]について説明します。 PADエントリーは例の構成にすぎません。 PADが論理的な概念であり、特定のモバイルアクセスゲートウェイか地方の移動性アンカー実装がどんな実装特有の方法でもPADを実装することができることに注意してください。 また、PAD状態は特定の実装における様々なデータベースの向こう側に分配されるかもしれません。
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_アイデンティティ_1であると思われます、そして、モバイルアクセスゲートウェイのアイデンティティは雑誌_アイデンティティ_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
モバイルアクセスゲートウェイPAD: - _リモート_のアイデンティティがlma_アイデンティティと等しいなら、1Thenがリモートアドレスlma_アドレス_1のためにCHILD_SAsを認証して(共有秘密キー/証明書/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
地方の移動性アンカーPAD: - _リモート_のアイデンティティが雑誌_アイデンティティと等しいなら、1Thenがリモートアドレス雑誌_アドレス_1のためにCHILD_SAsを認証して(共有秘密キー/証明書/EAP)、認可します。
Figure 4: PAD Entries
図4: パッドエントリー
Gundavelli, et al. Standards Track [Page 16] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[16ページ]RFC5213のプロキシのモバイルIPv6 August 2008
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
上記の例の認証機構のリストは徹底的ではありません。 PADに保存された認証に使用される他の資格証明書があるかもしれません。
4.2. Security Policy Database (SPD) Example Entries
4.2. 安全保障政策データベース(SPD)例のエントリー
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]について説明します、そして、地元の移動性アンカーがProxyのモバイル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.
以下の例では、モバイルアクセスゲートウェイのアイデンティティは_1、モバイルアクセスゲートウェイのアドレスが雑誌_アドレス_1であると思われて、地元の移動性アンカーのアドレスがlma_アドレス_1であると思われる雑誌_アイデンティティであると思われます。 頭文字語MHはMobility Header[RFC3775]のプロトコル番号を表します、mh_タイプという用語のローカルの_mh_タイプとリモート_はそれぞれローカルの移動性ヘッダータイプとリモート移動性ヘッダータイプを表しますが。
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
モバイルアクセスゲートウェイSPD-S: - ローカルの_アドレスが雑誌_アドレス_1と等しく、リモート_アドレスがlma_アドレス_1と等しく、protoがMHと等しく、(ローカルの_mh_タイプはBUと等しいです| リモート_mh_タイプ=BA)なら、lmaが_アドレス_1であると扱うのに雑誌IDi=_アイデンティティ_1を使用することでSA ESP交通機関Initiateを使用してください。
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
地方の移動性アンカーSPD-S: - ローカルの_アドレスがlma_アドレス_1と等しく、リモート_アドレスが雑誌_アドレス_1と等しく、protoがMHと等しく、(ローカルの_mh_タイプはBAと等しいです| リモート_mh_タイプ=BU)なら、SA ESP交通機関を使用してください。
Figure 5: SPD Entries
図5: SPDエントリー
5. Local Mobility Anchor Operation
5. 地方の移動性アンカー操作
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]とこの仕様に基づき定義された拡大で定義されるようにホームエージェント機能をサポートしなければなりません。 ProxyのモバイルIPv6プロトコルをサポートするためのこれらの変更と高められた能力があるホームのエージェントは地元の移動性アンカーと呼ばれます。
This section describes the operational details of the local mobility anchor.
このセクションは地元の移動性アンカーの操作上の細部について説明します。
Gundavelli, et al. Standards Track [Page 17] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[17ページ]RFC5213のプロキシのモバイルIPv6 August 2008
5.1. Extensions to Binding Cache Entry Data Structure
5.1. 拘束力があるキャッシュエントリーデータ構造への拡大
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].
すべての地元の移動性アンカーがそれぞれの現在登録されたモバイルノードのためのBinding Cacheエントリーを維持しなければなりません。 Binding Cacheエントリーは[RFC3775]のセクション9.1で説明された概念的なデータ構造です。
For supporting this specification, the Binding Cache Entry data structure needs to be extended with the following additional fields.
この仕様をサポートするために、Binding Cache Entryデータ構造は、以下の追加分野で広げられる必要があります。
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 このBinding Cacheエントリーがプロキシ登録のため作成されるかどうかを示す旗。 この旗は、プロキシ登録証明書であるBinding Cacheエントリーに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 登録されたモバイルノードに関する識別子、ミネソタ-識別子。 受信されたProxy Binding Updateメッセージの現在のモバイルNode Identifier Option[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 アクセスリンクの上のモバイルノードの接続インタフェースに関するリンクレイヤ識別子。 この識別子は、モバイルNode Link-層のIdentifierオプションによって後天的であって、受信されたProxy Binding Updateメッセージに存在している場合があります。 オプションが要求に存在していなかったなら、この可変長フィールドを2(八重奏)に設定しなければならなくて、_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 ポイントへのポイントリンクの上のモバイルアクセスゲートウェイのリンクローカルアドレスはモバイルノードと共有されました。 初期のProxy Binding Updateメッセージを受け入れた後に、これは地元の移動性アンカーによって生成されます。
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 モバイルノードが現在据えつけられる地元の移動性アンカーとモバイルアクセスゲートウェイの間の両性愛者の方向のトンネルに関するトンネルインタフェース識別子(イドであるなら、トンネルを堀ってください)。 地元の移動性アンカーにとって、これは内部です。 トンネル作成の間、トンネルインタフェース識別子を取得します。
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 アクセス技術タイプ。(モバイルノードは現在、そのタイプによって添付されます)。 これは、Access Technology Typeオプションから得て、Proxy Binding Updateメッセージに存在しています。
Gundavelli, et al. Standards Track [Page 18] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[18ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 最も最近受け入れられたProxy Binding Updateメッセージの64ビットのタイムスタンプ値はこのモバイルノードを注文しました。 メッセージを受け取ったとき、これは地元の移動性アンカーの上の時刻です。 TimestampオプションがProxy Binding Updateメッセージに存在していないなら(すなわち、系列番号ベースの体系はいつ使用中ですか)、_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.
通常、移動性セッションからのモバイルノードのホームネットワーク接頭語のどれかはモバイルノードのセッションの移管があった時以外のすべての場合におけるBinding Cacheエントリーの新しいモバイルアクセスゲートウェイに場所を見つけるのにキーとして使用されるかもしれません、そして、モバイルがゲートウェイにアクセスするのは、その移動性セッションまで割り当てられたホームネットワーク接頭語(es)に気づきません。 そのような移管場合では、Binding Cacheエントリーはセクション5.4.1で指定された問題の下で位置できます。
5.2. Supported Home Network Prefix Models
5.2. ホームネットワーク接頭語モデルであるとサポートされます。
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ミネソタ接頭語モデルをサポートして、Shared-接頭語モデルはサポートしません。 Perミネソタ接頭語によると、モデル、モバイルノードに割り当てられたホームネットワーク接頭語(es)はそのモバイルノードの専用のためのものです、そして、他のどんなノードもその接頭語(そのリンクの上にその接頭語をホスティングするモバイルアクセスゲートウェイによって使用されるSubnet-ルータ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つ以上の接頭語があるかもしれません。 接頭語が割り当てられたそれらのすべてがそのモバイルノードにユニークであるに違いありません、そして、すべてがまさに1つの移動性セッションの一部です。 モバイルノードが同時に複数のインタフェースを通してProxyのモバイル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ディスカバリー(ノースダコタ)操作[RFC4861]も実行する必要はありません、接頭語が地元の移動性アンカーの上で局所的にホスティングされないとき。 しかしながら、ルーティング見解から、ホームネットワーク接頭語(es)は地元の移動性アンカーに位相的に据えつけられます。
Gundavelli, et al. Standards Track [Page 19] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[19ページ]RFC5213のプロキシのモバイルIPv6 August 2008
5.3. Signaling Considerations
5.3. シグナリング問題
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.
このセクションはシグナリングメッセージを処理のための規則に提供します。 このセクションと他の関連するセクションで指定された処理規則は、チェーニングされて、特定のオーダーにあります。 シグナリングメッセージを処理するためにこれらの問題を適用するとき、指定されたオーダーを維持しなければなりません。
5.3.1. Processing Proxy Binding Updates
5.3.1. プロキシの拘束力があるアップデートを処理します。
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. セクション4で説明されて、((P)旗が1の値、セクション8.1で指定された形式にセットしたことでのBinding Updateメッセージ)を認証しなければならない受信されたProxy Binding Updateメッセージ。 IPsecが通報認証に使用されるとき、容認されたパケットのIPsecヘッダー[RFC4306]のSecurity Parameter Index(SPI)がセキュリティ協会の場所を見つけるのに必要です、Proxy Binding Updateメッセージを認証するために。
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. 地元の移動性アンカーは受信されたProxy Binding UpdateメッセージでMobility Headerを処理するとき[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. 地元の移動性アンカーはProxy Binding UpdateメッセージでのホームAddress目的地オプションの存在に関連する.1セクション10.3[RFC3775]で指定されたチェックを無視しなければなりません。
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. 地元の移動性アンカーはProxy Binding UpdateメッセージのモバイルNode Identifierオプション[RFC4283]における現在の識別子からのモバイルノードを特定しなければなりません。 モバイルNode IdentifierオプションがProxy Binding Updateメッセージに存在していないなら、地元の移動性アンカーは、Status分野セットで_MISSING_ミネソタIDENTIFIER_OPTION(なくなったモバイルNode Identifierオプション)に要求を拒絶して、Proxy Binding Acknowledgementメッセージを送らなければなりません、そして、メッセージで運ばれたモバイルNode Identifierオプションにおける識別子をゼロ・レングス識別子に設定しなければなりません。
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. 地元の移動性アンカーは必要な方針チェックを適用しなければなりません、送付者がこのモバイルノードを代表してメッセージをProxy Binding Updateに送るのが認可された信じられたモバイルアクセスゲートウェイであることを確かめるためにセクション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. 地元の移動性アンカーが、要求ノードが特定されたモバイルノードへのメッセージをProxy Binding Updateに送るのが認可されないと決心しているなら、それは、要求を拒絶して、__どんなAUTHORIZED_FOR_PROXY_REG(拘束力があるアップデートをプロキシに送るのは認可されない)もMAGへのStatus分野セットがあるProxy Binding Acknowledgementメッセージに送ってはいけません。
Gundavelli, et al. Standards Track [Page 20] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[20ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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. 地元の移動性アンカーがProxy Binding UpdateメッセージのモバイルNode Identifierオプション[RFC4283]における現在の識別子に基づくモバイルノードを特定できないなら、それは、Status分野セットで_どんな_の_のモバイル_LMA_FOR THIS NODE(このモバイルノードのための地元の移動性アンカーでない)にも要求を拒絶して、Proxy Binding Acknowledgementメッセージを送ってはいけません。
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. 地元の移動性アンカーが、モバイルノードがネットワークベースの移動性経営指導のために認可されないと決心しているなら、それは、Status分野セットで_ENABLED(Registrationが可能にしなかったプロキシ)ではなく、PROXY_レッジ_に要求を拒絶して、Proxy Binding Acknowledgementメッセージを送らなければなりません。
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. 地元の移動性アンカーはProxy Binding UpdateメッセージのSequence Number分野とTimestampオプションを処理するのにセクション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. Proxy Binding Updateメッセージの現在のどんなホームNetwork Prefixオプション(どんな値があるも)もなければ、地元の移動性アンカーは、Status分野セットでMISSING_ホーム_NETWORK_PREFIX_OPTION(なくなったホームNetwork Prefixオプション)に要求を拒絶して、Proxy Binding Acknowledgementメッセージを送らなければなりません。
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. Handoff IndicatorオプションがProxy Binding Updateメッセージに存在していないなら、地元の移動性アンカーは、Status分野セットでMISSING_HANDOFF_INDICATOR_OPTION(なくなったHandoff Indicatorオプション)に要求を拒絶して、Proxy Binding Acknowledgementメッセージを送らなければなりません。
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. Access Technology TypeオプションがProxy Binding Updateメッセージに存在していないなら、地元の移動性アンカーは、Status分野セットでMISSING_ACCESS_TECH_TYPE_OPTION(なくなったAccess Technology Typeオプション)に要求を拒絶して、Proxy Binding Acknowledgementメッセージを送らなければなりません。
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. Binding Cacheエントリー存在テストを実行して、セクション5.4.1で指定された問題に申し込まなければなりません。 それらのチェックがセクション5.4.1結果で交際するのにおいて指定したなら、新しい移動性セッション作成要求への受信されたProxy Binding Updateメッセージ(セクション5.3.2(初期のBinding Registration--新しいMobility Session)からの問題)を適用しなければなりません。 それらのチェックが既存の移動性セッションまで要求を関連づけるのに結果として生じるなら、以下のチェックは適用される必要がある処理規則の次のセットを決定します。
Gundavelli, et al. Standards Track [Page 21] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[21ページ]RFC5213のプロキシのモバイルIPv6 August 2008
* 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.
* 受信されたProxy Binding Updateメッセージにゼロの生涯値があるなら、セクション5.3.5(拘束力があるDe登録)からの問題を適用しなければなりません。
* 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.
* Binding CacheエントリーにおけるProxy-CoAが要求のソースアドレスに合っている、(中のアドレス、Alternate Care、-、Addressオプション、オプションが存在しているならセクション5.3.3(拘束力があるLIfetime Extension--移管がない)からの問題を適用しなければなりません。
* For all other cases, considerations from Section 5.3.4
(Binding Lifetime Extension - After handoff) MUST be applied.
* 他のすべてのケースにおいて、セクション5.3.4(移管の後の拘束力があるLifetime Extension)からの問題を適用しなければなりません。
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. どんなStatus分野価値、メッセージがあるProxy Binding Acknowledgementメッセージも送るのが組み立てなければならないとき、セクション5.3.6で指定されるように、組み立てられてください。
5.3.2. Initial Binding Registration (New Mobility Session)
5.3.2. 初期の拘束力がある登録(新しい移動性セッション)
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. Proxy Binding Updateメッセージの_ZEROへの接頭語選択値群について現在のホームNetwork Prefixオプションの少なくとも1つのインスタンスがあれば、地元の移動性アンカーは、1つ以上のホームネットワーク接頭語をモバイルノードに割り当てて、モバイルノードのために作成された新しい移動性セッションまでそれを割り当てなければなりません。 地元の移動性アンカーは割り当てられた接頭語(es)が確実にいかなる他のノードか移動性セッションでも使用中にならないようにしなければなりません。 いくつの接頭語を付属インタフェースに割り当てるかに関する決定はそのモバイルノードに特定のグローバルな方針か方針に基づくことができます。 しかしながら、DHCPを使用するstatefulアドレス自動構成がリンクの上にサポートされるとき、接頭語課題のためにセクション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. 地元の移動性アンカーがモバイルノードのためにどんなホームネットワーク接頭語も割り当てることができないなら、それは、Status分野セットで130(不十分なリソース)に要求を拒絶して、Proxy Binding Acknowledgementメッセージを送らなければなりません。
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
3. Proxy Binding Updateメッセージ(NON_ZERO値に設定されたそれぞれの接頭語がある)の現在の1つ以上のホームNetwork Prefixオプションがあれば、その要求を受け入れる前に、地元の移動性アンカーは、モバイルノードが地元の移動性アンカーと、一層ですが、これらの接頭語を使用するのが認可されて、それらの接頭語の各々が所有されているのを保証しなければなりません。 モバイルノードがいくらか1つかそれらの接頭語の以上を使用するのが認可されないなら、地元の移動性アンカーは、要求を拒絶して、Proxy Bindingを送らなければなりません。
Gundavelli, et al. Standards Track [Page 22] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[22ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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).
Status分野がある確認メッセージは_どんな_AUTHORIZED_FOR_ホームNETWORK_PREFIXにもセットしませんでした(モバイルノードは要求ホームネットワークの1つ以上のために接頭語を認可しませんでした)。
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. 要請を受け入れると、地元の移動性アンカーはモバイルノードのためのBinding Cacheエントリーを作成しなければなりません。 それはその登録のために受け入れられた値へのBinding Cacheエントリーに分野をはめ込まなければなりません。
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. 地元の移動性アンカーはStatus分野セットがあるProxy Binding Acknowledgementメッセージを0(プロキシBinding Update Accepted)に送らなければなりません。 指定されるとしてセクション5.3.6でメッセージを構成しなければなりません。
5.3.3. Binding Lifetime Extension (No Handoff)
5.3.3. 拘束力がある生涯拡大(移管がありません)
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. 結合をアップデートしたのと同じモバイルアクセスゲートウェイ(Binding CacheエントリーにおけるProxy-CoAが要求でProxy-CoAと同じであるなら)から得られた拘束力がある生涯を広げることへのProxy Binding Updateメッセージを受け入れると、地元の移動性アンカーは受け入れられた登録値でBinding Cacheエントリーをアップデートしなければなりません。
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. 地元の移動性アンカーはStatus分野セットがあるProxy Binding Acknowledgementメッセージを0(プロキシBinding Update Accepted)に送らなければなりません。 指定されるとしてセクション5.3.6でメッセージを構成しなければなりません。
Gundavelli, et al. Standards Track [Page 23] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[23ページ]RFC5213のプロキシのモバイルIPv6 August 2008
5.3.4. Binding Lifetime Extension (After Handoff)
5.3.4. 拘束力がある生涯拡大(移管の後の)
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. モバイルノードの移動性セッションが渡されるところで新しいモバイルアクセスゲートウェイ(Binding CacheエントリーにおけるProxy-CoAが要求でProxy-CoAに合っていないなら)から得られた拘束力がある生涯を広げることへのProxy Binding Updateメッセージを受け入れると、地元の移動性アンカーは受け入れられた登録値でBinding Cacheエントリーをアップデートしなければなりません。
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)のために以前に作成されたルートを取り外さなければなりません。 何か他のものがいなければ、さらに、ダイナミックに双方向で作成されているのを共有するモバイルノードが前のモバイルアクセスゲートウェイにトンネルを堀ります、トンネルSHOULD。削除されてください、セクション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. 地元の移動性アンカーはStatus分野セットがあるProxy Binding Acknowledgementメッセージを0(プロキシBinding Update Accepted)に送らなければなりません。 指定されるとしてセクション5.3.6でメッセージを構成しなければなりません。
5.3.5. Binding De-Registration
5.3.5. 拘束力がある反-登録
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 Binding UpdateがIPv6ヘッダーにゼロの生涯値で通信して、Source Addressを持っている、(中のアドレス、Alternate Care、-、Addressオプション、オプションがBinding CacheエントリーにおけるProxy-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
2. 地元の移動性アンカーがゼロの生涯値で待たなければならないProxy Binding Updateメッセージをそれの前の時間のMinDelayBeforeBCEDeleteが削除する受け入れること。
Gundavelli, et al. Standards Track [Page 24] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[24ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
Cacheエントリーを縛ります。 しかしながら、それはStatus分野セットがあるProxy Binding Acknowledgementメッセージを0(プロキシBinding Update Accepted)に送らなければなりません。 指定されるとしてセクション5.3.6でメッセージを構成しなければなりません。
* During this wait period, the local mobility anchor SHOULD drop
the mobile node's data traffic.
* この待ちの期間、地方の移動性アンカーSHOULDはモバイルノードのデータ通信量を下げます。
* 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.
* この待ちの期間、地元の移動性アンカーがゼロ以上の生涯値との同じ移動性セッションへの有効なProxy Binding Updateメッセージを受け取って、その要求を受け入れるなら、Binding Cacheエントリーを削除してはいけませんが、新たに受け入れられた登録値でアップデートしなければなりません、そして、待ちの期間を終わらせるべきです。
* 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.
* この待ちの期間の終わりまでには、地元の移動性アンカーがこの移動性セッションへのどんな有効なProxy Binding Updateメッセージも受け取らなかったなら、それは、Binding Cacheエントリーを削除して、その移動性セッションのために創設されたルーティング状態を取り除かなければなりません。 地元の移動性アンカーは潜在的に、この移動性セッションに関連している接頭語(es)を他のモバイルノードに再選任できます。
5.3.6. Constructing the Proxy Binding Acknowledgement Message
5.3.6. プロキシの拘束力がある確認メッセージを構成します。
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 Proxy Binding Acknowledgementメッセージをモバイルアクセスゲートウェイに送るとき、地元の移動性アンカーは以下で指定されるとしてメッセージを構成しなければなりません。
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)
IPv6ヘッダー(src=LMAA、dstはプロキシ-CoAと等しい)移動性ヘッダー--評価してくださいP旗を設定しなければならない1*/移動性OptionsのBA/*--モバイルNode Identifierオプション(義務的な)--ホームNetwork Prefixオプション(義務的な)--移管Indicatorオプション(義務的な)--アクセスTechnology Typeオプション(義務的な)--タイムスタンプオプション(任意の)--モバイルNode Link-層のIdentifierオプション(任意の)--リンクローカルのAddressオプション(任意)です。
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 受信されたProxy Binding Updateメッセージの送付先アドレスにメッセージのIPv6ヘッダーのSource Address分野を設定しなければなりません。
Gundavelli, et al. Standards Track [Page 25] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[25ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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ヘッダーのDestination Address分野を受信されたProxy Binding Updateメッセージのソースアドレスに設定しなければなりません。 そこの時がノーである、Alternate Care、-、要求の現在のAddressオプション、送付先アドレスはProxy-CoAと同じです。 さもなければ、アドレスはProxy-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 モバイルNode Identifierオプション[RFC4283]は存在していなければなりません。 受信されたProxy Binding UpdateメッセージにおけるモバイルNode Identifierオプションからオプションにおける識別子分野をコピーしなければなりません。 オプションが要求に存在していなかったなら、ゼロ・レングス識別子にオプションにおける識別子を設定しなければなりません。
o At least one Home Network Prefix option MUST be present.
o 少なくとも1つのホームNetwork Prefixオプションが存在していなければなりません。
* 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.
* すなわち、Proxy Binding Updateが拒絶されるならStatus分野が値より多くの128に設定されるなら、すべての要求(それらの接頭語値に伴う)に存在しているホームNetwork Prefixオプションが回答で存在していなければなりません。 しかし、要求の現在のどんなホームNetwork Prefixオプションもなかったなら、_ZEROに設定されたオプションには値がある1つのホームNetwork Prefixオプションしかないに違いありません。
* 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.
* 他のすべてのケースのために、割り当てられた接頭語値に設定されたオプションにはそれぞれの割り当てられたホームネットワーク接頭語(その移動性セッションのための)、および接頭語値があるホームNetwork Prefixオプションがあるに違いありません。
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 Handoff Indicatorオプションは存在していなければなりません。 受信されたProxy Binding UpdateメッセージにおけるHandoff Indicatorオプションからオプションにおける移管インディケータ分野をコピーしなければなりません。 オプションが要求に存在していなかったなら、オプションにおける値をゼロに設定しなければなりません。
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 Access Technology Typeオプションは存在していなければなりません。 受信されたProxy Binding UpdateメッセージにおけるAccess Technology Typeオプションからオプションにおけるアクセス技術タイプ分野をコピーしなければなりません。 オプションが要求に存在していなかったなら、オプションにおける値をゼロに設定しなければなりません。
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 受信されたProxy Binding Updateメッセージに存在していて、そうでなければ、同じオプションが存在しているはずがない場合にだけ、Timestampオプションは存在していなければなりません。 Timestampオプションを構成しながら、セクション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
o 受信されたProxy Binding Updateメッセージに存在していて、そうでなければ、同じオプションが存在しているはずがない場合にだけ、モバイルNode Link-層のIdentifierオプションは存在していなければなりません。 リンクレイヤ
Gundavelli, et al. Standards Track [Page 26] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[26ページ]RFC5213のプロキシのモバイルIPv6 August 2008
identifier value MUST be copied from the Mobile Node Link-layer
Identifier option present in the received Proxy Binding Update
message.
受信されたProxy Binding Updateメッセージの現在のモバイルNode Link-層の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 受信されたProxy Binding Updateメッセージに存在していて、そうでなければ、同じオプションが存在しているはずがない場合にだけ、LinkローカルのAddressオプションは存在していなければなりません。 すなわち、Proxy Binding Updateが拒絶されるなら回答におけるStatus分野が値より多くの128に設定されるなら、回答におけるLinkローカルのAddressオプションに要求からのリンクローカルアドレスをコピーしなければなりません。さもなければ、以下の問題は適用されます。
* 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.
* 受信されたProxy Binding Updateメッセージですべての_ZERO価値があるLinkローカルのAddressオプションがあって、この要求に関連している既存のBinding Cacheエントリーがあれば、回答におけるLinkローカルのAddressオプションにBinding Cacheエントリーからのリンクローカルアドレスをコピーしなければなりません。
* 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.
* 受信されたProxy Binding Updateメッセージですべての_ZERO価値があるLinkローカルのAddressオプションがあって、Binding Cacheエントリーがこの要求に関連づけた存在がなければ、地元の移動性アンカーはモバイルアクセスゲートウェイがモバイルノードと共有されたポイントツーポイント接続の上で使用できるリンクローカルアドレスを生成しなければなりません。 回答におけるLinkローカルのAddressオプションにこの生成アドレスをコピーしなければなりません。 また、この移動性セッションのために作成されたBinding Cacheエントリーのリンクローカルアドレス分野に同じアドレスをコピーしなければなりません。
* 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).
* 受信されたProxy Binding UpdateメッセージにNON_ZERO値があるLinkローカルのAddressオプションがあるなら、回答におけるLinkローカルのAddressオプションに要求からのリンクローカルアドレスをコピーしなければなりません。 また、この要求(1つが存在していないならBinding Cacheエントリーを作成した後の)に関連しているBinding Cacheエントリーのリンクローカルアドレス分野に同じアドレスをコピーしなければなりません。
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]などと異なって、Type2ルート設定ヘッダーはパケットのIPv6ヘッダーに出席しているはずがありません。
5.4. Multihoming Support
5.4. マルチホーミングサポート
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.
この仕様で、モバイルノードは同時アクセスのために複数のインタフェースを通してProxyのモバイルIPv6ドメインに接続できます。 ↓これはこのマルチホーミングサポートの特徴です。
Gundavelli, et al. Standards Track [Page 27] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[27ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 モバイルノードが同時アクセスのために複数のインタフェースを通してProxyのモバイルIPv6ドメインに接続するとき、地元の移動性アンカーはそれぞれの付属インタフェースのための移動性セッションを割り当てなければなりません。 それぞれの移動性セッションは別々のBinding Cacheエントリーとそれ自身の生涯で管理されるべきです。
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つ以上のホームネットワーク接頭語を割り当てるかもしれません。 しかしながら、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つの移動性セッションの一部)に関連しているすべてのホームネットワーク接頭語がモバイルノードの異なったインタフェースに関連するでしょう。 いつ新しい移動性セッションを作成するか、そして、いつ既存の移動性セッションをアップデートするかに関する決定をProxy Binding Updateメッセージと、そして、このセクションで指定された問題の下における現在のHandoverヒントに基礎づけなければなりません。
5.4.1. Binding Cache Entry Lookup Considerations
5.4.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.
与えられたモバイルノードのための複数のBinding Cacheエントリーがあることができます。 処理のためのモバイルノードのBinding Cacheエントリーへのルックアップに受信されたProxy Binding Updateメッセージをするとき、地元の移動性アンカーは以下のマルチホーミング問題を適用しなければなりません(指定された以下では、セクション5.4.1から始まって、.1が注文されています)。 処理規則がセクション5.3で指定されている状態で、これらの規則はチェーニングされます。
5.4.1.1. Home Network Prefix Option (NON_ZERO Value) Present in the
Request
5.4.1.1. 要求の現在のホームネットワーク接頭語オプション(ゼロが評価する非_)
+=====================================================================+ | 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 | +=====================================================================+
+=====================================================================+ | 反-登録/登録メッセージ| +=====================================================================+ | NON_ZERO Valueと少なくとも1HNP Option| +=====================================================================+ | ATT| +=====================================================================+ | Mn LL識別子はプレゼントを選びます。| Mn LL識別子はどんなプレゼントも選びません。| +=====================================================================+ | こんにちは| +==================================+==================================+ | BCEルックアップキー: 要求からのホームNetwork Prefixesのいずれも| +=====================================================================+
Figure 7: Binding Cache Entry (BCE) Lookup Using Home Network Prefix
図7: 拘束力があるキャッシュエントリー(BCE)ルックアップ使用ホームネットワーク接頭語
Gundavelli, et al. Standards Track [Page 28] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[28ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
NON_ZERO接頭語価値がある要求と要求における、モバイルNode Link-層のIdentifierオプションの存在の如何にかかわらず現在の少なくとも1つのホームNetwork Prefixオプションがあれば、以下の問題を適用しなければなりません。 ホームNetwork Prefixオプションの1つ以上のインスタンスがあれば、Binding Cacheエントリーの場所を見つけるのに要求(NON_ZERO接頭語価値がある)の現在のホームNetwork Prefixオプションのいずれも使用できます。
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. 地元の移動性アンカーは、受信されたProxy Binding UpdateメッセージのホームNetwork Prefixオプションの1つでホームネットワーク接頭語の1つが接頭語値に合っている既存のBinding Cacheエントリーがあるかを確かめなければなりません。
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. Binding Cacheエントリーが存在していないなら(Binding Cacheエントリーにおけるホームネットワーク接頭語の1つが受信されたProxy Binding UpdateメッセージのホームNetwork Prefixオプションの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. Binding Cacheエントリー(Binding Cacheエントリーにおけるホームネットワーク接頭語の1つが受信されたProxy Binding UpdateメッセージのホームNetwork Prefixオプションの1つにおける接頭語値に合っている)が存在しているなら; しかし、エントリーにおけるモバイルノード識別子が受信されたProxy Binding UpdateメッセージのモバイルNode Identifierオプションにおけるモバイルノード識別子に合っていないなら、地元の移動性アンカーは_どんな_AUTHORIZED_FOR_ホームNETWORK_PREFIXにもStatus分野選択値群による要求を拒絶してはいけません(モバイルノードは要求しているホームネットワーク接頭語の1つ以上のために認可されません)。
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. Binding Cacheエントリー(受信されたProxy Binding UpdateメッセージのホームNetwork Prefixオプションの1つにおける接頭語値を合わせながら、Binding Cacheエントリーでミネソタ-識別子とホームネットワーク接頭語の1つを合わせる)が存在しているなら; しかし、カウントで合っていないなら要求におけるすべての接頭語がBinding Cacheエントリーですべての接頭語に合っているというわけではないなら、地元の移動性アンカーはPREFIX_SET_が__どんなMATCHもしないBCE_PBU_にStatus分野選択値群による要求を拒絶しなければなりません(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. Binding Cacheエントリー(受信されたProxy Binding Updateメッセージのすべてのホームネットワーク接頭語を合わせながら、Binding Cacheエントリーでミネソタ-識別子とすべてのホームネットワーク接頭語を合わせる)が存在していて、述べられた状態の下におけるこれらのいくらか1つか以上が本当であるなら、そのBinding Cacheエントリーをアップデートするのを求める要求であると要求をみなさなければなりません。
Gundavelli, et al. Standards Track [Page 29] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[29ページ]RFC5213のプロキシのモバイルIPv6 August 2008
* 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.
* 要求の現在のモバイルNode Link-層のIdentifierオプションがあって、オプションにおけるリンクレイヤ識別子がBinding Cacheエントリーとアクセス技術に関するリンクレイヤ識別子に合っているなら、要求マッチの現在のAccess Technology Typeオプションで、Binding Cacheエントリーでアクセス技術タイプをタイプしてください。
* 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).
* 要求の現在のHandoff IndicatorオプションにおけるHandoff Indicator分野が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).
* 要求の現在のどんなモバイルNode Link-層のIdentifierオプションもなければ、Binding Cacheエントリーにおけるリンクレイヤ識別子価値は_ZEROに設定されて、Binding Cacheエントリーと要求の現在のHandoff IndicatorオプションにおけるHandoff Indicator分野が3(同じインタフェースへのモバイルアクセスゲートウェイの間の移管)の値に設定されるかどうかで要求の現在のAccess Technology Typeオプションにおけるアクセス技術タイプ分野はアクセス技術タイプに合っています。
* 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.
* Binding CacheエントリーにおけるProxy-CoAが要求のソースアドレスに合っている、(中のアドレス、Alternate Care、-、Addressオプション、オプションが存在しているなら要求の現在のAccess Technology Typeオプションにおけるアクセス技術タイプ分野がアクセス技術に合っているなら、Binding Cacheエントリーをタイプしてください。
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. 他のすべてのケースにおいて、新しい移動性セッションを作成するのを求める要求であるとメッセージをみなさなければなりません。 しかしながら、受信されたProxy Binding Updateメッセージでゼロの生涯値があって、どんな既存の移動性セッションにも要求を関連づけることができないなら、静かにメッセージを無視しなければなりません。
Gundavelli, et al. Standards Track [Page 30] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[30ページ]RFC5213のプロキシのモバイルIPv6 August 2008
5.4.1.2. Mobile Node Link-layer Identifier Option Present in the
Request
5.4.1.2. 要求の現在のモバイルノードリンクレイヤ識別子オプション
+=====================================================================+ | 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) | +=====================================================================+
+=====================================================================+ | 反-登録/登録メッセージ| +=====================================================================+ | NON_ZERO ValueとのHNPオプションがありません。| +=====================================================================+ | ATT| +=====================================================================+ | Mn LL識別子オプションプレゼント(ゼロが評価する非_)| +=====================================================================+ | こんにちは| +==================================+==================================+ | BCEルックアップキー: (Mn LLミネソタ-識別子+ATT+識別子) | +=====================================================================+
Figure 8: BCE Lookup Using Link-layer Identifier
エイト環: リンクレイヤ識別子を使用する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接頭語価値の現在のどんなホームNetwork Prefixオプションもありませんが、要求の現在のモバイルNode Link-層のIdentifierオプションがあれば、Binding Cacheエントリーの場所を見つけて、以下の問題に申し込まなければなりません。
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. 地元の移動性アンカーは、既存のBinding Cacheエントリーがあるかどうか確かめなければなりません、モバイルノード識別子が容認されたモバイルNode Link-層のIdentifierオプションにおける識別子を合わせながら容認されたモバイルNode Identifierオプション、容認されたAccess Technology Typeオプションにおける値に合っているアクセス技術タイプ、およびリンクレイヤ識別子価値における識別子に合っていて。
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. Binding Cacheエントリー(合っているミネソタ-識別子、Access Technology Type(ATT)、およびミネソタLL識別子)が存在しているなら、そのBinding Cacheエントリーをアップデートするのを求める要求であると要求をみなさなければなりません。
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. Binding Cacheエントリー(合っているミネソタ識別子、ATT、およびミネソタLL識別子)が存在していなくて、要求の現在のHandoff IndicatorオプションにおけるHandoff Indicator分野が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
* 地元の移動性アンカーは、要求の現在のモバイルNode Identifierオプションにおける識別子に合っているモバイルノード識別子と何かリンクレイヤ識別子のために1つの唯一無二のBinding Cacheエントリーが存在するかどうか確かめなければなりません。
Gundavelli, et al. Standards Track [Page 31] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[31ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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つだけが存在しているなら(ミネソタ識別子を合わせて)、そのBinding Cacheエントリーをアップデートするのを求める要求であると要求をみなさなければなりません。
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. Binding Cacheエントリー(合っているミネソタ識別子、ATT、およびミネソタLL識別子)が存在していなくて、要求の現在のHandoff IndicatorオプションにおけるHandoff Indicator分野が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.
* 地元の移動性アンカーは、要求の現在のモバイルNode Identifierオプションにおける識別子に合っているモバイルノード識別子と何かリンクレイヤ識別子価値のために1つの唯一無二のBinding Cacheエントリーが存在するかどうか確かめなければなりません。 そのようなエントリーの1つだけが存在しているなら(ミネソタ識別子を合わせて)、既存のBinding Cacheエントリーが反-登録されるまで、地方の移動性アンカーSHOULDは以前に役立っているモバイルアクセスゲートウェイのそばで待っています、そのBinding Cacheエントリーをアップデートするのを求める要求であると要求をみなすことができる前に。 しかしながら、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. 他のすべてのケースにおいて、新しい移動性セッションを作成するのを求める要求であるとメッセージをみなさなければなりません。 しかしながら、受信されたProxy Binding Updateメッセージでゼロの生涯値があって、どんな既存の移動性セッションにも要求を関連づけることができないなら、静かにメッセージを無視しなければなりません。
Gundavelli, et al. Standards Track [Page 32] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[32ページ]RFC5213のプロキシのモバイルIPv6 August 2008
5.4.1.3. Mobile Node Link-layer Identifier Option Not Present in the
Request
5.4.1.3. 要求の現在でないモバイルノードリンクレイヤ識別子オプション
+=====================================================================+ | 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) | +=====================================================================+
+=====================================================================+ | 反-登録/登録メッセージ| +=====================================================================+ | NON_ZERO ValueとのHNPオプションがありません。| +=====================================================================+ | ATT| +=====================================================================+ | 現在でないMn LL識別子オプション| +=====================================================================+ | こんにちは| +==================================+==================================+ | BCEルックアップキー: (ミネソタ-識別子) | +=====================================================================+
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接頭語価値の現在のどんなホームNetwork Prefixオプションもなくて、またまた、要求の現在のどんなモバイルNode Link層のIdentifierオプションもなければ、Binding Cacheエントリーの場所を見つけて、以下の問題に申し込まなければなりません。
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. 地元の移動性アンカーは、モバイルノード識別子が要求の現在のモバイルNode Identifierオプションにおける識別子に合っている1つの唯一無二のBinding Cacheエントリーが存在するかどうか確かめなければなりません。
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. そのようなエントリーの1つだけが存在していて(ミネソタ-識別子を合わせて)、要求の現在のHandoff IndicatorオプションにおけるHandoff Indicator分野が2(モバイルノードの2つの異なったインタフェースの間の移管)の値に設定されるか、または3の値に設定されるなら(同じインタフェースへのモバイルアクセスゲートウェイの間の移管)、そのBinding Cacheエントリーをアップデートするのを求める要求であると要求をみなさなければなりません。
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
3. そのようなエントリーの1つだけが存在していて(ミネソタ-識別子を合わせて)、要求の現在のHandoff IndicatorオプションにおけるHandoff Indicator分野が4(移管州の未知)の値に設定されるなら、そのBinding Cacheエントリーをアップデートするのを求める要求であると要求をみなすことができる前に既存のBinding Cacheエントリーが反-登録されるまで、地方の移動性アンカーSHOULDは以前に役立っているモバイルアクセスゲートウェイのそばで待っています。 しかしながら、MaxDelayBeforeNewBCEAssign時間中に受け取られる反-登録メッセージが全くなければ、要請を受け入れるとき、地元の移動性アンカーは、新しい移動性セッションを作成するのを求めて要求が要求であるとみなさなければなりません。 The
Gundavelli, et al. Standards Track [Page 33] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[33ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
また、地元の移動性アンカーは、反-登録メッセージを待たないで新しい移動性セッションを作成するのを選ぶかもしれません、そして、これは地元の移動性アンカーに構成可能であるべきです。
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. 他のすべてのケースにおいて、新しい移動性セッションを作成するのを求める要求であるとメッセージをみなさなければなりません。 しかしながら、受信されたProxy Binding Updateメッセージでゼロの生涯値があって、どんな既存の移動性セッションにも要求を関連づけることができないなら、静かにメッセージを無視しなければなりません。
5.5. Timestamp Option for Message Ordering
5.5. メッセージ注文のためのタイムスタンプオプション
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]はホームのエージェントがそれらがモバイルノードによって送られたオーダーにおける拘束力があるアップデートを処理する方法として拘束力がある登録メッセージでSequence Number分野を使用します。 ホームのエージェントとモバイルノードは結合の生涯このカウンタを管理しなければなりません。 しかしながら、ProxyのモバイルIPv6では、モバイルノードが別のものとモバイルアクセスゲートウェイの間の文脈転送などのメカニズムがないとき1モバイルアクセス門から移行するので、給仕モバイルアクセスゲートウェイはそれがシグナリングメッセージで使用する必要がある一連番号を測定できないでしょう。 したがって、[RFC3775]で指定される一連番号体系はProxyのモバイル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.
地元の移動性アンカーが受信されたProxy Binding Updateメッセージの送付順番を決定できないなら、潜在的に故障していた状態でモバイルノードが以前に据えつけられましたが、提供されたモバイルアクセスゲートウェイによって送られたより古いメッセージを処理するかもしれません、前のモバイルアクセスゲートウェイにモバイルノードのトラフィックにトンネルを堀るために不当にモバイルノードのBinding Cacheエントリーをアップデートして、ルーティング状態を創設するようになって。
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つは[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.
拘束力がある登録メッセージにおけるタイムスタンプの使用の後ろの基本原理はメッセージ差し込みが現在の時刻と、メッセージを受け取るノードであると生成するノードが、このタイムスタンプにすべてが以前にタイムスタンプを受け入れたよりすばらしいのをチェックするということです。 ProxyのモバイルIPv6ドメインの給仕モバイルアクセスゲートウェイに与えられたモバイルノードの結合をアップデートすることへのProxy Binding Updateメッセージで送られた最後の一連番号を得る能力がないと、タイムスタンプベースのソリューションは使用されるかもしれません。
Gundavelli, et al. Standards Track [Page 34] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[34ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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モバイルアクセス門の間を移動するのに必要である現代の合計であり、時間が給仕モバイルアクセスゲートウェイがアクセスリンクの上のモバイルノードを検出して、Proxy Binding Updateメッセージを構成するのが必要です。 これらの隣接している2モバイルアクセス門(時計同期に使用される一般的な時間ソースに比例した)のどれかにおける時計斜行がこの再接続時間にタイムスタンプ解決がすべてのケースとしたがって、SHOULD NOTで予想どおりに扱わない半数以上であるなら、使用されてください。
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.
また、Timestampベースのアプローチに代わる手段として、仕様は[RFC3775]で指定されるようにSequence番号ベースの体系の使用を許します。 しかしながら、この体系がうまくいくために、ProxyのモバイルIPv6ドメインの給仕モバイルアクセスゲートウェイには、その移動性セッションへの拘束力がある登録メッセージで送られた最後の一連番号を得る能力がなければなりません。 一連番号は、モバイルノードの移動性セッション基礎あたり1つのところで維持しなければならなくて、給仕モバイルアクセスゲートウェイに有効であるに違いありません。 これは、文脈転送体系を使用するか、または方針店で一連番号を維持することによって、達成されるかもしれません。 しかしながら、このドキュメントの範囲の外にどうモバイルノードの一連番号をProxy Binding Updateメッセージを送る前に給仕モバイルアクセスゲートウェイに利用可能にするかに関する特定の詳細があります。
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. 地方の移動性アンカー実装は、Timestampがオプションであるとサポートしなければなりません。 Timestampオプションが受信されたProxy Binding Updateメッセージに存在しているなら、地元の移動性アンカーはモバイルアクセスゲートウェイに発信するというProxy Binding Acknowledgementメッセージで有効なTimestampオプションを入れなければなりません。
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. ProxyのモバイルIPv6ドメインのTimestampオプションを使用することで拘束力がある登録メッセージを交換しているすべての移動性実体が時刻時計を適切に連動させたに違いありません。 これはこのソリューションが働いているという必須の条件です。 この必要条件が満たされないと、ソリューションはすべての場合で予想どおりに働かないでしょう。
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
3. ProxyのモバイルIPv6ドメインSHOULDの移動性実体は一般的な時間ソースにそれらの時計を連動させます。 時計を連動させるように、ノードはNetwork Timeプロトコル[RFC4330]を使用するかもしれません。 また、展開はその特定の展開に適した他のアプローチを取るかもしれません。 あるいはまた、タイムスタンプであることが作られたモバイルノードがあれば、それはアクセスリンクであってそのタイムスタンプが利用可能であるかどうかへのあらゆる付属で増加しています。
Gundavelli, et al. Standards Track [Page 35] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[35ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
モバイルアクセスゲートウェイ(例えば、モバイルノードが発信するというSEND[RFC3971]メッセージにおけるTimestampオプション)に、モバイルアクセスゲートウェイは、Proxy Binding Updateメッセージでこのタイムスタンプか一連番号を使用できて、どんな外部クロックソースにも頼る必要はありません。 しかしながら、このドキュメントの範囲の外にこれがどう達成されるかに関する特定の詳細があります。
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. Timestampオプションを組み込むためにタイムスタンプが値であると生成するとき、移動性実体は、発生しているタイムスタンプが同じ参照時代の指定されるとしての過去のTimestampオプション(セクション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. Timestampオプションが受信されたProxy Binding Updateメッセージに存在しているなら、地元の移動性アンカーはメッセージの一連番号分野を無視しなければなりません。 しかしながら、それは受信されたProxy Binding UpdateメッセージからProxy Binding Acknowledgementメッセージまで一連番号をコピーしなければなりません。
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. TimestampオプションがあるProxy Binding Updateメッセージを受け取り次第、地元の移動性アンカーは正当性がないかどうかタイムスタンプ分野をチェックしなければなりません。 それが有効であると考えられるために、以下は本当でなければなりません。
* 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.
* 地元の移動性アンカーの時刻時計にはTimestampオプションに含まれたタイムスタンプ値が十分近くにあるに違いありません(TimestampValidityWindow時間差の中で)。 しかしながら、旗のMobileNodeGeneratedTimestampInUseが1の値に用意ができているなら、地元の移動性アンカーは、このチェックを無視して、以下のチェックだけを実行しなければなりません。
* The timestamp MUST be greater than all previously accepted
timestamps in the Proxy Binding Update messages sent for that
mobile node.
* タイムスタンプはProxy Binding Updateメッセージのすべての以前に受け入れられたタイムスタンプがそのモバイルノードを注文したよりすばらしいに違いありません。
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. 容認されたProxy Binding Updateのタイムスタンプ値が有効であるか(上の問題における指定されるとしての正当性)、または旗のMobileNodeGeneratedTimestampInUseが1の値に用意ができているなら、モバイルアクセスゲートウェイに発信するというProxy Binding Acknowledgementメッセージにオプションを含んでいる場合、地元の移動性アンカーはTimestampで同じタイムスタンプ値を返さなければなりません。
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
8. 容認されたProxy Binding Updateのタイムスタンプ値が移動性がそれのためにProxy Binding Updateメッセージの以前に受け入れられたタイムスタンプで付いたより低いなら、地元の移動性アンカーがStatus分野セットでTIMESTAMP_LOWER_THAN_PREV_ACCEPTEDにProxy Binding Updateメッセージを拒絶して、Proxy Binding Acknowledgementメッセージを送らなければならない、(タイムスタンプは下ろされます。
Gundavelli, et al. Standards Track [Page 36] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[36ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
以前に受け入れられたタイムスタンプ) また、メッセージは地元の移動性アンカーの上の現在の時刻に選択値群によるTimestampオプションを含まなければなりません。
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. 容認されたProxy Binding Updateのタイムスタンプ値が有効でないなら(上の問題における指定されるとしての正当性)、地元の移動性アンカーは、Status分野セットでTIMESTAMP_MISMATCH(タイムスタンプミスマッチ)にProxy Binding Updateを拒絶して、Proxy Binding Acknowledgementメッセージを送らなければなりません。 また、メッセージは地元の移動性アンカーの上の現在の時刻に選択値群によるTimestampオプションを含まなければなりません。
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. Timestampオプションが受信されたProxy Binding Updateメッセージに存在していないなら、地元の移動性アンカーはSequence番号ベースの体系へ後ろへ下がらなければなりません。 それは[RFC3775]の指定されるとしての一連番号分野を処理しなければなりません。 また、それはモバイルアクセスゲートウェイに発信するというProxy Binding AcknowledgementメッセージにTimestampオプションを含んではいけません。
2. An implementation MUST support the Sequence-Number-based scheme,
as specified in [RFC3775].
2. 実装は[RFC3775]で指定されるようにSequence番号ベースの体系をサポートしなければなりません。
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. 給仕モバイルアクセスゲートウェイが与えられたモバイルノードの結合をアップデートすることへのProxy Binding Updateメッセージで送られた最後の一連番号を得ることができる何らかのメカニズム(モバイルアクセスゲートウェイの間の文脈転送手順などの)があるときだけ、Sequence番号ベースのアプローチを使用できます。
5.6. Routing Considerations
5.6. ルート設定問題
5.6.1. Bi-Directional Tunnel Management
5.6.1. 双方向のトンネル管理
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.
モバイルアクセスゲートウェイと地元の移動性アンカーの間のモバイルノードのデータ通信量を発送するのに双方向のトンネルを使用しなければなりません。 トンネルは、トポロジーを隠して、モバイルノードがそのProxyのモバイルIPv6ドメインのどんなアクセスリンクからもホームネットワーク接頭語(es)からのアドレス(es)を使用するのを可能にします。 必要でないと、必要であり、取り除くと、ダイナミックにトンネルを作成するかもしれません。 しかしながら、実装は、必要性ベースでダイナミックにそれらを作成して、引き裂くことの代わりに静的なプレ確立したトンネルを使用するのを選ぶかもしれません。 ダイナミックに作成されたトンネルを使用するとき、以下の問題を適用しなければなりません。
Gundavelli, et al. Standards Track [Page 37] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[37ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 地元の移動性アンカーと、モバイルアクセスゲートウェイと地元の移動性アンカーの間でIPv6のIPv6カプセル化で双方向のトンネルを確立しなければなりません、[RFC2473]で説明されるように。 トンネル終点は、Proxy-CoAとLMAAです。 しかしながら、IPv4輸送を使用するとき、トンネルの終点は、IPv4-LMAAと指定されるとしてのカプセル化モードは[IPV4-PMIP6]にあるIPv4プロキシ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 トンネルSHOULD、削除されてください、いつ、トンネル、生涯、期限が切れるか、または、いつ、トンネルを共有するモバイルノードが全くないか。
5.6.2. Forwarding Considerations
5.6.2. 推進問題
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)か集められた接頭語のためのルート設定Infrastructureに接続ルートの広告を出さなければなりません。 これはモバイルノードのホームネットワーク接頭語(es)のための最後のホップルータとして地元の移動性アンカーを検出するそのネットワークで本質的にはIPv6ルータを可能にします。
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 トンネルを堀られたパケットの書式は以下に示されます。 IPv6カプセル化のために[RFC2473]からの問題を適用しなければなりません。 しかしながら、IPv4輸送を使用するとき、パケットの形式が[IPV4-PMIP6]で説明されるようにあります。
Gundavelli, et al. Standards Track [Page 38] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[38ページ]RFC5213のプロキシのモバイルIPv6 August 2008
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
IPv6ヘッダー、(src= LMAA、dstはプロキシ-CoA/*トンネルHeader*/IPv6ヘッダー(src= CN、dstはミネソタ-HOAと等しい)/*パケットHeader*/覚醒剤層のプロトコル/*パケットContent*/と等しいです。
Figure 10: Tunneled Packet from LMA to MAG
図10: トンネルを堀られた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= 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*/
IPv6ヘッダー、(src= LMAA、dstはトンネルモード/*超能力Header*/IPv6ヘッダー(src= CN、dstはミネソタ-HoAと等しい)/*パケットHeader*/覚醒剤層のプロトコル/*パケットContent*/でプロキシ-CoA/*トンネルHeader*/超能力Headerと等しいです。
Figure 11: Tunneled Packet from LMA to MAG with Payload Protection
図11: 有効搭載量保護があるトンネルを堀られたLMAから雑誌までのパケット
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 トンネルヘッダーを取り除いた後に地元の移動性アンカーがモバイルアクセスゲートウェイから受けたすべての逆のトンネルを堀られたパケットを内側のパケットのヘッダーで指定された目的地に発送しなければなりません。 これらの発送されたパケットで、モバイルノードのホームアドレスにSource Address分野を設定するでしょう。 IPv6被膜剥離術のために[RFC2473]からの問題を適用しなければなりません。
5.6.3. Explicit Congestion Notification (ECN) Considerations for Proxy
Mobile IPv6 Tunnels
5.6.3. プロキシのモバイルIPv6Tunnelsのための明白な混雑通知(電子証券取引ネットワーク)問題
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.
電子証券取引ネットワーク情報が、どうトンネルエントリーとエキジットポイントにおける移動性エージェントによって扱われる必要であるかをこのセクションは説明します。 IPトンネルへの電子証券取引ネットワーク問題は[RFC3168]で指定されます、そして、同じ問題はProxyのモバイルIPv6トンネルに適用されます(IPv6のIPv6カプセル化モードを使用して)。 明確に、完全な機能性オプションをサポートしなければなりません。 [RFC3168]からの関連電子証券取引ネットワーク問題は便宜のためにここへまとめられます。
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 内側のヘッダーのExplicit Congestion Notification(電子証券取引ネットワーク)分野がECT(0)かECT(1)(ECTは電子証券取引ネットワークのできるTransport(ECT)を表す)に設定されるなら、内側のヘッダーからの電子証券取引ネットワーク分野を外側のヘッダーにコピーしなければなりません。 IPsecを使用するペイロード保護がモバイルノードのデータ通信量に可能にされるとき、さらに、[RFC4301]からの電子証券取引ネットワーク問題を適用しなければなりません。
Gundavelli, et al. Standards Track [Page 39] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[39ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 内側のヘッダーのExplicit Congestion Notification(電子証券取引ネットワーク)分野がECT(0)かECT(1)に設定されて、外側のヘッダーの電子証券取引ネットワーク分野がCongestion Experienced(CE)に設定されるなら、内側のヘッダーの電子証券取引ネットワーク分野をCEに設定しなければなりません。 さもなければ、内側のヘッダーの電子証券取引ネットワーク分野を変更してはいけません。 IPsecを使用するペイロード保護がモバイルノードのデータ通信量に可能にされるとき、さらに、[RFC4301]からの電子証券取引ネットワーク問題を適用しなければなりません。
5.7. Local Mobility Anchor Address Discovery
5.7. 地方の移動性アンカーアドレス発見
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で説明されるダイナミックなホームエージェントAddressディスカバリー(DHAAD)で、モバイルノードは、ホームのリンクの上にホームネットワーク接頭語から得られたモバイルIPv6ホームのエージェントのanycastアドレスにICMPホームエージェントAddressディスカバリーRequestメッセージを送ることによって、すべてのホームのエージェントを発見できます。
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.
モバイルノードの地元の移動性アンカーのアドレスを発見するのにProxyのモバイルIPv6で現在のフォームでのDHAADメッセージを使用できません。 ProxyのモバイルIPv6では、地元の移動性アンカーはモバイルIPv6ホームのエージェントのモバイルノードのホームネットワーク接頭語(es)に対応するanycastアドレスに送られたどんなメッセージも受け取ることができないでしょう、接頭語(es)がインタフェースのいずれでもホスティングされないとき。 さらに、モバイルアクセスゲートウェイは予想どおりにモバイルノードの拘束力があるキャッシュエントリーを持っている役立っている地元の移動性アンカーの居場所を見つけることができないでしょう。 したがって、この仕様は、DynamicホームエージェントAddressがディスカバリープロトコルであるとサポートしません。
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.
ProxyのモバイルIPv6では、移動性アクセスゲートウェイ実体で他の手段でモバイルノードに役立つように構成された地元の移動性アンカーのアドレスを発見できます。 モバイルノードに割り当てられるべきLMAはモバイルノードの方針プロフィールの構成されたエントリーであるかもしれませんかこのドキュメントの範囲の外のメカニズムを通してそれを得るかもしれません。
5.8. Mobile Prefix Discovery Considerations
5.8. モバイル接頭語発見問題
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]の指定されるとしてのモバイル接頭語発見メカニズムはProxyのモバイルIPv6に適切ではありません。
Gundavelli, et al. Standards Track [Page 40] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[40ページ]RFC5213のプロキシのモバイルIPv6 August 2008
5.9. Route Optimization Considerations
5.9. 経路最適化問題
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.
そして、モバイルIPv6の[RFC3775]で定義されるRoute Optimizationが、モバイルノードが通信員ノードとコミュニケートするのを直接使用することで可能にする、それ、注意、-、アドレス、さらに、Return Routability手順が、通信員ノードにはモバイルノードが届いている信頼の妥当な両方があるのを可能にする、ホームアドレス、注意、-、アドレス
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]で指定されたRoute Optimizationをサポートしません。 しかしながら、この仕様はセクション6.10.3で指定されるように別の形式の経路最適化をサポートします。
6. Mobile Access Gateway Operation
6. モバイルアクセスゲートウェイ操作
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.
本書では説明されたProxyのモバイルIPv6プロトコルは新しい機能的な実体、モバイルアクセスゲートウェイ(MAG)を導入します。 モバイルアクセスゲートウェイはリンクとアクセスリンクからモバイルノードの動きを検出して、地元の移動性アンカーにProxy Binding Updateメッセージを送るのに原因となる実体です。 本質では、モバイルノードを代表してモバイルアクセスゲートウェイは移動性管理を実行します。
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)を含むメッセージをRouter Advertisementに送るのによるアクセスリンクの上のモバイルノードのホームのリンクのエミュレーション、各接頭語は、Prefix情報オプション[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つ以上のアドレスを構成して、付属アクセスリンクからそれを使用するのを可能にするための推進をセットアップするのに責任があります。
Gundavelli, et al. Standards Track [Page 41] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[41ページ]RFC5213のプロキシのモバイルIPv6 August 2008
6.1. Extensions to Binding Update List Entry Data Structure
6.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].
あらゆるモバイルアクセスゲートウェイがBinding Update Listを維持しなければなりません。 Binding Update Listの各エントリーは地元の移動性アンカーと共に付くモバイルノードの移動性を表します。 Binding Update Listは[RFC3775]のセクション11.1で説明された概念的なデータ構造です。
For supporting this specification, the conceptual Binding Update List entry data structure needs be extended with the following additional fields.
この仕様、概念的なBinding Update Listエントリーにデータ構造の必要性をサポートするには、以下の追加分野で、広げられてください。
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 添付のモバイルノードに関する識別子、ミネソタ-識別子。 アクセスリンクへのモバイルノードの付属の間、このドキュメントの範囲の外のメカニズムを通してこの識別子を取得します。
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 モバイルノードの接続インタフェースに関するリンクレイヤ識別子。 モバイルノードかアクセスネットワークへのモバイルノードの付属の間、受信されたRouter Solicitationメッセージからこれを取得できます。 通常、これはモバイルノードによって伝えられたリンクレイヤ識別子です。 しかしながら、この仕様のための範囲の外にそれがどう運ばれるかに関する特定の詳細があります。 この識別子が利用可能でないなら、この可変長フィールドを2(八重奏)に設定しなければならなくて、_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 アクセスリンクの上のモバイルアクセスゲートウェイのLink-ローカルアドレスはモバイルノードと共有されました。
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 インタフェース識別子、(-、イド、)、ポイントツーポイントでは、モバイルノードとモバイルアクセスゲートウェイの間でリンクしてください。 これは、モバイルアクセスゲートウェイに内部であり、モバイルノードが添付しているアクセスリンクにProxyのモバイルIPv6トンネルを関連づけるのに使用されます。
Gundavelli, et al. Standards Track [Page 42] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[42ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 モバイルノードの地元の移動性アンカーとモバイルアクセスゲートウェイの間の両性愛者の方向のトンネルに関するトンネルインタフェース識別子(イドであるなら、トンネルを堀ってください)。 これはモバイルアクセスゲートウェイに内部です。 トンネル作成の間、トンネルインタフェース識別子を取得します。
6.2. Mobile Node's Policy Profile
6.2. モバイルノードの方針プロフィール
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 モバイルノードの識別子(ミネソタ-識別子)
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 (es)が割り当てたモバイルノードのIPv6ホームネットワーク接頭語はモバイルノードのものにインタフェースを接続しました。 これらの接頭語は1インタフェースあたり1個のベースで維持されなければなりません。 モバイルノードの各インタフェースのための複数のユニークなエントリーがあることができます。 ネットワークが、このドキュメントの範囲の外に接頭語セットとインタフェースと、特にインタフェースの間の移動性セッション移管の間のこの協会があるとどう主張するかに関する特定の詳細。
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ホームネットワークPrefix生涯。 この寿命はリンクの上のすべての接待された接頭語に同じになるでしょう、それらが皆、1つの移動性セッションの一部であるので。 また、この値もすべてのモバイルノードの移動性セッションのために同じである場合があります。
o Supported address configuration procedures (Stateful, Stateless,
or both) for the mobile node in the Proxy Mobile IPv6 domain
o ProxyのモバイルIPv6ドメインのモバイルノードのためのアドレス構成手順(Stateful、Stateless、または両方)であるとサポートされます。
Gundavelli, et al. Standards Track [Page 43] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[43ページ]RFC5213のプロキシのモバイルIPv6 August 2008
6.3. Supported Access Link Types
6.3. アクセスリンク型であるとサポートされます。
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.
最終的に、この仕様はノード付属と分離のリンクレイヤしるしなしでリンクまで作動できますが、ネットワークかモバイルノード側におけるそのような指摘の存在は結果として起こる性能を向上させます。
6.4. Supported Address Configuration Modes
6.4. アドレス構成モードであるとサポートされます。
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.
ProxyのモバイルIPv6ドメインのモバイルノードはそのリンクの上の接待された接頭語(es)からインタフェース(Statelessを使用するか、Statefulアドレス自動構成手順または手動のアドレス構成)に関する1つ以上のグローバルなIPv6アドレスを構成できます。 アクセスリンクに送られたRouter Advertisementメッセージはそのモバイルノードのためにそのアクセスリンクの上に受入れられたアドレス構成メソッドを指定します。 しかしながら、アドレス構成に関して、モバイルノードにおいて、広告を出している旗は一貫するでしょう、そのProxyのモバイル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].
状態がないアドレス自動構成がアクセスリンクの上にサポートされるとき、Stateless Autoconfigurationなどの標準のIPv6メカニズム[RFC4862]かPrivacy拡張子[RFC4941]でモバイルノードは接待された接頭語(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アドレス自動構成がリンクの上にサポートされるとき、モバイルノードはProxyのモバイルIPv6ドメインに位置するDHCPサーバからアドレス構成を得ることができます、標準のDHCPメカニズムで、[RFC3315]で指定されるように。 得られたアドレス(es)はホームネットワーク接頭語(es)から来ているでしょう。 セクション6.11はどうこの構成を達成できるかに関する詳細を指定します。
Gundavelli, et al. Standards Track [Page 44] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[44ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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アドレス構成メカニズムのどれかの振舞いを変更しません。
6.5. Access Authentication and Mobile Node Identification
6.5. アクセス認証とモバイルノード識別
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.
モバイルノードがモバイルアクセスゲートウェイに接続されたアクセスリンクに付くと、そのリンクSHOULDの上の配布しているアクセス保護プロトコルは、モバイルノードを認証して、認可した後にだけネットワークベースの移動性経営指導がそのサービスのために提供されるのを確実にします。 このドキュメントの範囲の外にこれがどう達成されるかの正確な詳細かモバイルアクセスゲートウェイとアクセスセキュリティー・サービスとの相互作用があります。 この仕様はプロトコル操作が始まる前にモバイルノードとモバイルアクセスゲートウェイの間に確立した信頼を持つ述べられた仮定を伴います。
6.6. Acquiring Mobile Node's Identifier
6.6. モバイルノードの識別子を取得します。
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.
ProxyのモバイルIPv6ドメインのすべてのネットワーク実体がモバイルノードを特定できなければなりません、ミネソタ-識別子を使用して。 この識別子は、ProxyのモバイルIPv6ドメインの向こう側に安定していてユニークであるに違いありません。 ProxyのモバイルIPv6ドメインの移動性実体は、シグナリングメッセージのこの識別子を使用して、明白に与えられたモバイルノードを特定できなければなりません。 ↓これはこのミネソタ-識別子に関連する問題のいくつかです。
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 アクセス認証の一部、または、通知されたネットワーク付属イベントからミネソタ-識別子を通常得ます。 アクセス認証の間に唯一認証されたユーザ識別子がモバイルノードを特定する場合では、ミネソタ識別子はユーザ識別子と同じであるかもしれません。 しかしながら、同じProxyのモバイルIPv6ドメインで作動する1つ以上のモバイルノードから使用できるユーザアカウントを特定するなら、ユーザ識別子を使用してはいけません。
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ベースのシステム、中のRemote Authentication Dial User Service(RADIUS)属性に、Chargeableユーザ識別子[RFC4372]は使用されるかもしれません、唯一、ユーザアカウントではなく、複数のモバイルノードと共に使用できるモバイルノードを特定する限り。
Gundavelli, et al. Standards Track [Page 45] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[45ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 いくつかの場合とプライバシー理由で、方針店がモバイルアクセスゲートウェイに提供するミネソタ-識別子はモバイルノードの本当の識別子でないかもしれません。 しかしながら、移動性アクセスゲートウェイはメッセージが地元の移動性アンカーと共に交換したシグナリングにこの識別子を使用できなければなりません。
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 モバイルアクセスゲートウェイはミネソタ-識別子でモバイルノードを特定できなければなりません、そして、それは指すポイントへのモバイルノードと共有されたこのアイデンティティリンクを関連づけることができなければなりません。
6.7. Home Network Emulation
6.7. ホームネットワークエミュレーション
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つはアクセスリンクの上にモバイルノードのホームネットワークを見習うことです。 それは、そのProxyのモバイル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.
アクセスリンクの上のモバイルノードのホームのリンクを見習うのにおいて、モバイルアクセスゲートウェイはPrefix情報オプション[RFC4861]を使用することで運ばれてホームリンクの特性と一致した他のアドレス設定パラメータがあるモバイルノードのホームネットワーク接頭語(es)をRouter Advertisementメッセージ広告に送ることができなければなりません。 これらの構成設定は、通常、ドメイン全体の方針に基づいているか、またはそれぞれのモバイルノードに特定の方針に基づくでしょう。
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.
通常、モバイルアクセスゲートウェイが受信されたProxy Binding Acknowledgementメッセージからモバイルノードのホームネットワーク接頭語(es)の詳細を学ぶか、またはそれはモバイルノードの方針プロフィールからそれらを得るかもしれません。 しかしながら、モバイルノードの地元の移動性アンカーと共に拘束力がある登録を首尾よく終了した後にだけ、モバイルアクセスゲートウェイSHOULDはモバイルノードのホームネットワーク接頭語(es)をRouter Advertisements広告に送ります。
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.
Router Advertisementメッセージのホームネットワーク接頭語(es)の広告を出すとき、モバイルアクセスゲートウェイは一存におけるどんな選ばれた値への広告を出している接頭語(es)にも接頭語生涯価値を設定するかもしれません。 実装は、接頭語を結ぶのを選ぶかもしれません。生涯から拘束力があるモバイルノードの生涯。 生涯缶を前に置いてください、そして、また、モバイルノードの方針プロフィールの任意の設定パラメータになってください。
6.8. Link-local and Global Address Uniqueness
6.8. リンク地方とグローバルアドレスユニークさ
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
ProxyのモバイルIPv6ドメインのモバイルノードは、もう片方への1モバイルアクセス門から移行するときホームネットワークを検出し続けて、層-3付属の変化を検出しません。 あらゆる
Gundavelli, et al. Standards Track [Page 46] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[46ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
モバイルノードが新しいリンクに付く時、界面準位変化に関連するイベントはリンク地方とグローバルアドレス(es)にDuplicate Address Detection(DAD)操作を実行するモバイルノードの引き金となるでしょう。 しかしながら、モバイルノードが[DNAV6]で指定されるように有効にされたIPv6(DNAv6)のDetecting Network Attachmentであるなら、それは、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)がモバイルノードの排他的な用法のためのものであり、他のどんなノードも接頭語(es)からアドレスを共有しないので(モバイルアクセスゲートウェイによって構成されるSubnet-ルータ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人の隣人の間のリンクローカルアドレス衝突(すなわち、モバイルノードとモバイルアクセスゲートウェイ)のためにそのアクセスリンクの上に退室します。 この問題を解決するために、この仕様は、モバイルアクセスゲートウェイがポイントツーポイント接続の上で構成するリンクローカルアドレスが地元の移動性アンカーによって作られて、モバイルノードのBinding Cacheエントリーに保存される与えられたモバイルノードと共有されたのを必要とします。 このアドレスはそのモバイルノードの移動性セッションの持続時間のために変化しないで、あらゆるモバイルノードの移管で給仕モバイルアクセスゲートウェイに提供できます、Proxyのモバイル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
モバイルアクセスゲートウェイの上のアクセスリンクが、モバイルノードがDAD操作[RFC4862]をリンクローカルアドレスに完了する前にそのリンクの上のモバイルアクセスゲートウェイがそれがそのアクセスリンクの上に使用する必要がある地元の移動性アンカーによって提供されたそれ自身のリンクローカルアドレスを意識しているのをそのような方法で食糧を供給されるモバイルノードと共有したのは、非常に望ましいです。 モバイルノードがDAD操作を完了する前にこれはモバイルアクセスゲートウェイのそばで本質的にはProxyのモバイルIPv6シグナリングの無事終了を必要とします。 ProxyのモバイルIPv6シグナリングが達成されるまで、付属が完成しないそのリンクレイヤを確実にすることによって、これを達成できます。
Gundavelli, et al. Standards Track [Page 47] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[47ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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プロセスに関連しているデフォルト待ちの期間、完成しそうであるそのような方法でネットワーク、地方の移動性アンカー容量、およびシグナリング再送信タイマーに食糧を供給することができます。
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.
任意に、実装は、すべてのアクセスリンクの向こう側にProxyのモバイルIPv6ドメインとProxyのモバイルIPv6シグナリングメッセージで地元の移動性アンカーからモバイルアクセスゲートウェイまでこのアドレスを運ぶ必要性なしで固定リンクローカルアドレスを構成するのを選ぶかもしれません。 構成の可変FixedMAGLinkLocalAddressOnAllAccessLinksはそのProxyのモバイルIPv6ドメインで可能にされたモードを決定します。
6.9. Signaling Considerations
6.9. シグナリング問題
6.9.1. Binding Registrations
6.9.1. 拘束力がある登録証明書
6.9.1.1. Mobile Node Attachment and Initial Binding Registration
6.9.1.1. モバイルノード付属と初期の拘束力がある登録
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. アクセスリンクの上の新しいモバイルノードを検出した後に、モバイルアクセスゲートウェイは、モバイルノードを特定して、ミネソタ識別子を取得しなければなりません。 ネットワークベースの移動性経営指導が、モバイルノードに提供される必要を決定するなら、それは地元の移動性アンカーにProxy Binding Updateメッセージを送らなければなりません。
2. The Proxy Binding Update message MUST include the Mobile Node
Identifier option [RFC4283], carrying the MN-Identifier for
identifying the mobile node.
2. Proxy Binding UpdateメッセージはモバイルNode 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. ホームNetwork PrefixオプションはProxy Binding Updateメッセージに存在していなければなりません。 モバイルアクセスゲートウェイが方針店か他の手段からモバイルノードのホームネットワーク接頭語(es)を学ぶなら、モバイルアクセスゲートウェイは、それぞれのもののためのホームNetwork Prefixオプションを含んでいるのによる(es)が要求した特定の接頭語に接頭語を割り当てるよう地元の移動性アンカーに要求するのを選ぶかもしれません。 また、モバイルアクセスゲートウェイは、_ZEROの接頭語値があるちょうど1つのホームNetwork Prefixオプションを含んでいるのを選ぶかもしれません、接頭語課題をするよう地元の移動性アンカーに要求するために。 しかしながら、_ZEROの接頭語値があるホームNetwork Prefixオプションを含んでいるとき、要求におけるホームNetwork接頭語オプションの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. Handoff IndicatorオプションはProxy Binding Updateメッセージに存在していなければなりません。 移管ヒントを示す値にHandoff IndicatorオプションにおけるHandoff Indicator分野を設定しなければなりません。
Gundavelli, et al. Standards Track [Page 48] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[48ページ]RFC5213のプロキシのモバイルIPv6 August 2008
* 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.
* モバイルアクセスゲートウェイが、このインタフェースの上のネットワークへのモバイルノードの現在の付属が既存の移動性セッション(同じインタフェースか異なったインタフェースを通した)の移管の結果、新しいインタフェースに関する付属の結果、あることを決定するなら(このセクションで指定されたHandoff Indicator問題の下で)、1(新しいインタフェースに関する付属)の値にHandoff Indicator分野を設定しなければなりません。 新しい移動性セッションを作成して、Binding Cacheエントリーが同じモバイルノードのために作成したどんな存在もアップデートしない地元の移動性アンカーへの要求が異なったインタフェースを通してProxyのモバイル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.
* Handoff Indicator分野は2(モバイルノードの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.
* Handoff Indicator分野は3(同じインタフェースへのモバイルアクセスゲートウェイの間の移管)の値へのセットが、モバイルアクセスゲートウェイであるなら2モバイルアクセス門の間の既存の移動性セッションの移管とモバイルノードの同じインタフェースにはモバイルノードの現在の付属があるのを決定的に知っているということであるに違いありません。
* 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(移管州の未知)の値にHandoff Indicator分野を設定しなければなりません。
5. The mobile access gateway MUST apply the below considerations
when choosing the value for the Handoff Indicator field.
5. Handoff Indicator分野への値を選ぶとき、モバイルアクセスゲートウェイは以下の問題を適用しなければなりません。
* 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つの異なったインタフェースの間の移管)を使用するのを選ぶことができます、モバイルノードがわざと1つのインタフェースから別のものに切り替わって、前のインタフェースが障害があるようになるのを知っているときだけ。 それは多くの要因のためこれを知るかもしれません。 例えば、ネットワークが、ホストが別のものへの1つの付属によって移行しているのを知っているところでほとんどのセルラー・ネットワークが身柄の引き渡しを制御しました。 この状況で、リンクレイヤメカニズムは、本当に、これが新たな付属ではなく、動きであることを移動性機能に知らせることができます。
Gundavelli, et al. Standards Track [Page 49] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[49ページ]RFC5213のプロキシのモバイルIPv6 August 2008
* 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).
* いくつかのリンクレイヤには、(b) 新しいインタフェースの付属と同じホストと(a) 新たな付属への特定のインタフェースの動きを区別するのに使用できるリンクレイヤ識別子があります。 オプション価値3(同じインタフェースへのモバイルアクセスゲートウェイの間の移管)は場合(b)における、1(新しいインタフェースに関する付属)の場合(a)と値で適切です。
* 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(同じインタフェースへのモバイルアクセスゲートウェイの間の移管)は移行しました。 さもなければ、同じドメインに複数の物理インターフェースを持っているProxyのモバイルIPv6気づかないホストは予期していなかった失敗に苦しむかもしれません。
* 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.
* リンクレイヤからのサポートが全く存在していないところでは、ホストとネットワークは、意図活動に関して互いに知らせる必要があるでしょう。 Proxyのモバイル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](Sequence番号ベースの体系が使用中であるなら)の指定されるとしてのモバイルノードの移動性セッション基礎あたりのaで維持されたTimestampオプションか有効な一連番号のどちらかが存在していなければなりません。 これは構成旗のTimestampBasedApproachInUseの値に基づいて決定できます。 そして、また、Timestampオプションがメッセージに追加されるときモバイルアクセスゲートウェイSHOULDが単調に増加するカウンタの値にSequence Number分野を設定する、(それぞれのモバイルアクセスゲートウェイで維持される、中でモバイルノード一連番号単位で指定されているのに[RFC3775)混乱しないように。 地元の移動性アンカーは、要求の現在のTimestampオプションがあるとき、この分野を無視しますが、Proxy Binding Acknowledgementメッセージの同じ値を返すでしょう。 これは要求メッセージに回答に合っていることの役に立ちます。
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. 現在付属しているインタフェースに関するリンク層の識別子を運ぶモバイルNode Link-層のIdentifierオプションはProxy Binding Updateメッセージに存在していなければなりません、モバイルアクセスゲートウェイが同じくらい意識しているなら。 現在付属しているインタフェースに関するリンクレイヤ識別子が知られていないか、識別子値がすべて_ZEROであるなら、このオプションは存在しているはずがありません。
Gundavelli, et al. Standards Track [Page 50] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[50ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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. Access Technology TypeオプションはProxy Binding Updateメッセージに存在していなければなりません。 アクセス技術タイプはアクセスのタイプへのセットがモバイルノードが現在モバイルアクセスゲートウェイに添付される技術であったならオプションでSHOULDをさばきます。
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. 構成の可変FixedMAGLinkLocalAddressOnAllAccessLinksの値が_ZEROの値に設定される場合にだけ、LinkローカルのAddressオプションはProxy Binding Updateメッセージに存在していなければなりません。 さもなければ、LinkローカルのAddressオプションは要求に存在しているはずがありません。 LinkローカルのAddressオプションを使用するとき、セクション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.
* それがモバイルノードと共有されたポイントツーポイント接続の上で使用するべきであるリンクローカルアドレスを提供するために地元の移動性アンカーについて質問するのにおいて、すべての_ZERO価値にこのオプションを設定しなければなりません。 それがアクセスリンクの上に使用できるリンクローカルアドレスを提供する地元の移動性アンカーへの要求がモバイルノードと共有されたようにこれは本質的には役立ちます。
10. The Proxy Binding Update message MUST be constructed as
specified in Section 6.9.1.5.
10. メッセージを構成しなければならないProxy Binding Updateはセクション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. そのモバイルノードのためのどんな既存のBinding Update Listエントリーもなければ、Proxy Binding Updateメッセージを送るとき、モバイルアクセスゲートウェイはモバイルノードのためのBinding Update Listエントリーを作成しなければなりません。
6.9.1.2. Receiving Proxy Binding Acknowledgement
6.9.1.2. プロキシの拘束力がある承認を受けます。
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.
地元の移動性アンカーからProxy Binding Acknowledgementメッセージ(セクション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. 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.
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. 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.
Gundavelli, et al. Standards Track [Page 51] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli, et al. Standards Track [Page 51] RFC 5213 Proxy Mobile IPv6 August 2008
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. 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.
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. 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.
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. 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.
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. 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.
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. 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.
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. 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.
Gundavelli, et al. Standards Track [Page 52] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli, et al. Standards Track [Page 52] RFC 5213 Proxy Mobile IPv6 August 2008
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. 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.
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. 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.
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. 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.
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. 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.
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. 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.
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. 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.
Gundavelli, et al. Standards Track [Page 53] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli, et al. Standards Track [Page 53] RFC 5213 Proxy Mobile IPv6 August 2008
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. 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.
6.9.1.3. Extending Binding Lifetime
6.9.1.3. Extending Binding Lifetime
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. 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.
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. 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.
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. The Handoff Indicator field in the Handoff Indicator option MUST be set to a value of 5 (Handoff state not changed - Re- Registration).
6.9.1.4. Mobile Node Detachment and Binding De-Registration
6.9.1.4. Mobile Node Detachment and Binding De-Registration
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. 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.
Gundavelli, et al. Standards Track [Page 54] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli, et al. Standards Track [Page 54] RFC 5213 Proxy Mobile IPv6 August 2008
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. 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.
3. The Handoff Indicator field in the Handoff Indicator option MUST
be set to a value of 4 (Handoff state unknown).
3. The Handoff Indicator field in the Handoff Indicator option MUST be set to a value of 4 (Handoff state unknown).
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:
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:
1. It MUST remove the Binding Update List entry for the mobile node
from its Binding Update List.
1. It MUST remove the Binding Update List entry for the mobile node from its Binding Update List.
2. It MUST remove the created routing state for tunneling the mobile
node's traffic.
2. It MUST remove the created routing state for tunneling the mobile node's traffic.
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. 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.
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. 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.
6.9.1.5. Constructing the Proxy Binding Update Message
6.9.1.5. Constructing the Proxy Binding Update Message
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 The mobile access gateway, when sending the Proxy Binding Update message to the local mobility anchor, MUST construct the message as specified below.
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)
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
Figure 12: Proxy Binding Update Message Format
Gundavelli, et al. Standards Track [Page 55] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli, et al. Standards Track [Page 55] RFC 5213 Proxy Mobile IPv6 August 2008
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 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 The Destination Address field in the IPv6 header of the message
MUST be set to the local mobility anchor address.
o The Destination Address field in the IPv6 header of the message MUST be set to the local mobility anchor address.
o The Mobile Node Identifier option [RFC4283] MUST be present.
o The Mobile Node Identifier option [RFC4283] MUST be present.
o At least one Home Network Prefix option MUST be present.
o At least one Home Network Prefix option MUST be present.
o The Handoff Indicator option MUST be present.
o The Handoff Indicator option MUST be present.
o The Access Technology Type option MUST be present.
o The Access Technology Type option MUST be present.
o The Timestamp option MAY be present.
o The Timestamp option MAY be present.
o The Mobile Node Link-layer Identifier option MAY be present.
o The Mobile Node Link-layer Identifier option MAY be present.
o The Link-local Address option MAY be present.
o The Link-local Address option MAY be present.
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 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 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 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.
6.9.2. Router Solicitation Messages
6.9.2. Router Solicitation Messages
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.
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.
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
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
Gundavelli, et al. Standards Track [Page 56] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli, et al. Standards Track [Page 56] RFC 5213 Proxy Mobile IPv6 August 2008
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.
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.
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. または、モバイルアクセスゲートウェイがいかなる理由でも拘束力がある登録手続を完成しなかったなら地元の移動性アンカーがProxy Binding Updateメッセージを拒絶するなら、モバイルアクセスゲートウェイはアクセスリンクを転送するというRouter Advertisementメッセージにモバイルノードのホームネットワーク接頭語(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. モバイルアクセスゲートウェイSHOULDはMTUオプションを加えます、[RFC4861]で指定されるように、アクセスリンクを転送するというRouter Advertisementメッセージに。 これは、リンクの上のモバイルノードが広告を出しているMTU値を使用するのを確実にするでしょう。 MTU値のSHOULDはモバイルアクセスゲートウェイと地元の移動性アンカーの間の双方向のトンネルにトンネルMTUを反映します。 問題、セクション6.9.5SHOULDから、トンネルMTU価値を測定しながら、申し込まれてください。
6.9.3. Default-Router
6.9.3. デフォルトルータ
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.
ProxyのモバイルIPv6では、モバイルアクセスゲートウェイはアクセスでのモバイルノードのためのデフォルトルータがリンクするIPv6です。 しかしながら、モバイルノードが別のものへの1個のアクセスリンクから移行するとき、それらのそれぞれのリンクの上の給仕モバイルアクセスゲートウェイはRouter Advertisementメッセージを送るでしょう。 これらのRouter Advertisementsに異なったリンクローカルアドレスか異なったリンクレイヤアドレスを使用させると、モバイルノードはあらゆる移管の後にいつも新しいデフォルトルータを検出するでしょう。 この問題を解決するために、この仕様はリンク地方で同じくらい使用するためにProxyのモバイルIPv6ドメインのすべてのモバイルアクセスゲートウェイを必要として、アクセスのどれかに関するリンクレイヤアドレスはどこでも、モバイルノードが付くところにリンクされます。 これらのアドレスは全体のProxyモバイルIPv6ドメイン中の定番地であるかもしれません、そして、すべてのモバイルアクセスゲートウェイがポイントツーポイント接続のどれかに関するアドレスがグローバルに修理されたこれらを使用できます。 構成変数のFixedMAGLinkLocalAddressOnAllAccessLinksとFixedMAGLinkLayerAddressOnAllAccessLinks SHOULD、このために使用されてください。 さらに、地元の移動性アンカーは、この仕様から、リンクローカルアドレスを生成して、シグナリングメッセージの一部としてモバイルアクセスゲートウェイにそれを供給します。
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
しかしながら、これらのアプローチ(地元の移動性アンカーかいつまでにグローバルに固定されたリンクローカルアドレスを使用することで生成されたリンクローカルアドレス)の両方がSEcure Neighborディスカバリー(SEND)[RFC3971]の展開に意味を持っています。 そしてSENDでは、ルータが証明書を持っている。
Gundavelli, et al. Standards Track [Page 57] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[57ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
公開鍵は対にされます、そして、それらのRouter Advertisementsはこれらの主要な組の秘密鍵を契約されます。 多くの異なったルータが同じアドレスを使用すると、すべてが同じ主要な組か、中古の主要な組とルータの暗号のアイデンティティのためにこれらの署名を構成できるように持っているルータは動きの後に変化しなければなりません。 両方のアプローチは問題が多いです。 PMIP6ドメインの複数のノードの向こう側に秘密鍵情報を共有するのは、セキュリティ見解からの貧しいデザインです。 そして、ルータの暗号のアイデンティティさえ変えると、ホストには、できるだけ目に見えないProxyモバイル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.
しかしながら、SEND仕様を改訂するために、進行中の仕事がIETFにあります。 また、これらの改正がその上の問題を訴えることが提案されます。 他の改正が、SENDの広い普及の展開の前に他の問題の多いケース(Neighborディスカバリープロキシなどの)に対処するのに必要です。
6.9.4. Retransmissions and Rate Limiting
6.9.4. Retransmissionsとレート制限
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.
モバイルアクセスゲートウェイは発信するというProxy Binding Updateメッセージを地元の移動性アンカーに制限する「再-トランスミッション」とレートに原因となります。 RetransmissionとRate Limiting規則が[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. モバイルアクセスゲートウェイがProxy Binding Updateメッセージを送るとき、定数を使用するべきです、INITIAL_BINDACK_TIMEOUT[RFC3775]、再送信タイマーを構成するために、セクション11.8[RFC3775]で指定されるように。 しかしながら、モバイルアクセスゲートウェイはInitialBindackTimeoutFirstRegの、より長い再送信間隔を費やす必要はありません、[RFC3775]で指定されるように、初期のProxy Binding Updateメッセージのために。
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. ゲートウェイはモバイルアクセスであるなら再送信間隔中に登録か再登録メッセージのための有効な合っている応答を受けません、それ。SHOULDは受けられた応答までメッセージを再送します。 しかしながら、モバイルアクセスゲートウェイは、メッセージを再送する前にモバイルノードがまだ接続リンクに添付されているのを確実にしなければなりません。
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で指定されるように、モバイルアクセスゲートウェイはタイムアウト時間が各「再-トランスミッション」で倍にされる指数の下に後部プロセスを使用しなければなりません、ノードが応答を受けるか、またはタイムアウト時間が値のマックス_BINDACK_TIMEOUT[RFC3775]に達するまで。 モバイルアクセスゲートウェイは、このより遅いレートでこれらのメッセージを無期限に送り続けるかもしれません。
Gundavelli, et al. Standards Track [Page 58] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[58ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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. Timestampベースの体系が使用中であるなら、再送されたProxy Binding Updateメッセージは最新のタイムスタンプを使用しなければなりません。 Sequence Number体系が使用中であるなら、再送されたProxy Binding Updateメッセージは[RFC3775]のそれがこのProxy Binding Updateメッセージの前の伝達に使用されたよりちょうど指定されるとして優れたSequence Number値を使用しなければなりません。
6.9.5. Path MTU Discovery
6.9.5. 経路MTU発見
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.
そのモバイルノード、モバイルアクセスゲートウェイ、および地元の移動性アンカーにはMTUsの正しい理解があるのは、重要です。 モバイルノードが正しい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 地元の移動性アンカーとモバイルアクセスゲートウェイはPath MTU発見メカニズムを使用するかもしれません、[RFC1981]か[RFC4821]で指定されるように、Path MTU(PMTU)を(LMA-MAG)経路に決定するために。 与えられた展開に使用されるべき特定の発見メカニズムは構成可能である場合があります。
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 移動性実体は実装しなければなりません、そして、SHOULDは[RFC1981]で指定されるようにICMPベースのPath MTUが発見メカニズムであるとサポートします。 しかしながら、ProxyのモバイルIPv6ネットワークがICMP Packet Too Bigメッセージを提供もしませんし、処理もしないなら、このメカニズムは正しく動作しないかもしれません。
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]で指定されるようにPacketization Layer Path MTU発見がメカニズムであると実装して、PMTU発見にペイロードとしてどんなアプリケーショントラフィックも使用するかもしれません。 容易にこのためにモバイルアクセスゲートウェイと地元の移動性エージェントの間のProxyのモバイルIPv6プロトコルもトンネルも使用できません。 しかしながら、実装SHOULDはこのために少なくとも明白なICMP Echo Request/応答の使用をサポートします。
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発見を実行するのを選んで、Path MTU値がそれらの経路に変化していないのを保証するために定期的にこの操作を繰り返すかもしれません。 ダイナミックなPMTU発見メカニズムがPath MTUを決定しないなら、行政上構成されたデフォルト値を使用しなければなりません。
Gundavelli, et al. Standards Track [Page 59] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[59ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 その特定の経路への決定しているPath MTU値に基づいて地元の移動性アンカーとモバイルアクセスゲートウェイの間の確立したトンネルへのIPv6トンネル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 それがアクセスリンクの上のRouter Advertisementsで送るMTUオプションにおけるMTU値がモバイルノードと共有されたようにモバイルアクセスゲートウェイSHOULDは決定しているトンネルPath MTU価値(モバイルノードの地元の移動性アンカーと共に確立されたトンネルへの)を使用します。 しかし、モバイルノードと共有されたアクセスリンクのMTU値が決定しているPath 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下側の)SHOULDを評価します。送付の追加Router Advertisementメッセージによって影響を与えられたモバイルノードに通知されてください。 さらに、また、すべてのその後のRouter Advertisementメッセージで調整されたトンネルMTU価値を使用しなければなりません。
6.10. Routing Considerations
6.10. ルート設定問題
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
プロキシ-CoA LMAA| | +--+ +---+ +---+ +--+ |ミネソタ|----------|雑誌|======================|LMA|----------|CN| +--+ +---+ +---+ +--+ IPv6トンネル
Figure 13: Proxy Mobile IPv6 Tunnel
図13: プロキシのモバイルIPv6トンネル
6.10.1. Transport Network
6.10.1. 転送ネットワーク
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輸送を交渉するための必要な拡大と対応するカプセル化モードを指定します。
Gundavelli, et al. Standards Track [Page 60] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[60ページ]RFC5213のプロキシのモバイルIPv6 August 2008
6.10.2. Tunneling and Encapsulation Modes
6.10.2. トンネリングとカプセル化モード
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]はホームのエージェントとモバイルノードの間で[RFC2473]にトンネルを堀りながら、IPv6過剰IPv6の使用を定義します、そして、この仕様は同じトンネリングメカニズムの地元の移動性アンカーとモバイルアクセスゲートウェイの間の使用の使用を広げています。
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).
どんな地元の移動性アンカーにも二地点間トンネルを作成するために、モバイルアクセスゲートウェイはグローバルアドレスへの出口のインタフェース(プロキシ-CoA)のSource Address分野セットと地方の移動性アンカー(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のIPv6--IPv6データグラムはIPv6パケット[RFC2473]で要約されました。
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 IPv4のIPv6--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 IPv4-UDPのIPv6--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 IPv4-UDP-TLVのIPv6--TLVヘッダーがあるIPv4 UDPパケットのIPv6データグラムカプセル化。 このモードは[IPV4-PMIP6]で指定されます。
Gundavelli, et al. Standards Track [Page 61] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[61ページ]RFC5213のプロキシのモバイルIPv6 August 2008
6.10.3. Local Routing
6.10.3. 地方のルート設定
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.
訪問のモバイルノードと局所的にモバイルアクセスゲートウェイに接続されたアクセスリンクに添付される通信員ノードの間には、データ通信量があれば、モバイルノードの地元の移動性アンカーにそれらにトンネルを堀って、モバイルアクセスゲートウェイは配送取り組みで局所的にパケットを発送して、どんな逆によっても最適化されないかもしれません。 旗の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.
モバイルアクセスゲートウェイの上で構成された方針に基づきましたが、モバイルノードの地元の移動性アンカーによって実施された経路最適化SHOULDのこの決定。 これがどう達成されるかに関する特定の詳細は向こうのこのドキュメントの範囲のものです。
6.10.4. Tunnel Management
6.10.4. トンネル管理
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で言及したすべての問題がまた、モバイルアクセスゲートウェイに申し込みます。
6.10.5. Forwarding Rules
6.10.5. 推進規則
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 モバイルノードの地元の移動性アンカーと共に確立された双方向のトンネルからパケットを受けると、モバイルアクセスゲートウェイは、インタフェースでそれを進めるのに送信先ネットワーク接頭語がホスティングされるところで内側のパケットの送付先アドレスを使用しなければなりません。 パケットを進める前に、モバイルアクセスゲートウェイは外側のヘッダーを取り除かなければなりません。 IPv6被膜剥離術のために[RFC2473]からの問題を適用しなければなりません。 モバイルアクセスゲートウェイがその送付先アドレスに関して接続インタフェースに当たることができないなら、それは静かにパケットを下げなければなりません。 そのようなシナリオ、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
o レギュラーのIPv6ホスト(セクション6.14を見る)が運命づけたのでモバイルアクセスゲートウェイに接続される通信員ノードからモバイルまた、局所的に添付されるノードまでパケットを受けると、モバイルアクセスゲートウェイは、直接モバイルノードにパケットを提供できるかどうか決定するために旗のEnableMAGLocalRoutingをチェックしなければなりません。 モバイルアクセスゲートウェイはルートに許容されていません。
Gundavelli, et al. Standards Track [Page 62] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[62ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
パケット、直接、地元の移動性アンカーに向かったパケットを送付先アドレスが位相的に据えつけられるところに発送しなければならなくて、ほかに、直接モバイルノードにパケットを発送できます。
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 局所的につなげられる目的地のためにアクセスリンクに接続されたモバイルノードからパケットを受けると、モバイルアクセスゲートウェイは、モバイルアクセスゲートウェイが直接目的地にパケットを発送できるのを保証するために旗のEnableMAGLocalRoutingをチェックしなければなりません。 モバイルアクセスゲートウェイが直接パケットを発送できないなら、それはそれ自体とモバイルノードの地元の移動性アンカーの間で確立された双方向のトンネルを通ってパケットを発送しなければなりません。 さもなければ、それは直接目的地にパケットを発送しなければなりません。
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 アクセスリンクに接続されたモバイルノードから直接つなげられない目的地までパケットを受けると、それ自体とモバイルノードの地元の移動性アンカーの間で確立された両性愛者の方向のトンネルを通して地元の移動性アンカーにパケットを送らなければなりません。 しかしながら、リンク地元筋アドレスと共に送られるパケットを進めてはいけません。
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 トンネルを堀られたパケットの書式は以下に示されます。 IPv6カプセル化のために[RFC2473]からの問題を適用しなければなりません。 しかしながら、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*/
IPv6ヘッダー、(srcはプロキシ-CoAと等しいです、dst= LMAA/*トンネルHeader*/IPv6ヘッダー(srcはミネソタ-HoAと等しいです、dst= CN)/*パケットHeader*/覚醒剤層のプロトコル/*パケットContent*/
Figure 14: Tunneled Packet from MAG to LMA
図14: トンネルを堀られた雑誌から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]で説明されるようにあります。
Gundavelli, et al. Standards Track [Page 63] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[63ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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*/
IPv6ヘッダー、(srcはプロキシ-CoAと等しいです、トンネルモード/*超能力Header*/IPv6ヘッダー(srcはミネソタ-HoAと等しいです、dst= CN)/*パケットHeader*/覚醒剤層のプロトコル/*パケットContent*/のdst= LMAA/*トンネルHeader*/超能力Header
Figure 15: Tunneled Packet from MAG to LMA with Payload Protection
図15: 有効搭載量保護があるトンネルを堀られた雑誌からLMAまでのパケット
6.11. Supporting DHCP-Based Address Configuration on the Access Link
6.11. アクセスリンクの上にDHCPベースのアドレスが構成であるとサポートします。
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.
このセクションはProxyのモバイルIPv6ドメインでどうDHCPサポートを使用するStateful Address Configurationを有効にすることができるかを説明します。 それは、また、このアドレスが構成モードであるとサポートするために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を使用することでStateful Address Configurationをサポートするのにおいて、ProxyのモバイルIPv6ドメインのすべてのモバイルアクセスゲートウェイの上でDHCP中継エージェント[RFC3315]サービスをサポートしなければなりません。 さらに、DHCP中継エージェントは、必要に応じて与えられた展開にユニキャストアドレス、All_DHCP_Serversマルチキャストアドレス、または他のアドレスを含むかもしれない送付先アドレスのリストを使用するために[RFC3315]のセクション20で指定されるように構成されるべきです。
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インフラストラクチャは、そのProxyのモバイルIPv6ドメインのリンクに割り当てられたそれぞれの接頭語からのアドレスを割り当てるために構成される必要があります。 DHCP中継エージェントはRelay Forwardメッセージのリンクアドレス分野のそのリンクに割り当てられた接頭語のいずれからもモバイルノードが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;
* モバイルノードが各リンクに関連している接頭語のリストのRelay Forwardメッセージのリンクアドレス分野に接頭語を調べることによって添付されるリンクを特定してください。
* 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ネットワークと同じです。 モバイルノードから異なった中継エージェントまでDHCPメッセージを受け取るのを除いて、時間、DHCPインフラストラクチャの上の(MAGs)はモバイルノードの能力で移動性サポートに関して気づかなくなるでしょう。
Gundavelli, et al. Standards Track [Page 64] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[64ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 地元の移動性アンカーはProxyのモバイルIPv6ドメインで関連接頭語に伴うリンクに関して同じ認識を必要とします。 地元の移動性アンカーが接頭語(es)をモバイルノードに割り当てるとき、与えられたリンクに関連しているすべての接頭語を割り当てなければなりません、そして、接頭語が割り当てられたそれらはすべて、その移動性セッションの寿命の間中そのモバイルノードのためのホームネットワーク接頭語として残るでしょう。 これらの接頭語をホスティングする給仕モバイルアクセスゲートウェイは、物理的にそのリンクに接続されて、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]の1つからの自動構成アドレスを作ることができて、このアドレスリンクアドレスオプションを使用できます、リンク識別のためにヒントをDHCP Serverに供給するために。 モバイルノードから要求を受け取るとき、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リースを広げるためにいったんアドレス(es)を得て、異なったリンクに移行して、(いつでも)DHCP要求を送ると、新しいリンクの上のDHCP中継エージェントはモバイルノードのホームネットワーク接頭語の1つへのDHCP Relay Forwardメッセージにリンクアドレス分野をはめ込むでしょう。 DHCPサーバは、Client-DUIDオプションからクライアントを特定して、要求の現在のリンクアドレスオプションからリンクを特定して、従来と同様、同じアドレス(es)を割り当てるでしょう。
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
o ホストが少しの移動性管理にも参加しないネットワークを拠点とする移動性管理のモデルの正しい操作において、モバイルノードが付けているアクセスリンクにかかわらず同じIPv6アドレスをモバイルノードにいつも割り当てなければなりません。 例えば、モバイルアクセスゲートウェイ
Gundavelli, et al. Standards Track [Page 65] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[65ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
ProxyのモバイルIPv6では、ドメインは、モバイルノードからのDHCPメッセージがいつも同じDHCPサーバかサーバによって扱われるように、そのドメインに役立つ連携DHCPサーバの同じグループから構成されるべきです。 DHCPベースのアドレス構成は地元の移動性アンカーとモバイルアクセスゲートウェイが異なった管理ドメインに位置している展開のために推薦されません。
6.12. Home Network Prefix Renumbering
6.12. ホームネットワーク接頭語の番号を付け替えること
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)が中央の間、番号を付け替えられて、無効になるなら、移動性セッション、ゼロとのアクセスリンクにRouter Advertisementメッセージを送って、ゲートウェイが接頭語(es)を引き下がらせなければならないモバイルアクセスでは、番号を付け替えられている接頭語(es)のための生涯を前に置いてください。 また、地元の移動性アンカーとモバイルアクセスゲートウェイは番号を付け替えている接頭語(es)のために作成されたルーティング状態を削除しなければなりません。 しかしながら、このドキュメントの範囲の外に地元の移動性アンカーがモバイルノードのホームネットワーク接頭語(es)の番号を付け替えるのに関してどうモバイルアクセスゲートウェイに通知するかに関する特定の詳細があります。
6.13. Mobile Node Detachment Detection and Resource Cleanup
6.13. モバイルノード分離検出とリソースクリーンアップ
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.
以前、モバイルノードの現在既存の製本の生涯、モバイルアクセスゲートウェイが確実にモバイルノードを作らなければならない広げるために地元の移動性アンカーにProxy Binding Updateメッセージを送るのは、何らかの確かな方法を使用することによって、まだ接続リンクに付けられています。 モバイルアクセスゲートウェイが予想どおりに接続リンクの上のモバイルノードの存在を検出できないなら、それは、モバイルノードの登録生涯を広げるのを試みてはいけません。 さらに、そのようなシナリオでは、モバイルアクセスゲートウェイSHOULDは、0への生涯選択値群でモバイルノードの地元の移動性アンカーにProxy Binding Updateメッセージを送ることによって、モバイルノードの製本を終えます。 また、それはそのモバイルノードのために作成されたBinding Update Listエントリーなどの地方のどんな状態も取り除かなければなりません。
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:
接続リンクにおける訪問のモバイルノードの損失の特定の検出メカニズムは、モバイルノードとモバイルアクセスゲートウェイとのアクセスリンクに特定であり、このドキュメントの範囲の外にあります。 通常、モバイルアクセスゲートウェイがノードの損失を検出するために依存できるそれぞれのアクセス技術に特定の様々なリンク層の詳細イベントがあります。 一般に、モバイルアクセスゲートウェイを接続リンクの上のモバイルノードの検出存在のために以下のメソッドの1つ以上に依存できます:
Gundavelli, et al. Standards Track [Page 66] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[66ページ]RFC5213のプロキシのモバイルIPv6 August 2008
o Link-layer event specific to the access technology
o アクセス技術に特定のリンクレイヤイベント
o Session termination event on point-to-point link types
o 二地点間リンク型の上のセッション終了イベント
o IPv6 Neighbor Unreachability Detection event from IPv6 stack
o IPv6スタックからのIPv6 Neighbor Unreachability Detectionイベント
o Notification event from the local mobility anchor
o 地元の移動性アンカーからの通知イベント
6.14. Allowing Network Access to Other IPv6 Nodes
6.14. 他のIPv6ノードへのネットワークアクセスを許します。
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.
いくつかのProxyのモバイル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であるなら可能にされます、モバイルノードSHOULD。正常なIPv6アドレス構成手順を使用することでIPv6アドレス(es)を得ることができてください。 得られたアドレス(es)は地方の訪問者ネットワーク接頭語(es)から来ているに違いありません。 これは、モバイルノードへの正常なアクセスルータがアクセスリンクに付いてホストベースの移動性に影響を与えることのないモバイルアクセスゲートウェイ機能が操作について議定書の中で述べるのを本質的には確実にします。
7. Mobile Node Operation
7. モバイルノード手術
This non-normative section explains the mobile node's operation in a Proxy Mobile IPv6 domain.
この非標準のセクションはProxyのモバイルIPv6ドメインでモバイルノードの操作について説明します。
7.1. Moving into a Proxy Mobile IPv6 Domain
7.1. プロキシのモバイル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
モバイルノードがProxyのモバイルIPv6ドメインに入って、アクセスネットワークに付くと、アクセスリンクの上のモバイルアクセスゲートウェイは、モバイルノードの付属を見つけて、結合を終了します。
Gundavelli, et al. Standards Track [Page 67] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[67ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
モバイルノードの地元の移動性アンカーとの登録。 拘束力があるアップデート操作が首尾よく実行されると、モバイルアクセスゲートウェイは、モバイルノードのデータ通信量のために必要な状態を創設して、推進にセットするでしょう。
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.
モバイルノードがアクセスリンクに付くと、それはRouter Solicitationメッセージ[RFC4861]を通常送るでしょう。 アクセスリンクの上のモバイルアクセスゲートウェイはRouter AdvertisementメッセージでRouter Solicitationメッセージに応じるでしょう。 Router Advertisementメッセージはモバイルノードのホームネットワーク接頭語(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.
アクセスでのモバイルアクセスゲートウェイであるなら、リンクはモバイルノードからRouter Solicitationメッセージを受け取ります、モバイルノードの地元の移動性アンカーと共にシグナリングを完成する前にモバイルアクセスゲートウェイは、モバイルノードのホームネットワーク接頭語(es)を知らないで、アクセスリンクの上のモバイルノードのホームのリンクを見習うことができないかもしれません。 そのようなシナリオでは、Router Advertisementメッセージを受け取る前にモバイルノードは遅れに気付くかもしれません。 また、これはそれら自身の移動性を扱うことができるモバイルノード、または動きで同じ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).
受信されたRouter AdvertisementメッセージでManaged Address Configuration旗を設定すると、モバイルノードは通常、するようにDHCP Request[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.
モバイルノードが受信されたRouter AdvertisementメッセージでManaged Address Configuration旗を設定しないで、自動構成されたアドレス(es)を使用できると、モバイルノードは、それぞれのホームネットワーク接頭語からそのモードのために受入れられた標準のIPv6アドレス構成メカニズムのどれかを使用することでIPv6アドレス(es)を得ることができるでしょう。
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アドレス構成を得ることができるでしょう、仲間ドキュメント[IPV4-PMIP6]で指定されるように。
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.
アドレス構成がいったん完全になると、モバイルノードは、それがそのProxyのモバイルIPv6ドメインの範囲にあるネットワークに付けられている限り、このアドレス構成を使用し続けることができます。
Gundavelli, et al. Standards Track [Page 68] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[68ページ]RFC5213のプロキシのモバイルIPv6 August 2008
7.2. Roaming in the Proxy Mobile IPv6 Domain
7.2. プロキシのモバイル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.
モバイルノードがもう片方への1モバイルアクセス門から接着点を動かして、変えながらProxyのモバイルIPv6ドメインでアドレス構成を得た後に、それは、まだ同じアドレス構成を使用してい続けることができます。 付属アクセスリンクがそのProxyのモバイルIPv6ドメインの範囲にある限り、モバイルノードは、いつもデフォルトルータとモバイルノードのホームネットワークの広告を出すとそれぞれの接続リンクの(es)が前に置かれて同じルータが自分を売り込むのを検出するでしょう。 アドレス構成を保有して、モバイルノードにそれが得たアドレス構成がDHCPを使用することであると、広がることができる、生涯を賃貸してください。
8. Message Formats
8. メッセージ・フォーマット
This section defines extensions to the Mobile IPv6 [RFC3775] protocol messages.
このセクションはモバイルIPv6[RFC3775]プロトコルメッセージと拡大を定義します。
8.1. Proxy Binding Update Message
8.1. プロキシの拘束力があるアップデートメッセージ
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 .
. .
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P| 予約されます。| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
モバイルアクセスゲートウェイによって地元の移動性アンカーに送られるBinding Updateメッセージは「プロキシの拘束力があるアップデート」メッセージと呼ばれます。 新しい旗(P)はBinding Updateメッセージに含まれています。 Binding Updateメッセージ・フォーマットの残りは[RFC3775]と追加(R)と(M)旗で定義されるように同じままで残っています、[RFC3963]と[RFC4140]でそれぞれ指定されるように。
Gundavelli, et al. Standards Track [Page 69] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[69ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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)はBinding Updateメッセージがプロキシ登録であることを地元の移動性アンカーに示すBinding Updateメッセージに含まれています。 旗をプロキシ登録証明書のために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.
完全なMobility Headerが長い間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.
この仕様に従って、以下の移動性オプションはProxy Binding Updateメッセージで有効です。 これらのオプションは順不同なメッセージに存在している場合があります。 メッセージの現在のホームNetwork Prefixオプションの1つ以上のインスタンスがあることができます。 しかしながら、以下のオプションのどれかの1つ以上のインスタンスがあるはずがありません。
Mobile Node Identifier option
モバイルNode Identifierオプション
Home Network Prefix option
ホームNetwork Prefixオプション
Handoff Indicator option
移管Indicatorオプション
Access Technology Type option
アクセスTechnology Typeオプション
Timestamp option
タイムスタンプオプション
Mobile Node Link-layer Identifier option
モバイルNode Link-層のIdentifierオプション
Link-local Address option
リンクローカルのAddressオプション
Additionally, there can be one or more instances of the Vendor-
Specific Mobility option [RFC5094].
さらに、Vendorの特定のMobilityオプション[RFC5094]の1つ以上のインスタンスがあることができます。
For descriptions of other fields present in this message, refer to Section 6.1.7 of [RFC3775].
このメッセージの現在の他の分野の記述について、.7セクション6.1[RFC3775]を参照してください。
Gundavelli, et al. Standards Track [Page 70] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[70ページ]RFC5213のプロキシのモバイルIPv6 August 2008
8.2. Proxy Binding Acknowledgement Message
8.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態|K|R|P|予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 系列#| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . 移動性オプション…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
地元の移動性アンカーによってモバイルアクセスゲートウェイに送られるBinding Acknowledgementメッセージは「プロキシの拘束力がある承認」メッセージと呼ばれます。 新しい旗(P)はBinding Acknowledgementメッセージに含まれています。 Binding Acknowledgementメッセージ・フォーマットの残りは[RFC3775]、そして、指定されるとしての追加(R)旗が[RFC3963]にある状態で定義されるように同じままで残っています。
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)は対応するProxy Binding Updateメッセージを処理した地元の移動性アンカーがプロキシに登録証明書をサポートするのを示すBinding Acknowledgementメッセージに含まれています。 対応するProxy Binding UpdateがProxy Registration Flag(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.
完全なMobility Headerが長い間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
この仕様に従って、以下の移動性オプションはProxy Binding Acknowledgementメッセージで有効です。 これらのオプションは順不同なメッセージに存在している場合があります。 または1つがあることができる。
Gundavelli, et al. Standards Track [Page 71] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[71ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
メッセージの現在のホームNetwork Prefixオプションの、より多くのインスタンス。 しかしながら、以下のオプションのどれかの1つ以上のインスタンスがあるはずがありません。
Mobile Node Identifier option
モバイルNode Identifierオプション
Home Network Prefix option
ホームNetwork Prefixオプション
Handoff Indicator option
移管Indicatorオプション
Access Technology Type option
アクセスTechnology Typeオプション
Timestamp option
タイムスタンプオプション
Mobile Node Link-layer Identifier option
モバイルNode Link-層のIdentifierオプション
Link-local Address option
リンクローカルのAddressオプション
Additionally, there can be one or more instances of the Vendor-
Specific Mobility option [RFC5094].
さらに、Vendorの特定のMobilityオプション[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.
Proxy Binding Updateの気質を示す8ビットの符号のない整数。 128未満のStatus分野の値は、Proxy Binding Updateが地元の移動性アンカーによって受け入れられたのを示します。 値より多くの128は、Proxy Binding Updateメッセージが地元の移動性アンカーによって拒絶されたのを示します。 セクション8.9はProxy Binding Acknowledgementメッセージで使用されて、そうすることができるStatus値を定義します。
For descriptions of other fields present in this message, refer to Section 6.1.8 of [RFC3775].
このメッセージの現在の他の分野の記述について、.8セクション6.1[RFC3775]を参照してください。
8.3. Home Network Prefix Option
8.3. ホームネットワーク接頭語オプション
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.
新しいオプション、ホームNetwork Prefixオプションは使用のために地元の移動性アンカーとモバイルアクセスゲートウェイの間でProxy Binding UpdateとProxy Binding Acknowledgementメッセージを交換している状態で定義されます。 このオプションは、モバイルノードのホームネットワーク接頭語情報を交換するのに使用されます。 メッセージの現在の複数のホームNetwork Prefixオプションがあることができます。
The Home Network Prefix Option has an alignment requirement of 8n+4. Its format is as follows:
ホームNetwork Prefix Optionには、8n+4の整列要求があります。 形式は以下の通りです:
Gundavelli, et al. Standards Track [Page 72] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[72ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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ホームNetwork Prefixを含む16バイトの分野。
8.4. Handoff Indicator Option
8.4. 移管インディケータオプション
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.
新しいオプション、Handoff Indicatorオプションは使用のために地元の移動性アンカーとモバイルアクセスゲートウェイの間でProxy Binding UpdateとProxy Binding Acknowledgementメッセージを交換している状態で定義されます。 このオプションは、モバイルノードの移管関連のヒントを交換するのに使用されます。
Gundavelli, et al. Standards Track [Page 73] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[73ページ]RFC5213のプロキシのモバイルIPv6 August 2008
The Handoff Indicator option has no alignment requirement. Its format is as follows:
Handoff Indicatorオプションには、整列要求が全くありません。 形式は以下の通りです:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約された(R)| こんにちは| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
移管インディケータ(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に関する付属: モバイルノード3の2つの異なったインタフェースの間の移管: 同じインタフェース4へのモバイルアクセスゲートウェイの間の移管: 移管州未知の5: 移管状態は変化しませんでした。(再登録)
8.5. Access Technology Type Option
8.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.
新しいオプション、Access Technology Typeオプションは使用のために地元の移動性アンカーとモバイルアクセスゲートウェイの間でProxy Binding UpdateとProxy Binding Acknowledgementメッセージを交換している状態で定義されます。 このオプションは、モバイルノードが現在モバイルアクセスゲートウェイに添付されるアクセス技術のタイプを交換するのに使用されます。
Gundavelli, et al. Standards Track [Page 74] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[74ページ]RFC5213のプロキシのモバイルIPv6 August 2008
The Access Technology Type Option has no alignment requirement. Its format is as follows:
Access Technology Type Optionには、整列要求が全くありません。 形式は以下の通りです:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約された(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: IEEE802.3(「イーサネット」)4: IEEE 802.11a/b/g(「ワイヤレスのLAN」)5: IEEE 802.16e("WIMAX")
Gundavelli, et al. Standards Track [Page 75] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[75ページ]RFC5213のプロキシのモバイルIPv6 August 2008
8.6. Mobile Node Link-layer Identifier Option
8.6. モバイルノードリンクレイヤ識別子オプション
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.
新しいオプション、モバイルNode Link-層のIdentifierオプションは使用のために地元の移動性アンカーとモバイルアクセスゲートウェイの間でProxy Binding UpdateとProxy Binding Acknowledgementメッセージを交換している状態で定義されます。 このオプションは、モバイルノードのリンクレイヤ識別子を交換するのに使用されます。
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].
Link-層のIdentifierオプションの書式は以下に示されます。 識別子のサイズに基づいて、適切にオプションを並べなければなりません、[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 +
. ... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
この分野(バイトと噛み付いている注文を含んでいる)の内容と形式が[RFC4861]のセクション4.6でリンクレイヤアドレスを運ぶのに指定されるようにあります。 あるアクセスリンクの上では、このオプションを使用できません。そこでは、リンクレイヤアドレスは、使用されていないか、または決定できません。
Gundavelli, et al. Standards Track [Page 76] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[76ページ]RFC5213のプロキシのモバイルIPv6 August 2008
8.7. Link-local Address Option
8.7. リンクローカルアドレスオプション
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ローカルのAddressオプションは使用のために地元の移動性アンカーとモバイルアクセスゲートウェイの間でProxy Binding UpdateとProxy Binding Acknowledgementメッセージを交換している状態で定義されます。 このオプションは、モバイルアクセスゲートウェイのリンクローカルアドレスを交換するのに使用されます。
The Link-local Address option has an alignment requirement of 8n+6. Its format is as follows:
Linkローカルの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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
リンクローカルアドレスを含む16バイトの分野。
8.8. Timestamp Option
8.8. タイムスタンプオプション
A new option, Timestamp option is defined for use in the Proxy Binding Update and Proxy Binding Acknowledgement messages.
新しいオプションであり、TimestampオプションはProxy Binding UpdateとProxy Binding Acknowledgementメッセージにおける使用のために定義されます。
The Timestamp option has an alignment requirement of 8n+2. Its format is as follows:
Timestampオプションには、8n+2の整列要求があります。 形式は以下の通りです:
Gundavelli, et al. Standards Track [Page 77] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[77ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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日、協定世界時0時0分以来の秒数を示します。 この形式では、整数秒数は分野の最初の48ビットに含まれています、そして、残っている16ビットは1秒の1/65536の何分の一の数を示します。
8.9. Status Values
8.9. 状態値
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].
このドキュメントはProxy Binding Acknowledgementメッセージにおける使用のために以下の新しいStatus値を定義します。 これらの値は.8セクション6.1[RFC3775]で定義されるように同じ数のスペースから割り当てることです。
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は、Proxy Binding Updateメッセージが地元の移動性アンカーによって受け入れられたのを示します。 状態値より多くの128は、Proxy Binding Updateが地元の移動性アンカーによって拒絶されたのを示します。
PROXY_REG_NOT_ENABLED: 152
どんな_も有効にしなかったプロキシ_レッジ_: 152
Proxy registration not enabled for the mobile node
モバイルノードのために可能にされなかったプロキシ登録
Gundavelli, et al. Standards Track [Page 78] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[78ページ]RFC5213のプロキシのモバイルIPv6 August 2008
NOT_LMA_FOR_THIS_MOBILE_NODE: 153
__この_モバイル_ノードのためのLMA_でない: 153
Not local mobility anchor for this mobile node
このモバイルノードのための地元の移動性アンカーでない
MAG_NOT_AUTHORIZED_FOR_PROXY_REG: 154
_ではなく、雑誌_が_プロキシ_レッジのために_を認可しました: 154
The mobile access gateway is not authorized to send proxy binding
updates
モバイルアクセスゲートウェイが拘束力があるアップデートをプロキシに送るのが認可されません。
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: 155
どんな_も_ホーム_ネットワーク_接頭語のために_を認可しませんでした: 155
The mobile node is not authorized for one or more of the
requesting home network prefixes
モバイルノードは要求しているホームネットワーク接頭語の1つ以上のために認可されません。
TIMESTAMP_MISMATCH: 156
タイムスタンプ_ミスマッチ: 156
Invalid timestamp value (the clocks are out of sync)
無効のタイムスタンプ値(時計は同期しています)
TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: 157
_PREV_より低い_タイムスタンプ_は受け入れました: 157
The timestamp value is lower than the previously accepted value
タイムスタンプ値は以前に受け入れられた値より低いです。
MISSING_HOME_NETWORK_PREFIX_OPTION: 158
なくなった_ホーム_ネットワーク_接頭語_オプション: 158
Missing home network prefix option
なくなったホームネットワーク接頭語オプション
BCE_PBU_PREFIX_SET_DO_NOT_MATCH: 159
BCE_PBU_接頭語_セット_は_どんな_マッチもしません: 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
なくなった_Mn_識別子_オプション: 160
Missing mobile node identifier option
なくなったモバイルノード識別子オプション
MISSING_HANDOFF_INDICATOR_OPTION: 161
なくなった_移管_インディケータ_オプション: 161
Missing handoff indicator option
なくなった移管インディケータオプション
MISSING_ACCESS_TECH_TYPE_OPTION: 162
行方不明の_アクセス_技術者_は_オプションをタイプします: 162
Missing access technology type option
なくなったアクセス技術タイプオプション
Gundavelli, et al. Standards Track [Page 79] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[79ページ]RFC5213のプロキシのモバイルIPv6 August 2008
Additionally, the following Status values defined in [RFC3775] can also be used in a Proxy Binding Acknowledgement message.
また、さらに、Proxy Binding Acknowledgementメッセージで[RFC3775]で定義された以下のStatus値は使用できます。
0 Proxy Binding Update accepted
0 プロキシBinding Updateは受け入れました。
128 Reason unspecified
128は不特定の状態で推論します。
129 Administratively prohibited
129は行政上禁止しました。
130 Insufficient resources
130 不十分なリソース
9. Protocol Configuration Variables
9. プロトコル構成変数
9.1. Local Mobility Anchor - Configuration Variables
9.1. 地元の移動性アンカー--構成変数
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.
この変数はモバイルノードのBinding Cacheエントリーを削除する前の地元の移動性アンカーが待たなければならないミリセカンドで表現される時間に指定します、0の生涯値でモバイルアクセスゲートウェイからProxy Binding Updateメッセージを受け取ることに関して。 この待ち時間の間、地元の移動性アンカーが生涯値より多くの0で付く同じ移動性のためにProxy Binding Updateを受け取るなら、それは受け入れられた拘束力がある値で拘束力があるキャッシュエントリーをアップデートしなければなりません。 この待ち時間の終わりまでには、地元の移動性アンカーがその移動性結合へのどんな有効なProxy Binding Updateメッセージも受け取らなかったなら、それはBinding Cacheエントリーを削除しなければなりません。 この遅れは、モバイルノードのBinding Cacheエントリーがすばやく削除され過ぎるというわけではないのを本質的には確実にして、いつか、新しいモバイルアクセスゲートウェイがモバイルノードのためにシグナリングを完成するのを許容します。
The default value for this variable is 10000 milliseconds.
この変数のためのデフォルト値は10000ミリセカンドです。
Gundavelli, et al. Standards Track [Page 80] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[80ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
Proxy Binding Updatesに再送信アルゴリズムで使用されるこの値と値の間には、依存があることに注意してください。 「再-トランスミッション」は、MaxDelayBeforeNewBCEAssignがなくなる前に起こる必要があります、そうでなければ、状況が前のモバイルアクセスゲートウェイからの反-登録が失われるかもしれなくて、地元の移動性アンカーがモバイルノードのために不必要に新しい移動性セッションと新しい接頭語を作成するところにあるとき。 しかしながら、これは移動性セッションを特定するのに使用できる移管か他のパラメタのタイプに関して下層から情報が全くない状況に影響します。
TimestampValidityWindow
TimestampValidityWindow
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.
この変数は受信されたProxy Binding Updateメッセージのタイムスタンプと地元の移動性アンカーの上の現在の時刻の間でミリセカンドで最大の時間差を指定して、それは有効であると考えられるべき受信されたメッセージのために地元の移動性アンカーによって許されています。
The default value for this variable is 300 milliseconds. This
variable must be adjusted to suit the deployments.
この変数のためのデフォルト値は300ミリセカンドです。 展開に合うようにこの変数を調整しなければなりません。
9.2. Mobile Access Gateway - Configuration Variables
9.2. モバイルアクセスゲートウェイ--構成変数
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.
この旗は、モバイルアクセスゲートウェイが訪問のモバイルノードと局所的にモバイルアクセスゲートウェイのインタフェースの1つに接続される通信員ノードの間で交換されたトラフィックのローカルのルーティングを可能にすることができるかどうかを示します。 通信員ノードは、また、別の訪問のモバイルノード、またはローカルの固定ノードであるかもしれません。
Gundavelli, et al. Standards Track [Page 81] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[81ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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.
ローカルのルーティングのこの局面はモバイル基礎あたりのaに関する方針とプレゼントがいつこの旗の上に優先するかと定義されるかもしれません。
9.3. Proxy Mobile IPv6 Domain - Configuration Variables
9.3. プロキシのモバイルIPv6ドメイン--構成変数
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.
ProxyのモバイルIPv6ドメインのすべてのモバイル実体(地元の移動性アンカーとモバイルアクセスゲートウェイ)が、以下の変数がシステム管理で構成されるのを許容しなければなりません。 これらのプロトコル変数のための構成された値はサーバリブートを乗り切らなければなりません、そして、サービスは再開します。 そのドメインのすべての移動性実体で励行される同じ値をもたらす与えられたProxyモバイルIPv6ドメインにこれらの変数をグローバルに固定しなければなりません。
TimestampBasedApproachInUse
TimestampBasedApproachInUse
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.
この旗は、そのProxyのモバイルIPv6ドメインでメッセージ注文のためのタイムスタンプベースのアプローチが使用中であるかどうかを示します。 この旗のための値が1に設定されるとき、そのProxyのモバイルIPv6ドメインのすべてのモバイルアクセスゲートウェイがセクション5.5に記載されたタイムスタンプベースの問題を適用しなければなりません。 この旗の値が0に設定されるとき、セクション5.5に記載された系列番号ベースの問題を適用しなければなりません。 この旗のためのデフォルト値は1の値に設定されます、タイムスタンプベースのメカニズムがそのProxyのモバイルIPv6ドメインで使用中であることを示して。
MobileNodeGeneratedTimestampInUse
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.
この旗は、そのProxyのモバイルIPv6ドメインで作られたモバイルノードタイムスタンプアプローチが使用中であるかどうかを示します。 この旗のための値が1に設定されるとき、そのProxyのモバイル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.
タイムスタンプベースのアプローチが使用中であるときにだけ、この旗は関連しています。 この旗のための値を1の値に設定してはいけません、TimestampBasedApproachInUse旗の値が0に設定されるなら。
Gundavelli, et al. Standards Track [Page 82] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[82ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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のデフォルト、モバイルノードがタイムスタンプメカニズムを生成したのを示すのはそのProxyのモバイルIPv6ドメインで使用中ではありません。
FixedMAGLinkLocalAddressOnAllAccessLinks
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.
この変数は、すべてのモバイルアクセスゲートウェイSHOULDがアクセスリンクのいずれでも使用するリンクローカルアドレス値がそのProxyのモバイルIPv6ドメインでモバイルノードのどれかと共有されたのを示します。 この変数がすべての_ZERO価値に初期化されるなら、それは、固定リンクローカルアドレスモードの使用がそのProxyのモバイルIPv6ドメインに可能にされないのを含意します。
FixedMAGLinkLayerAddressOnAllAccessLinks
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.
この変数は、すべてのモバイルアクセスゲートウェイSHOULDがアクセスリンクのいずれでも使用するリンクレイヤアドレス値がそのProxyのモバイルIPv6ドメインでモバイルノードのどれかと共有されたのを示します。 リンクレイヤアドレスが全くないアクセス技術において、すべての_ZERO価値にこの変数を初期化しなければなりません。
10. IANA Considerations
10. IANA問題
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つの新しいMobility Headerオプション、Network Prefix Option、Handoff Indicator Option、Access Technology Type Option、モバイルNode Link-層のIdentifier Option、Link地方のAddress Option、およびTimestamp Optionを定義します。 これらのオプションはセクション8で説明されます。 他の移動性オプションのために割り当てられるのと同じ付番スペースからこれらのオプションのためのType値を割り当ててあります、[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で定義されたHandoff Indicator Optionは、スペース(0〜5までの値はこのドキュメントによって予約された)に付番しながら、新しいHandoff Indicator(HI)を導入します。 値がIANA Expert Reviewを通して作られていることになっている新しいHandoff Indicatorタイプの承認。
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で定義されたAccess Technology Type Optionは、スペース(0〜5までの値はこのドキュメントによって予約された)に付番しながら、新しいAccess Technologyタイプ(ATT)を導入します。 値がIANA Expert Reviewを通して作られていることになっている新しいAccess Technologyタイプの承認。
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で説明されるように新しいBinding Acknowledgement状態値を定義します。 Binding Acknowledgement状態値に使用される同じ数のスペースから状態値を割り当てなければなりません、[RFC3775]で定義されるように。 それぞれのこれらの状態値のための割り当てられた値は128以上でなければなりません。
Gundavelli, et al. Standards Track [Page 83] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[83ページ]RFC5213のプロキシのモバイルIPv6 August 2008
This document creates a new registry for the flags in the Binding Update message called the "Binding Update Flags".
このドキュメントは旗のために「拘束力があるアップデート旗」と呼ばれるBinding Updateメッセージで新しい登録を作成します。
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ビットの分野の値の残りは予約されています。 Standards Actionか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.
また、このドキュメントは旗のために「拘束力がある承認旗」と呼ばれるBinding Acknowledgmentメッセージで新しい登録を作成します。 以下の値は予約されています。
(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ビットの分野の値の残りは予約されています。 Standards ActionかIESG承認で新しい値を割り当てることができます。
11. Security Considerations
11. セキュリティ問題
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]にどんなネットワークベースの移動性管理プロトコルに対して説明されます。 このセクションはProxyのモバイルIPv6プロトコルがどうそれらの脅威に対して自らを守るかを説明します。
Gundavelli, et al. Standards Track [Page 84] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[84ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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プロトコルは、モバイルアクセスゲートウェイと地元の移動性アンカーの間で交換されたシグナリングメッセージ、Proxy Binding Update、およびProxy Binding Acknowledgementが保護されることをそれらの間の設立されたセキュリティ協会を使用することで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.
この仕様で、モバイルアクセスゲートウェイはモバイルノードを代表して拘束力がある登録メッセージを送ることができます。 適切な許可検査が適所にないなら、悪意があるノードは、モバイルノードの移動性セッションをハイジャックできるか、またはサービスの否定攻撃を行うかもしれません。 この攻撃を防ぐために、この仕様は、地元の移動性アンカーがそのProxyのモバイルIPv6ドメインの一部である唯一の認可されたモバイルアクセスゲートウェイにモバイルノードを代表してメッセージをProxy Binding Updateに送らせるのを必要とします。
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.
モバイルアクセスゲートウェイとモバイルノードとのインタフェースで脅威を排除するために、この仕様はモバイルアクセスゲートウェイとモバイルノードの間の確立した信頼を必要として、以前モバイルノードを認証して、認可するために、それはネットワークにアクセスできます。 さらに、そのアクセスリンクで可能にされた確立した認証機構は、モバイルノードのアイデンティティとそのリンクレイヤアドレスの間には、安全な結合があるのを確実にするでしょう。 モバイルアクセスゲートウェイは決定的にそれがそのアクセスリンクの上に受けるパケットからのモバイルノードを特定するでしょう。
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.
関連する脅威を扱うために、感染しているモバイルアクセスゲートウェイ(与えられたモバイルノードへのProxy Binding Updateメッセージを受け入れる前の地元の移動性アンカー)は、モバイルノードがProxy Binding Updateメッセージを送ったモバイルアクセスゲートウェイに添付されるのを確実にするかもしれません。 これは、信じられた実体に連絡することによって、達成されるかもしれません。(実体はモバイルノードの現在の接着点を追跡できます)。 しかしながら、このドキュメントの範囲の外にこれを達成するための実際のメカニズムの特定の細部があります。
12. Acknowledgements
12. 承認
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.
特に、作者は彼らのこのドキュメントの徹底的なレビューについてヤリArkko、ジュリアンLaganier、クリスチャンのフォークト、デーヴThaler、パシEronen、ピートマッキャン、ブライアン・ヘイリー、アフマドMuhanna、JinHyeockチェ、およびElwynデイヴィースに感謝したがっています。
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
また、作者はアレックス・ペトレスクに感謝したがっていて、アリスはQinxiaです、Alper Yegin、Ashutoshドゥッタ、Behcet Sarikaya、チャールズ・パーキンス、Domagoj Premec、フレッド・テンプリンGenadi Velev、ジョージTsirtsis、ヘラルドGiaretta、Henrik Levkowetz、Heshamソリマン、ジェームス・ケンフ、ジャンミッシェル
Gundavelli, et al. Standards Track [Page 85] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[85ページ]RFC5213のプロキシのモバイルIPv6 August 2008
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!
コンブ、ジョンジェイソンBrzozowski、Jun粟野ジョン・チャオ、ジョング-Hyoukリー、Jonne Soininen、Jouni Korhonen、Kalin Getov、キリアン・ウェニガー、ラース・エッゲルト、マグヌスWesterlund、マルコLiebsch、モハメド・カリル、勝利西田、Pierrick Seite、フィル・ロバーツ、ラルフDroms; ローカライズしている移動性運営方法の話題に関するワーキンググループメーリングリストの龍治Wakikawa、Sangjin Jeong、Sureshクリシュナン、Tero Kauppinen、ユリ・ブルーメンソル、Ved Kafle、Vidyaナラヤナン、Youn-ヒー・ハン、および彼らの激論のための多くの他のもの。 これらの議論は、考えの多くを刺激して、現在のフォームにドキュメントを形成しました、そして、私たちはそれを承認します!
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服部、Parviz Yegani、マーク・グレーソン、マイケルハンマー、ボイスラフVucetic、ジェイ・アイヤル、ティムStammers、バーニー・フォルツ、およびジョッシュ・リトルフィールドに感謝したがっています。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2473] コンタとA.とS.デアリング、「IPv6仕様によるジェネリックパケットトンネリング」、RFC2473、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(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.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
2005年12月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[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] パテル、A.、レオン、K.、カリル、M.、Akhtar、H.、およびK.チョードリ、「モバイルIPv6のためのモバイルノード識別子オプション(MIPv6)」、RFC4283(2005年11月)。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
Gundavelli, et al. Standards Track [Page 86] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[86ページ]RFC5213のプロキシのモバイルIPv6 August 2008
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、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.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
13.2. Informative References
13.2. 有益な参照
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、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.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[RFC3971] ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[RFC4140]ソリマン、H.、Castelluccia、C.、高架鉄道Malki、K.、およびL.Bellier、「階層的なモバイルIPv6移動性管理(HMIPv6)」、RFC4140 2005年8月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version
4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]工場、D.、「IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(SNTP)バージョン4」、RFC4330、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、「請求できるユーザのアイデンティティ」、RFC4372、2006年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path
MTU Discovery", RFC 4821, March 2007.
[RFC4821] マシスとM.とJ.ヘフナー、「Packetization層の経路MTU発見」、RFC4821、2007年3月。
Gundavelli, et al. Standards Track [Page 87] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[87ページ]RFC5213のプロキシのモバイルIPv6 August 2008
[RFC4830] Kempf, J., "Problem Statement for Network-Based
Localized Mobility Management (NETLMM)", RFC 4830,
April 2007.
[RFC4830] ケンフ、J.、「ネットワークを拠点とするローカライズしている移動性管理(NETLMM)のための問題声明」、RFC4830、2007年4月。
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
[RFC4831] ケンフ、J.、「ネットワークを拠点とするローカライズしている移動性管理(NETLMM)の目標」、RFC4831、2007年4月。
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-
Based Localized Mobility Management (NETLMM)",
RFC 4832, April 2007.
[RFC4832] フォークトとC.とJ.ケンフ、「ネットワークへの脅威が基礎づけたセキュリティは、移動性が管理(NETLMM)であるとローカライズした」RFC4832、2007年4月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] トムソンとS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」、RFC4862、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.クリシュナン、「IPv6"、RFC4941、2007年9月の状態がないアドレス自動構成のためのプライバシー拡大。」
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
Vendor Specific Option", RFC 5094, December 2007.
[RFC5094] DevarapalliとV.とパテル、A.とK.レオン、「モバイルIPv6ベンダー特定のオプション」、RFC5094、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、「IPv4は2008年5月にプロキシのためにモバイルIPv6"、進行中の仕事をサポートします」。
[DNAV6] Narayanan, S., Ed., "Detecting Network Attachment in
IPv6 Networks (DNAv6)", Work in Progress,
February 2008.
[DNAV6] エドナラヤナン、S.、処理中の作業、「IPv6ネットワーク(DNAv6)でネットワーク付属を見つける」2月2008日
Gundavelli, et al. Standards Track [Page 88] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[88ページ]RFC5213のプロキシのモバイルIPv6 August 2008
Appendix A. Proxy Mobile IPv6 Interactions with AAA Infrastructure
AAAインフラストラクチャとの付録のA.のプロキシのモバイルIPv6相互作用
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ドメインを移動するあらゆるモバイルノードが識別子によって通常特定されるでしょう、ミネソタ-識別子、そして、その識別子で、アドレス構成モードが受入れられた1インタフェースあたり1個のベースでモバイルノードのホームネットワーク接頭語(es)を特定する関連方針プロフィールはネットワークベースの移動性経営指導を提供するのに、不可欠の方針、および他のパラメタに移動するでしょう。 この情報はAAAで通常構成されます。 いくつかの場合、ホームネットワーク接頭語(es)は、そのインタフェースの上のProxyのモバイル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]かDIAMETER[RFC3588]プロトコルを使用することでこの情報について質問できます。
Appendix B. Routing State
付録B.ルート設定状態
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.
以下のセクションはモバイルノードのためにモバイルアクセスゲートウェイに創設されたルーティング状態について説明します。 このルーティング州は実装の1つの特定の方法だけを反映します、そして、他の方法でそれを実装するのを選ぶかもしれません。 方針は行為の下で特定のトンネルを通るモバイルノードのトラフィックがモバイルアクセスゲートウェイとそのモバイルノードの地方の移動性の間で作成したルーティングのためのトラフィック選択規則が投錨されて特定のカプセル化モードで定義されたルートを基礎づけました、交渉されるように。
The below example identifies the routing state for two visiting mobile nodes, MN1 and MN2, with their respective local mobility anchors, LMA1 and LMA2.
以下の例は2訪問モバイルのノード、MN1、およびMN2のためにルーティング状態を特定します、それぞれの地元の移動性のアンカー、LMA1、およびLMA2と共に。
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アドレス、イングレスインタフェースまたはソースによって特定されたモバイルノードからのすべてのトラフィックには、インタフェースtunnel0(次のホップLMAA)を通して_あらゆる_DESTINATION_ルートへ(ミネソタ-HNP)を前に置いてください。
Gundavelli, et al. Standards Track [Page 89] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[89ページ]RFC5213のプロキシのモバイルIPv6 August 2008
+==================================================================+ | 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 | +------------------------------------------------------------------+
+==================================================================+ | パケットソース| 送付先アドレス| 目的地のインタフェース| +==================================================================+ | _MAC_アドレスMN1| _どんな_の目的地_| Tunnel0| | (IPv6 Prefix or |----------------------------------------------| | Input Interface) | 局所的に接続されます。| Tunnel0| +------------------------------------------------------------------+ | _MAC_アドレスMN2| _どんな_の目的地_| 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 | +------------------------------------------------------------------+
+==================================================================+ | インタフェース| ソースアドレス| 送付先アドレス| カプセル化| +==================================================================+ | Tunnel0| プロキシ-CoA| LMAA1| IPv6のIPv6| +------------------------------------------------------------------+ | Tunnel1| プロキシ-CoA| LMAA2| IPv6のIPv6| +------------------------------------------------------------------+
Example - Tunnel Interface Table
例--トンネルインタフェーステーブル
Gundavelli, et al. Standards Track [Page 90] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[90ページ]RFC5213のプロキシのモバイルIPv6 August 2008
Authors' Addresses
作者のアドレス
Sri Gundavelli (editor) Cisco 170 West Tasman Drive San Jose, CA 95134 USA
シスコ170の西タスマン・Drive様のGundavelli(エディタ)カリフォルニア95134サンノゼ(米国)
EMail: sgundave@cisco.com
メール: sgundave@cisco.com
Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA
レオンシスコ170の西タスマン・Driveケントカリフォルニア95134サンノゼ(米国)
EMail: kleung@cisco.com
メール: kleung@cisco.com
Vijay Devarapalli Wichorus 3590 North First Street San Jose, CA 95134 USA
ビジェイDevarapalli Wichorus3590の北の最初に、通りサンノゼ、カリフォルニア95134米国
EMail: vijay@wichorus.com
メール: vijay@wichorus.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA
KuntalチョードリStarentネットワーク30の国際Placeテュークスベリー(MA)
EMail: kchowdhury@starentnetworks.com
メール: kchowdhury@starentnetworks.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6000の接続Driveテキサス75039アービング(米国)
EMail: basavaraj.patil@nokia.com
メール: basavaraj.patil@nokia.com
Gundavelli, et al. Standards Track [Page 91] RFC 5213 Proxy Mobile IPv6 August 2008
Gundavelli、他 標準化過程[91ページ]RFC5213のプロキシのモバイルIPv6 August 2008
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Gundavelli, et al. Standards Track [Page 92]
Gundavelli、他 標準化過程[92ページ]
一覧
スポンサーリンク
