RFC4140 日本語訳
4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6). H.Soliman, C. Castelluccia, K. El Malki, L. Bellier. August 2005. (Format: TXT=71503 bytes) (Obsoleted by RFC5380) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Soliman
Request for Comments: 4140 Flarion
Category: Experimental C. Castelluccia
INRIA
K. El Malki
Ericsson
L. Bellier
INRIA
August 2005
コメントを求めるワーキンググループH.ソリマンの要求をネットワークでつないでください: 4140年のFlarionカテゴリ: 実験的なC.の高架鉄道MalkiエリクソンL.Bellier INRIA Castelluccia INRIA K.2005年8月
Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
階層的なモバイルIPv6移動性管理(HMIPv6)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.
このドキュメントは、地方の移動性取り扱いを考慮するためにモバイルIPv6とIPv6 Neighbourディスカバリーに拡大を紹介します。 モバイルIPv6のための階層的な移動性管理は、モバイルNodeと、Correspondent Nodesと、そのホームのエージェントの間で合図する量を減少させるように設計されています。 また、引き渡し速度に関してモバイルIPv6の性能を向上させるのに本書では説明されたMobility Anchor Point(MAP)は使用できます。
Soliman, et al. Experimental [Page 1] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[1ページ]RFC4140HMIPv6 August 2005
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operation ...........................................6
4. Mobile IPv6 Extensions ..........................................8
4.1. Local Binding Update .......................................8
5. Neighbour Discovery Extension: The MAP Option Message Format ....9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................10
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................12
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................13
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................14
7.1. Dynamic MAP Discovery .....................................14
7.1.1. Router Operation for Dynamic MAP Discovery .........15
7.1.2. MAP Operation for Dynamic MAP Discovery ............15
7.2. Mobile Node Operation .....................................16
8. Updating Previous MAPs .........................................16
9. Notes on MAP Selection by the Mobile Node ......................17
9.1. MAP Selection in a Distributed-MAP Environment ............17
9.2. MAP Selection in a Flat Mobility Management Architecture ..19
10. Detection and Recovery from MAP Failures ......................19
11. IANA Considerations ...........................................20
12. Security Considerations .......................................20
12.1. Mobile Node-MAP Security ................................20
12.2. Mobile Node-Correspondent Node Security .................22
12.3. Mobile Node-Home Agent Security .........................22
13. Acknowledgments ...............................................22
14. References ....................................................23
14.1. Normative References ....................................23
14.2. Informative References ..................................23
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 .................24
1. 序論…3 2. 用語…4 3. HMIPv6の概要…5 3.1. HMIPv6操作…6 4. モバイルIPv6拡張子…8 4.1. 局所束縛アップデート…8 5. 発見拡大に近くに住んでください: 地図オプションメッセージ・フォーマット…9 6. 操作について議定書の中で述べてください…10 6.1. モバイルノード手術…10 6.1.1. 通信員ノードにパケットを送ります…12 6.2. 操作を写像してください…12 6.3. ホームエージェント操作…13 6.4. 通信員ノード手術…13 6.5. 地図ドメインの中の地方の移動性管理最適化…13 6.6. 位置のプライバシー…14 7. 発見を写像してください…14 7.1. ダイナミックな地図発見…14 7.1.1. ダイナミックな地図発見のためのルータ操作…15 7.1.2. ダイナミックな地図発見のための操作を写像してください…15 7.2. モバイルノード手術…16 8. 前の地図をアップデートします…16 9. モバイルノードによる地図選択に関する注…17 9.1. 分配された地図環境における選択を写像してください…17 9.2. 平坦な移動性管理体系における選択を写像してください。19 10. 地図の故障からの検出と回復…19 11. IANA問題…20 12. セキュリティ問題…20 12.1. モバイルノード地図セキュリティ…20 12.2. モバイルノード通信員ノードセキュリティ…22 12.3. モバイルノードホームエージェントセキュリティ…22 13. 承認…22 14. 参照…23 14.1. 標準の参照…23 14.2. 有益な参照…23 付録A: 速いモバイルIPv6身柄の引き渡しとHMIPv6…24
Soliman, et al. Experimental [Page 2] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[2ページ]RFC4140HMIPv6 August 2005
1. Introduction
1. 序論
This memo introduces the concept of a Hierarchical Mobile IPv6 network, utilising a new node called the Mobility Anchor Point (MAP).
このメモはHierarchicalのモバイルIPv6ネットワークの概念を紹介します、Mobility Anchor Point(MAP)と呼ばれる新しいノードを利用して。
Mobile IPv6 [1] allows nodes to move within the Internet topology while maintaining reachability and on-going connections between mobile and correspondent nodes. To do this a mobile node sends Binding Updates (BUs) to its Home Agent (HA) and all Correspondent Nodes (CNs) it communicates with, every time it moves. Authenticating binding updates requires approximately 1.5 round-trip times between the mobile node and each correspondent node (for the entire return routability procedure in a best case scenario, i.e., no packet loss). In addition, one round-trip time is needed to update the Home Agent; this can be done simultaneously while updating correspondent nodes. The re-use of the home cookie (i.e., eliminating HOTI/HOT) will not reduce the number of round trip times needed to update correspondent nodes. These round trip delays will disrupt active connections every time a handoff to a new AR is performed. Eliminating this additional delay element from the time- critical handover period will significantly improve the performance of Mobile IPv6. Moreover, in the case of wireless links, such a solution reduces the number of messages sent over the air interface to all correspondent nodes and the Home Agent. A local anchor point will also allow Mobile IPv6 to benefit from reduced mobility signalling with external networks.
モバイルと通信員ノードの間で可到達性と継続している接続を維持している間、モバイルIPv6[1]はインターネットトポロジーの中でノードを移行させます。 これをするために、モバイルノードはホームエージェント(HA)とそれがコミュニケートするすべてのCorrespondent Nodes(CNs)にBinding Updates(BUs)を送ります、移行するときはいつも。 拘束力があるアップデートを認証するのはモバイルノードとそれぞれの通信員ノード(すなわち、最も良いケースシナリオ、パケット損失がないのにおける全体のリターンroutability手順のための)の間で往復のおよそ1.5回を必要とします。 さらに、往復の1回がホームのエージェントをアップデートするのに必要です。 同時に、通信員ノードをアップデートしている間、これができます。 ホームクッキー(すなわち、HOTI/HOTを排除する)の再使用は通信員ノードをアップデートするのに必要である周遊旅行時間の数を減少させないでしょう。 新しいARへの移管が実行されるときはいつも、これらの周遊旅行遅れは活発な接続を中断するでしょう。 時間の重要な引き渡しの期間からこの追加遅延素子を排除すると、モバイルIPv6の性能はかなり向上するでしょう。 そのうえ、ワイヤレスのリンクの場合では、そのようなソリューションは空気インタフェースの上に送られたメッセージの数をすべての通信員ノードとホームのエージェントに減少させます。 またモバイルIPv6がポイントで利益を得ることができる地元のアンカーは外部のネットワークと共に合図する移動性を減少させました。
For these reasons a new Mobile IPv6 node, called the Mobility Anchor Point, is used and can be located at any level in a hierarchical network of routers, including the Access Router (AR). Unlike Foreign Agents in IPv4, a MAP is not required on each subnet. The MAP will limit the amount of Mobile IPv6 signalling outside the local domain. The introduction of the MAP provides a solution to the issues outlined earlier in the following way:
これらの理由で、Mobility Anchor Pointと呼ばれる新しいモバイルIPv6ノードは、使用されていて、ルータの階層的なネットワークでどんなレベルでも位置できます、Access Router(AR)を含んでいて。 IPv4のForeignエージェントと異なって、MAPは各サブネットで必要ではありません。 MAPは局所領域の外で合図するモバイルIPv6の量を制限するでしょう。 MAPの導入は、より早く以下の方法で概説された問題に解決法を提供します:
- The mobile node sends Binding Updates to the local MAP rather than
the HA (which is typically further away) and CNs
- モバイルノードはHA(通常さらに遠さにある)とCNsよりむしろ地方のMAPにBinding Updatesを送ります。
- Only one Binding Update message needs to be transmitted by the MN
before traffic from the HA and all CNs is re-routed to its new
location. This is independent of the number of CNs that the MN is
communicating with.
- 1つのBinding Updateメッセージだけが、HAとすべてのCNsからのトラフィックが新しい位置に別ルートで送られる前にミネソタによって伝えられる必要があります。 これはミネソタがコミュニケートしているCNsの数から独立しています。
A MAP is essentially a local Home Agent. The aim of introducing the hierarchical mobility management model in Mobile IPv6 is to enhance the performance of Mobile IPv6 while minimising the impact on Mobile IPv6 or other IPv6 protocols. It also supports Fast Mobile IPv6 Handovers to help Mobile Nodes achieve seamless mobility (see
MAPは本質的には地元のホームのエージェントです。 モバイルIPv6の階層的な移動性マネジメント・モデルを紹介する目的はモバイルIPv6か他のIPv6プロトコルで影響を最小とならせている間、モバイルIPv6の性能を高めることです。 また、それがモバイルNodesがシームレスの移動性を達成するのを助けるためにFastのモバイルIPv6 Handoversをサポートする、(見る。
Soliman, et al. Experimental [Page 3] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[3ページ]RFC4140HMIPv6 August 2005
Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and Home Agents while using Mobile IPv6 route optimisation.
付録a)。 その上、モバイルIPv6ルート最適化を使用している間、HMIPv6はモバイルノードに通信員ノードとホームのエージェントからそれらの位置を隠させます。
2. Terminology
2. 用語
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 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[3]で説明されるように本書では解釈されることであるべきですか?
In addition, new terms are defined below:
さらに、新学期は以下で定義されます:
Access Router (AR) The AR is the Mobile Node's default router.
The AR aggregates the outbound traffic of
mobile nodes.
アクセスRouter(AR)ARはモバイルNodeのデフォルトルータです。 ARはモバイルノードのアウトバウンドトラフィックに集めます。
Mobility Anchor Point A Mobility Anchor Point is a router located
(MAP) in a network visited by the mobile node. The
MAP is used by the MN as a local HA. One or
more MAPs can exist within a visited network.
移動性Anchor Point A Mobility Anchor Pointはモバイルノードによって訪問されたネットワークで位置する(MAP)ルータです。 MAPは地方のHAとしてミネソタによって使用されます。 1MAPsが訪問されたネットワークの中に存在できます。
Regional Care-of An RCoA is an address obtained by the
Address (RCoA) mobile node from the visited network. An RCoA
is an address on the MAP's subnet. It is
auto-configured by the mobile node when
receiving the MAP option.
地方、Care、-、An RCoAはAddress(RCoA)のモバイルノードによって訪問されたネットワークから得られたアドレスです。 RCoAはMAPのサブネットに関するアドレスです。 MAPオプションを受け取るとき、それはモバイルノードによって自動構成されます。
HMIPv6-aware An HMIPv6-aware mobile node is a mobile
Mobile Node node that can receive and process the MAP
option received from its default router. An
HMIPv6-aware Mobile Node must also be able to
send local binding updates (Binding Update
with the M flag set).
HMIPv6意識しているAn HMIPv6意識しているモバイルノードはデフォルトルータから受け取られたMAPオプションを受け取って、処理できるモバイルモバイルNodeノードです。 また、HMIPv6意識しているモバイルNodeは局所束縛アップデートを送ることができなければなりません(Mがある拘束力があるUpdateはセットに旗を揚げさせます)。
On-link Care-of The LCoA is the on-link CoA configured on
Address (LCoA) a mobile node's interface based on the prefix
advertised by its default router. In [1],
this is simply referred to as the Care-of-
address. However, in this memo LCoA is used
to distinguish it from the RCoA.
オンリンク、Care、-、LCoAはモバイルノードのインタフェースがデフォルトルータによって広告に掲載された接頭語に基礎づけたAddress(LCoA)で構成されたリンクのCoAです。 これが[1]に単にCareと呼ばれる、-、アドレスについて。 しかしながら、このメモでは、LCoAは、RCoAとそれを区別するのに使用されます。
Local Binding Update The MN sends a Local Binding Update to the MAP
in order to establish a binding between the
RCoA and LCoA.
地方のBinding Updateミネソタは、RCoAとLCoAの間の結合を確立するためにLocal Binding UpdateをMAPに送ります。
Soliman, et al. Experimental [Page 4] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[4ページ]RFC4140HMIPv6 August 2005
3. Overview of HMIPv6
3. HMIPv6の概要
This Hierarchical Mobile IPv6 scheme introduces a new function, the MAP, and minor extensions to the mobile node operation. The correspondent node and Home Agent operation will not be affected.
このHierarchicalのモバイルIPv6体系は新しい機能、MAP、および小さい方の拡大をモバイルノード手術に取り入れます。 通信員ノードとホームエージェント操作は影響を受けないでしょう。
Just like Mobile IPv6, this solution is independent of the underlying access technology, allowing mobility within or between different types of access networks.
まさしくモバイルIPv6のように、このソリューションは基本的なアクセス技術から独立しています、ネットワークか異なったタイプのアクセスネットワークの間の移動性を許容して。
A mobile node entering a MAP domain will receive Router Advertisements containing information on one or more local MAPs. The MN can bind its current location (on-link CoA) with an address on the MAP's subnet (RCoA). Acting as a local HA, the MAP will receive all packets on behalf of the mobile node it is serving and will encapsulate and forward them directly to the mobile node's current address. If the mobile node changes its current address within a local MAP domain (LCoA), it only needs to register the new address with the MAP. Hence, only the Regional CoA (RCoA) needs to be registered with correspondent nodes and the HA. The RCoA does not change as long as the MN moves within a MAP domain (see below for definition). This makes the mobile node's mobility transparent to the correspondent nodes it is communicating with.
MAPドメインに入るモバイルノードは1地方のMAPsの情報を含むRouter Advertisementsを受けるでしょう。 ミネソタはMAPのサブネット(RCoA)に関するアドレスで現在の位置(リンクの上のCoA)を縛ることができます。 地方のHAとして機能して、MAPはそれが役立っていて、カプセル化するモバイルノードを代表してすべてのパケットを受けて、直接モバイルノードの現在のアドレスにそれらを送るでしょう。 モバイルノードが地方のMAPドメイン(LCoA)の中で現在のアドレスを変えるなら、それは、新しいアドレスをMAPに登録する必要があるだけです。 Regional CoA(RCoA)だけが、通信員ノードとHAに登録される必要があります。 ミネソタがMAPドメインの中で移行する(定義に関して以下を見てください)限り、RCoAは変化しません。 これはモバイルノードのものをそれがコミュニケートしている通信員ノードに透明な移動性にします。
A MAP domain's boundaries are defined by the Access Routers (ARs) advertising the MAP information to the attached Mobile Nodes. The detailed extensions to Mobile IPv6 and operations of the different nodes will be explained later in this document.
MAPドメインの境界は、付属モバイルNodesにMAP情報の広告を出しながら、Access Routers(ARs)によって定義されます。 異なったノードのモバイルIPv6と操作への詳細な拡大は後で本書では説明されるでしょう。
It should be noted that the HMIPv6 concept is simply an extension to the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an implementation of Mobile IPv6 SHOULD choose to use the MAP when discovering such capability in a visited network. However, in some cases the mobile node may prefer to simply use the standard Mobile IPv6 implementation. For instance, the mobile node may be located in a visited network within its home site. In this case, the HA is located near the visited network and could be used instead of a MAP. In this scenario, the mobile node would only update the HA whenever it moves. The method to determine whether the HA is in the vicinity of the MN (e.g., same site) is outside the scope of this document.
HMIPv6概念が単にモバイルIPv6プロトコルへの拡大であることに注意されるべきです。 モバイルIPv6 SHOULDの実装があるHMIPv6意識しているモバイルノードは、訪問されたネットワークでそのような能力を発見するとき、MAPを使用するのを選びます。 しかしながら、いくつかの場合、モバイルノードは、単に標準のモバイルIPv6実装を使用するのを好むかもしれません。 例えば、モバイルノードはホームサイトの中に訪問されたネットワークで位置するかもしれません。 この場合、HAを訪問されたネットワークの近くに位置して、MAPの代わりに使用できました。 このシナリオでは、移行するときはいつも、モバイルノードはHAをアップデートするだけでしょう。 このドキュメントの範囲の外にHAがミネソタ(例えば、同じサイト)の近くにあるかを決定するメソッドがあります。
Soliman, et al. Experimental [Page 5] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[5ページ]RFC4140HMIPv6 August 2005
3.1. HMIPv6 Operation
3.1. HMIPv6操作
The network architecture shown in Figure 1 illustrates an example of the use of the MAP in a visited network.
図1に示されたネットワークアーキテクチャは訪問されたネットワークにおけるMAPの使用に関する例を例証します。
In Figure 1, the MAP can help in providing seamless mobility for the mobile node as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), while communicating with the correspondent node. A multi- level hierarchy is not required for a higher handover performance. Hence, it is sufficient to locate one or more MAPs (possibly covering the same domain) at any position in the operator's network.
図1では、MAPは、Access Router1(AR1)からAccess Router2(AR2)まで移行するので通信員ノードとコミュニケートしている間、シームレスの移動性をモバイルノードに提供するのを手伝うことができます。 マルチレベル階層構造は、より高い引き渡し性能に必要ではありません。 したがって、どんな位置にもオペレータのネットワークで1MAPs(ことによると、同じドメインをカバーしている)を位置させるのは十分です。
+-------+
| HA |
+-------+ +----+
| | CN |
| +----+
| |
+-------+-----+
|
|RCoA
+-------+
| MAP |
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
LCoA1 LCoA2
+-------+ | ハ| +-------+ +----+ | | CN| | +----+ | | +-------+-----+ | |RCoA+-------+ | 地図| +-------+ | | | +--------+ | | | | +-----+ +-----+ | AR1| | AR2| +-----+ +-----+ LCoA1 LCoA2
+----+
| MN |
+----+ ------------>
Movement
+----+ | ミネソタ| +----+ ------------>運動
Figure 1: Hierarchical Mobile IPv6 domain
図1: 階層的なモバイルIPv6ドメイン
Upon arrival in a visited network, the mobile node will discover the global address of the MAP. This address is stored in the Access Routers and communicated to the mobile node via Router Advertisements (RAs). A new option for RAs is defined later in this specification. This is needed to inform mobile nodes about the presence of the MAP (MAP discovery). The discovery phase will also inform the mobile node of the distance of the MAP from the mobile node. For example, the MAP function could be implemented as shown in Figure 1, and, at
訪問されたネットワークへの到着のときに、モバイルノードはMAPのグローバルアドレスを発見するでしょう。 このアドレスは、Router Advertisements(RAs)を通してAccess Routersに保存されて、モバイルノードに伝えられます。 RAsのための新しいオプションは後でこの仕様に基づき定義されます。 これが、MAP(MAP発見)の存在に関するモバイルノードを知らせるのに必要です。 また、発見フェーズはモバイルノードからMAPの距離のモバイルノードを知らせるでしょう。 例えば、MAP機能はそして、図1に示されるように実装されるかもしれません。
Soliman, et al. Experimental [Page 6] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[6ページ]RFC4140HMIPv6 August 2005
the same time, also be implemented in AR1 and AR2. In this case the mobile node can choose the first hop MAP or one further up in the hierarchy of routers. The details on how to choose a MAP are provided in section 10.
また、同時に、AR1とAR2で実装されてください。 この場合、モバイルノードはルータの階層構造で、より遠くに最初のホップMAPか1つを選ぶことができます。 どうMAPを選ぶかに関する詳細はセクション10に明らかにされます。
The process of MAP discovery continues as the mobile node moves from one subnet to the next. Every time the mobile node detects movement, it will also detect whether it is still in the same MAP domain. The router advertisement used to detect movement will also inform the mobile node, through the MAP option, whether it is still in the same MAP domain. As the mobile node roams within a MAP domain, it will continue to receive the same MAP option included in router advertisements from its AR. If a change in the advertised MAP's address is received, the mobile node MUST act on the change by sending Binding Updates to its HA and correspondent nodes.
モバイルノードが1つのサブネットから次まで移行するとき、MAP発見のプロセスは持続します。 毎回、モバイルノードは動きを検出します、また、それがまだ同じMAPドメインにあるかを検出するでしょう。 また、動きを検出するのに使用されるルータ通知はモバイルノードを知らせるでしょう、MAPオプションで、それがまだ同じMAPドメインにあるか否かに関係なく。 モバイルノードがMAPドメインの中を移動するとき、それは、ARからのルータ通知に同じMAPオプションを含んでいて、受信し続けるでしょう。 広告を出しているMAPのアドレスにおける変化が受け取られているなら、HAと通信員ノードにBinding Updatesを送ることによって、モバイルノードは変化に影響しなければなりません。
If the mobile node is not HMIPv6-aware, then no MAP Discovery will be performed, resulting in the mobile node using the Mobile IPv6 [1] protocol for its mobility management. On the other hand, if the mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 implementation. If so, the mobile node will first need to register with a MAP by sending it a BU containing its Home Address and on-link address (LCoA). The Home address used in the BU is the RCoA. The MAP MUST store this information in its Binding Cache to be able to forward packets to their final destination when received from the different correspondent nodes or HAs.
モバイルノードがHMIPv6意識していないと、MAPディスカバリーは全く実行されないでしょう、移動性管理にモバイルIPv6[1]プロトコルを使用することでモバイルノードをもたらして。 他方では、モバイルノードがHMIPv6意識している、それ、SHOULDは、HMIPv6実装を使用するのを選びます。 そうだとすれば、モバイルノードは、最初に、そのホームAddressとリンクアドレスの(LCoA)を含むBUをそれに送ることによってMAPとともに記名する必要があるでしょう。 BUで使用されるホームアドレスはRCoAです。 異なった通信員のノードかHAsから受け取ると、MAP MUSTは、それらの最終的な目的地にパケットを送ることができるようにBinding Cacheのこの情報を保存します。
The mobile node will always need to know the original sender of any received packets to determine if route optimisation is required. This information will be available to the mobile node because the MAP does not modify the contents of the original packet. Normal processing of the received packets (as described in [1]) will give the mobile node the necessary information.
モバイルノードは、いつも何か容認されたパケットの元の送り主が、ルート最適化が必要であるかどうかと決心しているのを知る必要があるでしょう。 MAPがオリジナルのパケットのコンテンツを変更しないので、この情報はモバイルノードに利用可能になるでしょう。 容認されたパケットの正常処理、([1])で説明されるように、モバイルノードに必要事項を与えるでしょう。
To use the network bandwidth in a more efficient manner, a mobile node may decide to register with more than one MAP simultaneously and to use each MAP address for a specific group of correspondent nodes. For example, in Fig 1, if the correspondent node happens to exist on the same link as the mobile node, it would be more efficient to use the first hop MAP (in this case assume it is AR1) for communication between them. This will avoid sending all packets via the "highest" MAP in the hierarchy and thus will result in more efficient usage of network bandwidth. The mobile node can also use its current on-link address (LCoA) as a CoA, as specified in [1]. Note that the mobile node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a binding update sent to another MAP. The LCoA included in the binding update MUST be the mobile node's address derived from the prefix advertised on its link.
より効率的な方法でネットワーク回線容量を使用するために、モバイルノードは、同時に、1MAPとともに記名して、通信員ノードの特定のグループにそれぞれのMAPアドレスを使用すると決めるかもしれません。 例えば、図1では、通信員ノードがモバイルノードと同じリンクの上にたまたま存在するなら、それらのコミュニケーションに、最初のホップMAP(この場合、それがAR1であると仮定する)を使用するのは、より効率的でしょう。 これは、階層構造における「最も高い」MAPを通してすべてのパケットを送るのを避けて、その結果、ネットワーク回線容量の、より効率的な用法をもたらすでしょう。 また、モバイルノードは[1]で指定されるようにリンクアドレスのCoAとしての現在の(LCoA)を使用できます。 拘束力があるアップデートにおけるLCoAが別のMAPに発信したのでモバイルノードがMAPのサブネットからRCoAを寄贈してはいけないことに注意してください。 拘束力があるアップデートにLCoAを含むのは、リンクの上に広告に掲載された接頭語から得られたモバイルノードのアドレスであるに違いありません。
Soliman, et al. Experimental [Page 7] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[7ページ]RFC4140HMIPv6 August 2005
If a router advertisement is used for MAP discovery, as described in this document, all ARs belonging to the MAP domain MUST advertise the MAP's IP address. The same concept (advertising the MAP's presence within its domain) should be used if other methods of MAP discovery are introduced in future.
ルータ通知がMAP発見に本書では説明されるように使用されるなら、MAPドメインに属すすべてのARsがMAPのIPアドレスの広告を出さなければなりません。 これからMAP発見の他のメソッドを導入するなら、同じ概念(ドメインの中にMAPの存在の広告を出す)を使用するべきです。
4. Mobile IPv6 Extensions
4. モバイルIPv6拡張子
This section outlines the extensions proposed to the binding update specified in [1].
このセクションは[1]で指定された拘束力があるアップデートに提案された拡大について概説します。
4.1. Local Binding Update
4.1. 局所束縛アップデート
A new flag is added: the M flag, which indicates MAP registration. When a mobile node registers with the MAP, the M and A flags MUST be set to distinguish this registration from a BU being sent to the HA or a correspondent node.
新しい旗は加えられます: M(MAP登録を示す)は弛みます。 モバイルノードがMAPとともに記名すると、HAか通信員ノードに送られるBUとこの登録を区別するようにMとA旗を設定しなければなりません。
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| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 予約されます。| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description of extensions to the binding update:
拘束力があるアップデートへの拡大の記述:
M If set to 1 it indicates a MAP registration.
M、1に設定されるなら、それはMAP登録を示します。
It should be noted that this is an extension to the Binding update specified in [1].
これが[1]で指定されたBindingアップデートへの拡大であることに注意されるべきです。
Soliman, et al. Experimental [Page 8] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[8ページ]RFC4140HMIPv6 August 2005
5. Neighbour Discovery Extension: The MAP Option Message Format
5. 発見拡大に近くに住んでください: 地図オプションメッセージ・フォーマット
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 | Dist | Pref |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| Dist| Pref|R| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有効な生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 地図+のためのグローバルIPアドレス| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
分野:
Type IPv6 Neighbor Discovery option. 23.
IPv6 Neighborディスカバリーオプションをタイプしてください。 23.
Length 8-bit unsigned integer. The length of the option
and MUST be set to 3.
長さ、8ビットの符号のない整数。 長さ、3にゆだねて、設定していなければなりません。
Dist A 4-bit unsigned integer identifying the Distance
Between MAP and the receiver of the advertisement.
Its default value SHOULD be set to 1 if Dynamic
MAP discovery is used. The Distance MUST be set
to 1 if the MAP is on the same link as the mobile
node. This field need not be interpreted as the
number of hops between MAP and the mobile node.
The only requirement is that the meaning of the
Distance field is consistently interpreted within
one Domain. A Distance value of Zero MUST NOT be
used.
Dist A、広告のDistance Between MAPと受信機を特定する4ビットの符号のない整数。 デフォルトはSHOULDを評価します。1に、Dynamic MAP発見が使用されているなら、用意ができています。 モバイルノードと同じリンクの上にMAPがあるなら、Distanceは1に用意ができなければなりません。 この分野はMAPとモバイルノードの間のホップの数として解釈される必要はありません。 唯一の要件はDistance分野の意味が1Domainの中で一貫して解釈されるということです。 ZeroのDistance値を使用してはいけません。
Pref The preference of a MAP. A 4-bit unsigned
integer. A decimal value of 15 indicates the
highest availability.
Pref、MAPの好み。 4ビットの符号のない整数。 15のデシマル値は最も高い有用性を示します。
R When set to 1, it indicates that the mobile node
MUST form an RCoA based on the prefix in the MAP
option.
1にセットしてください、それが、モバイルノードがMAPオプションにおける接頭語に基づくRCoAを形成しなければならないのを示すR。
Soliman, et al. Experimental [Page 9] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[9ページ]RFC4140HMIPv6 August 2005
Valid Lifetime The minimum value (in seconds) of both the
preferred and valid lifetimes of the prefix
assigned to the MAP's subnet. This value
indicates the validity of the MAP's address and
consequently the time for which the RCoA is valid.
接頭語の両方の都合のよくて有効な生涯の最小値(秒の)がMAPのサブネットに割り当てた有効なLifetime。 この値はMAPのアドレスの正当性とその結果RCoAが有効である時を示します。
Global Address One of the MAP's global addresses. The 64-bit
prefix extracted from this address MUST be
configured in the MAP to be used for RCoA
construction by the mobile node.
MAPのグローバルなアドレスのグローバルなAddress One。 RCoA工事にモバイルノードによって使用されるためにMAPでこのアドレスから抜粋された64ビットの接頭語を構成しなければなりません。
Although not explicitly included in the MAP option, the prefix length of the MAP's Global IP address MUST be 64. This prefix is the one used by the mobile node to form an RCoA, by appending a 64-bit identifier to the prefix. Thus, it necessitates a static prefix length for the MAP's subnet.
MAPオプションに明らかに含まれていませんが、MAPのGlobal IPアドレスの接頭語の長さは64であるに違いありません。 この接頭語はモバイルノードによって使用される、RCoAを形成するものです、64ビットの識別子を接頭語に追加することによって。 したがって、それはMAPのサブネットのための静的な接頭語の長さを必要とします。
6. Protocol Operation
6. プロトコル操作
This section describes the HMIPv6 protocol. In HMIPv6, the mobile node has two addresses, an RCoA on the MAP's link and an on-link CoA (LCoA). This RCoA is formed in a stateless manner by combining the mobile node's interface identifier and the subnet prefix received in the MAP option.
このセクションはHMIPv6プロトコルについて説明します。 HMIPv6では、モバイルノードは2つのアドレス、MAPのリンクの上のRCoA、およびリンクの上のCoA(LCoA)を持っています。 このRCoAはモバイルノードのインタフェース識別子とMAPオプションで受け取られたサブネット接頭語を結合することによって、状態がない方法で形成されます。
As illustrated in this section, this protocol requires updating the mobile nodes' implementation only. The HA and correspondent node are unchanged. The MAP performs the function of a "local" HA that binds the mobile node's RCoA to an LCoA.
このセクションで例証されるように、このプロトコルは、モバイルノードの実装だけをアップデートするのを必要とします。 HAと通信員ノードは変わりがありません。 MAPはモバイルノードのRCoAをLCoAに縛る「地方」のHAの機能を実行します。
6.1. Mobile Node Operation
6.1. モバイルノード手術
When a mobile node moves into a new MAP domain (i.e., its MAP changes), it needs to configure two CoAs: an RCoA on the MAP's link and an on-link CoA (LCoA). The RCoA is formed in a stateless manner. After forming the RCoA based on the prefix received in the MAP option, the mobile node sends a local BU to the MAP with the A and M flags set. The local BU is a BU defined in [1] and includes the mobile node's RCoA in the Home Address Option. No alternate-CoA option is needed in this message. The LCoA is used as the source address of the BU. This BU will bind the mobile node's RCoA (similar to a Home Address) to its LCoA. The MAP (acting as a HA) will then perform DAD (when a new binding is being created) for the mobile node's RCoA on its link and return a Binding Acknowledgement to the MN. This acknowledgement identifies the binding as successful or contains the appropriate fault code. No new error codes need to be
モバイルノードが新しいMAPドメイン(すなわち、MAP変化)に移行すると、2CoAsを構成するのが必要です: MAPのリンクの上のRCoAとリンクの上のCoA(LCoA)。 RCoAは状態がない方法で形成されます。 MAPオプションで受け取られた接頭語に基づくRCoAを形成した後に、モバイルノードは旗が設定するAとMがあるMAPに地方のBUを送ります。 地方のBUは[1]で定義されたBUであり、ホームAddress OptionにモバイルノードのRCoAを含んでいます。 代替のCoAオプションは全くこのメッセージで必要ではありません。 LCoAはBUのソースアドレスとして使用されます。 このBUはモバイルノードのRCoA(ホームAddressと同様の)をLCoAに縛るでしょう。 MAP(HAとして、機能する)は次に、リンクの上のモバイルノードのRCoAのために、DAD(新しい結合が作成されているとき)を実行して、Binding Acknowledgementをミネソタに返すでしょう。 この承認は、結合がうまくいっていると認識するか、または適切な欠点コードを含んでいます。 どんな新しいエラーコードも、必要がありません。
Soliman, et al. Experimental [Page 10] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[10ページ]RFC4140HMIPv6 August 2005
supported by the mobile node for this operation. The mobile node MUST silently ignore binding acknowledgements that do not contain a routing header type 2, which includes the mobile node's RCoA.
この操作のためのモバイルノードで、サポートされます。 モバイルノードは静かにルーティングヘッダータイプ2を含まない拘束力がある承認を無視しなければなりません(モバイルノードのRCoAを含んでいます)。
Following a successful registration with the MAP, a bi-directional tunnel between the mobile node and the MAP is established. All packets sent by the mobile node are tunnelled to the MAP. The outer header contains the mobile node's LCoA in the source address field and the MAP's address in the destination address field. The inner header contains the mobile node's RCoA in the source address field and the peer's address in the destination address field. Similarly, all packets addressed to the mobile node's RCoA are intercepted by the MAP and tunnelled to the mobile node's LCoA.
MAPとのうまくいっている登録に続いて、モバイルノードとMAPの間の双方向のトンネルは確立されます。 モバイルノードによって送られたすべてのパケットがMAPにトンネルを堀られます。 外側のヘッダーは目的地アドレス・フィールドのソースアドレス分野とMAPのアドレスにモバイルノードのLCoAを保管しています。 内側のヘッダーは目的地アドレス・フィールドのソースアドレス分野と同輩のアドレスにモバイルノードのRCoAを保管しています。 同様に、モバイルノードのRCoAに扱われたすべてのパケットが、MAPによって妨害されて、モバイルノードのLCoAにトンネルを堀られます。
This specification allows a mobile node to use more than one RCoA if it received more than one MAP option. In this case, the mobile node MUST perform the binding update procedure for each RCoA. In addition, the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived from a MAP's prefix (e.g., MAP1) as a care-of address in its binding update to another MAP (e.g., MAP2). This would force packets to be encapsulated several times (twice in this example) on their path to the mobile node. This form of multi-level hierarchy will reduce the protocol's efficiency and performance.
この仕様で、1つ以上のMAPオプションを受け取ったなら、モバイルノードは1RCoAを使用できます。 この場合、モバイルノードは各RCoAのために拘束力があるアップデート手順を実行しなければなりません。 さらに、モバイルノードがMAPの接頭語(例えば、MAP1)から得られたあるRCoA(例えば、RCoA1)を使用してはいけない、注意、-、アドレス、結合では、(例えば、MAP2)を別のMAPにアップデートしてください。 これによって、パケットはそれらの経路で何度か(この例の2倍)やむを得ずモバイルノードにカプセルに入れられるでしょう。 このフォームのマルチレベル階層構造はプロトコルの効率と性能を抑えるでしょう。
After registering with the MAP, the mobile node MUST register its new RCoA with its HA by sending a BU that specifies the binding (RCoA, Home Address) as in Mobile IPv6. The mobile node's Home Address is used in the home address option and the RCoA is used as the care-of address in the source address field. The mobile node may also send a similar BU (i.e., that specifies the binding between the Home Address and the RCoA) to its current correspondent nodes.
MAPとともに記名した後に、モバイルノードは、モバイルIPv6のように結合(RCoA、ホームAddress)を指定するBUを送ることによって、新しいRCoAをHAに登録しなければなりません。 モバイルノードのホームAddressがホームアドレスオプションとRCoAが使用される中古のコネである、注意、-、ソースでアドレスが分野であると扱ってください。 また、モバイルノードは同様のBU(すなわち、それはホームAddressとRCoAの間の結合を指定する)を現在の通信員ノードに送るかもしれません。
The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering with its HA. It should be noted that when binding the RCoA with the HA and correspondent nodes, the binding lifetime MUST NOT be larger than the mobile node's binding lifetime with the MAP, which is received in the Binding Acknowledgement.
HAとともに記名する前に、モバイルノードSHOULDはMAPから拘束力がある承認を待ちます。 HAと通信員ノードでRCoAを縛るとき、拘束力がある寿命がBinding Acknowledgementに受け取られるMAPがあるモバイルノードの拘束力がある生涯より大きいはずがないことに注意されるべきです。
In order to speed up the handover between MAPs and reduce packet loss, a mobile node SHOULD send a local BU to its previous MAP, specifying its new LCoA. Packets in transit that reach the previous MAP are then forwarded to the new LCoA.
MAPsの間の引き渡しを加速して、減少するために、パケット損失、モバイルノードSHOULDは地方のBUを前のMAPに送ります、新しいLCoAを指定して。 そして、トランジットにおける前のMAPに達するパケットを新しいLCoAに送ります。
The MAP will receive packets addressed to the mobile node's RCoA (from the HA or correspondent nodes). Packets will be tunnelled from the MAP to the mobile node's LCoA. The mobile node will de-capsulate the packets and process them in the normal manner.
MAPはモバイルノードのRCoA(HAか通信員ノードからの)に扱われたパケットを受けるでしょう。 パケットはMAPからモバイルノードのLCoAまでトンネルを堀られるでしょう。 正常な方法によるモバイルのノードの意志の反-カプセルになったパケットと加工処理したそれら。
Soliman, et al. Experimental [Page 11] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[11ページ]RFC4140HMIPv6 August 2005
When the mobile node moves within the same MAP domain, it should only register its new LCoA with its MAP. In this case, the RCoA remains unchanged.
モバイルノードが同じMAPドメインの中で移行すると、それは新しいLCoAをMAPに登録するだけであるべきです。 この場合、RCoAは変わりがありません。
Note that a mobile node may send a BU containing its LCoA (instead of its RCoA) to correspondent nodes, which are connected to its same link. Packets will then be routed directly without going through the MAP.
モバイルノードがLCoA(RCoAの代わりに)を同じリンクに接続される通信員ノードに含むBUを送るかもしれないことに注意してください。 そして、直接MAPを通らないで、パケットは発送されるでしょう。
6.1.1. Sending Packets to Correspondent Nodes
6.1.1. 通信員ノードにパケットを送ります。
The mobile node can communicate with a correspondent node through the HA, or in a route-optimised manner, as described in [1]. When communicating through the HA, the message formats in [1] can be re- used.
モバイルノードはHAを通した、または、ルートで最適化された方法による通信員ノードとコミュニケートできます、[1]で説明されるように。 HAを通って交信するとき、[1]のメッセージ・フォーマットを再使用できます。
If the mobile node communicates directly with the correspondent node (i.e., the CN has a binding cache entry for the mobile node), the mobile node MUST use the same care-of address used to create a binding cache entry in the correspondent node (RCoA) as a source address. According to [1], the mobile node MUST also include a Home Address option in outgoing packets. The Home address option MUST contain the mobile node's home address.
モバイルノードが通信員ノードと共に直接伝達するなら(すなわち、CNには、モバイルノードのための拘束力があるキャッシュエントリーがあります)、モバイルノードが同じくらい使用しなければならない、注意、-、アドレスは以前はソースアドレスとしてよく通信員ノード(RCoA)における拘束力があるキャッシュエントリーを作成していました。 また、[1]によると、モバイルノードは出発しているパケットにホームAddressオプションを含まなければなりません。 ホームアドレスオプションはモバイルノードのホームアドレスを含まなければなりません。
6.2. MAP Operations
6.2. 地図操作
The MAP acts like a HA; it intercepts all packets addressed to registered mobile nodes and tunnels them to the corresponding LCoA, which is stored in its binding cache.
MAPはHAのように行動します。 それは、登録されたモバイルノードに扱われたすべてのパケットを妨害して、対応するLCoAにそれらにトンネルを堀ります。(LCoAは拘束力があるキャッシュで保存されます)。
A MAP has no knowledge of the mobile node's Home address. The mobile node will send a local BU to the MAP with the M and A flags set. The aim of this BU is to inform the MAP that the mobile node has formed an RCoA (contained in the BU as a Home address). If successful, the MAP MUST return a binding acknowledgement to the mobile node, indicating a successful registration. This is identical to the HA operation in [1]. No new error codes are introduced for HMIPv6. The binding acknowledgement MUST include a routing header type 2 that contains the mobile node's RCoA.
MAPには、モバイルノードのホームアドレスに関する知識が全くありません。 モバイルノードは旗が設定するMとAがあるMAPに地方のBUを送るでしょう。 このBUの目的はモバイルノードがRCoA(BUでは、ホームアドレスとして含まれている)を形成したことをMAPに知らせることです。 うまくいくなら、うまくいっている登録を示して、MAP MUSTは拘束力がある承認をモバイルノードに返します。 これは[1]でのHA操作と同じです。 どんな新しいエラーコードもHMIPv6のために紹介されません。 拘束力がある承認はモバイルノードのRCoAを含むルーティングヘッダータイプ2を含まなければなりません。
The MAP MUST be able to accept packets tunnelled from the mobile node, with the mobile node being the tunnel entry point and the MAP being the tunnel exit point.
モバイルノードのトンネルエキジットポイントであることでのMAP MUSTのモバイルノードからトンネルを堀られたパケットは受け入れることができてトンネルエントリー・ポイントとMAPです。
The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are intercepted by the MAP, using proxy Neighbour Advertisement, and then encapsulated and routed to the mobile node's LCoA. This operation is identical to that of the HA described in [1].
MAPはRCoAのためのHAとして機能します。 次に、RCOAに扱われたパケットは、モバイルノードのLCoAにプロキシNeighbour Advertisementを使用して、MAPによって妨害されて、カプセルに入れられて、発送されます。 この操作は[1]で説明されたHAのものと同じです。
Soliman, et al. Experimental [Page 12] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[12ページ]RFC4140HMIPv6 August 2005
A MAP MAY be configured with the list of valid on-link prefixes that mobile nodes can use to derive LCoAs. This is useful for network operators to stop mobile nodes from continuing to use the MAP after moving to a different administrative domain. If a mobile node sent a binding update containing an LCoA that is not in the MAP's "valid on-link prefixes" list, the MAP could reject the binding update using existing error code 129 (administratively prohibited).
MAP MAY、リンクの上のモバイルノードがLCoAsを引き出すのに使用できる有効な接頭語のリストで、構成されてください。 ネットワーク・オペレータが、モバイルノードが、異なった管理ドメインに移行した後にMAPを使用し続けているのを止めるように、これは役に立ちます。 モバイルノードがMAPの「リンクの上の有効な接頭語」リストにないLCoAを含む拘束力があるアップデートを送るなら、MAPは、既存のエラーコード129(行政上禁止されています)を使用することで拘束力があるアップデートを拒絶できるでしょう。
6.3. Home Agent Operations
6.3. ホームエージェント操作
The support of HMIPv6 is completely transparent to the HA's operation. Packets addressed to a mobile node's Home Address will be forwarded by the HA to its RCoA, as described in [1].
HMIPv6のサポートはHAの操作に完全にわかりやすいです。 モバイルノードのホームAddressに扱われたパケットはHAによってRCoAに送られるでしょう、[1]で説明されるように。
6.4. Correspondent Node Operations
6.4. 通信員ノード手術
HMIPv6 is completely transparent to correspondent nodes.
HMIPv6は通信員ノードに完全に透明です。
6.5. Local Mobility Management Optimisation within a MAP Domain
6.5. 地図ドメインの中の地方の移動性管理最適化
In [1], it is stated that for short-term communication, particularly communication that may easily be retried upon failure, the mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, thus not requiring the use of a Home Address option in the packet. Such use of the CoA will reduce the overhead of sending each packet due to the absence of additional options. In addition, it will provide an optimal route between the mobile node and correspondent node.
[1]に短期的なコミュニケーション、特に失敗で容易に再試行されるかもしれないコミュニケーションのためにモバイルノードが、直接1つを使用するのを選ぶかもしれないと述べられている、それ、注意、-、パケットの源として扱っても、その結果、パケットにおけるホームAddressオプションの使用を必要としません。 CoAのそのような使用は追加オプションの欠如のため各パケットを送るオーバーヘッドを下げるでしょう。 さらに、それはモバイルノードと通信員ノードの間の最適のルートを提供するでしょう。
In HMIPv6, a mobile node can use its RCoA as the source address without using a Home Address option. In other words, the RCoA can be used as a potential source address for upper layers. Using this feature, the mobile node will be seen by the correspondent node as a fixed node while moving within a MAP domain.
HMIPv6では、ホームAddressオプションを使用しないで、モバイルノードはソースアドレスとしてRCoAを使用できます。 言い換えれば、上側の層に潜在的ソースアドレスとしてRCoAを使用できます。 この特徴を使用して、モバイルノードはMAPドメインの中で移行している間、通信員ノードによって固定ノードと考えられるでしょう。
This usage of the RCoA does not have the cost of Mobile IPv6 (i.e., no bindings or home address options are sent over the Internet), but still provides local mobility management to the mobile nodes. Although such use of RCoA does not provide global mobility (i.e., communication is broken when a mobile host moves to a new MAP), it would be useful for several applications (e.g., web browsing). The validity of the RCoA as a source address used by applications will depend on the size of a MAP domain and the speed of the mobile node. Furthermore, because the support for BU processing in correspondent nodes is not mandated in [1], this mechanism can provide a way of obtaining route optimisation without sending BUs to the correspondent nodes.
RCoAのこの使用法は、モバイルIPv6(すなわち、どんな結合もホームアドレスオプションもインターネットの上に送らない)の費用を持っていませんが、まだローカルの移動性管理をモバイルノードに提供しています。 RCoAのそのような使用はグローバルな移動性を提供しませんが(モバイルホストが新しいMAPに移行するとき、すなわち、コミュニケーションは壊れています)、それはいくつかのアプリケーション(例えば、ウェブ閲覧)の役に立つでしょう。 アプリケーションで使用されるソースアドレスとしてのRCoAの正当性はMAPドメインのサイズとモバイルノードの速度に依存するでしょう。 その上、通信員ノードにおけるBU処理のサポートが[1]で強制されないので、このメカニズムは送付BUsなしでルート最適化を通信員ノードに得る方法を提供できます。
Soliman, et al. Experimental [Page 13] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[13ページ]RFC4140HMIPv6 August 2005
Enabling this mechanism can be done by presenting the RCoA as a temporary home address for the mobile node. This may require an implementation to augment its source address selection algorithm with the knowledge of the RCoA in order to use it for the appropriate applications.
モバイルノードのための仮設住宅アドレスとしてRCoAを寄贈することによって、このメカニズムを可能にすることができます。 これは、適切なアプリケーションにそれを使用するために実装がRCoAに関する知識でソースアドレス選択アルゴリズムを増大させるのを必要とするかもしれません。
6.6. Location Privacy
6.6. 位置のプライバシー
In HMIPv6, a mobile node hides its LCoA from its corresponding nodes and its home agent by using its RCoA in the source field of the packets that it sends. As a result, the location tracking of a mobile node by its corresponding nodes or its home agent is difficult because they only know its RCoA and not its LCoA.
HMIPv6では、モバイルノードは、それが送るパケットのソースフィールドでRCoAを使用することによって、対応するノードとそのホームのエージェントからLCoAを隠します。 その結果、彼らがLCoAではなく、そのRCoAを知っているだけであるので、対応するノードかそのホームのエージェントによるモバイルノードの位置追尾は難しいです。
7. MAP Discovery
7. 地図発見
This section describes how a mobile node obtains the MAP address and subnet prefix, and how ARs in a domain discover MAPs. Two different methods for MAP discovery are defined below.
このセクションは、モバイルノードがどのようにMAPアドレスとサブネット接頭語を得るか、そして、ドメインのARsがどのようにMAPsを発見するかを説明します。 MAP発見のための2つの異なったメソッドが以下で定義されます。
Dynamic MAP Discovery is based on propagating the MAP option in Router Advertisements from the MAP to the mobile node through certain (configured) router interfaces within the routers in an operator's network. This requires manual configuration of the MAP and also that the routers receiving the MAP option allow them to propagate the option on certain interfaces. To ensure a secure communication between routers, router advertisements that are sent between routers for Dynamic MAP discovery SHOULD be authenticated (e.g., using AH, ESP, or SEND). In the case where this authentication is not possible (e.g., third party routers exist between the MAP and ARs), a network operator may prefer to manually configure all the ARs to send the MAP option, as described in this document.
ダイナミックなMAPディスカバリーはルータの中のある(構成された)ルータインタフェースを通してオペレータのネットワークでRouter AdvertisementsのMAPオプションをMAPからモバイルノードまで伝播するのに基づいています。 これは、MAPの手動の構成と、また、あるインタフェースでMAPオプションを受け取るルータでオプションを伝播できるのを必要とします。 ルータ、Dynamic MAP発見SHOULDのためにルータの間に送られるルータ通知の安全なコミュニケーションを確実にするには、認証されてください(例えば、AH、超能力、またはSENDを使用します)。 この認証が可能でない(例えば第三者ルータはMAPとARsの間に存在しています)場合では、ネットワーク・オペレータは、MAPオプションを送るために手動ですべてのARsを構成するのを好むかもしれません、本書では説明されるように。
Manual configuration of the MAP option information in ARs and other MAPs in the same domain is the default mechanism. It should also be possible to configure ARs and MAPs to enable dynamic mechanisms for MAP Discovery.
同じドメインのARsと他のMAPsでのMAPオプション情報の手動の構成はデフォルトメカニズムです。 また、MAPディスカバリーのためにダイナミックなメカニズムを可能にするためにARsとMAPsを構成するのも可能であるべきです。
7.1. Dynamic MAP Discovery
7.1. ダイナミックな地図発見
The process of MAP discovery can be performed in different ways. Router advertisements are used for Dynamic MAP Discovery by introducing a new option. The access router is required to send the MAP option in its router advertisements. This option includes the distance vector from the mobile node (which may not imply the real distance in terms of the number of hops), the preference for this particular MAP, the MAP's global IP address and subnet prefix
異なった方法でMAP発見のプロセスを実行できます。 ルータ通知は、Dynamic MAPディスカバリーに新しいオプションを紹介することによって、使用されます。 アクセスルータが、ルータ通知におけるMAPオプションを送るのに必要です。 このオプションはMAPのモバイルノード(ホップの数に関して本当の距離を含意しないかもしれない)からの距離ベクトル、この特定のMAPのための好み、グローバルIPアドレス、およびサブネット接頭語を含んでいます。
Soliman, et al. Experimental [Page 14] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[14ページ]RFC4140HMIPv6 August 2005
7.1.1. Router Operation for Dynamic MAP Discovery
7.1.1. ダイナミックな地図発見のためのルータ操作
The ARs within a MAP domain may be configured dynamically with the information related to the MAP options. ARs may obtain this information by listening for RAs with MAP options. Each MAP in the network needs to be configured with a default preference, the right interfaces to send this option on, and the IP address to be sent. The initial value of the "Distance" field MAY be set to a default value of 1 and MUST NOT be set to zero. Routers in the MAP domain should be configured to re-send the MAP option on certain interfaces.
MAPドメインの中のARsはMAPオプションに関連する情報によってダイナミックに構成されるかもしれません。 ARsは、MAPオプションでRAsの聞こうとすることによって、この情報を得るかもしれません。 ネットワークにおける各MAPは、デフォルト優先、このオプションを送る正しいインタフェース、および送られるIPアドレスによって構成される必要があります。 「距離」分野の初期の値は、1のデフォルト値に設定するかもしれなくて、ゼロに設定してはいけません。 MAPドメインのルータは、あるインタフェースでMAPにオプションを再送するために構成されるべきです。
Upon reception of a router advertisement with the MAP option, the receiving router MUST copy the option and re-send it after incrementing the Distance field by one. If the receiving router was also a MAP, it MUST send its own option, together with the received option, in the same advertisement. If a router receives more than one MAP option for the same MAP (i.e., the same IP address in the MAP option), from two different interfaces, it MUST choose the option with the smallest distance field.
MAPオプションによるルータ通知のレセプションに、Distance分野を1つ増加した後に、受信ルータは、オプションをコピーして、それを再送しなければなりません。 また、受信ルータがMAPであったなら、それ自身のオプションを送らなければなりません、容認されたオプションと共に、同じ広告で。 ルータが同じMAP(すなわち、MAPオプションにおける同じIPアドレス)のために1つ以上のMAPオプションを受け取るなら、2つの異なったインタフェースから、それは最も小さい距離分野があるオプションを選ばなければなりません。
In this manner, information about one or more MAPs can be dynamically passed to a mobile node. Furthermore, by performing the discovery phase in this way, different MAP nodes are able to change their preferences dynamically based on the local policies, node overload or other load-sharing protocols being used.
この様に、ダイナミックにより多くの情報およそ1MAPsをモバイルノードに渡すことができます。 その上、このように発見フェーズを実行することによって、異なったMAPノードはダイナミックに使用されるローカルの方針、ノードオーバーロードまたは他の負荷分割法プロトコルに基づく彼らの好みを変えることができます。
7.1.2. MAP Operation for Dynamic MAP Discovery
7.1.2. ダイナミックな地図発見のための地図操作
A MAP will be configured to send its option or relay MAP options belonging to other MAPs onto certain interfaces. The choice of interfaces is done by the network administrator (i.e., manual configuration) and depends on the network topology. A default preference value of 10 may be assigned to each MAP. It should be noted that a MAP can change its preference value at any time due to various reasons (e.g., node overload or load sharing). A preference value of zero means the MAP SHOULD NOT be chosen by new mobile nodes. This value could be reached in cases of node overload or partial node failures.
オプションかリレーMAPオプションに他のMAPsに、あるインタフェースに属させるように、MAPは構成されるでしょう。 インタフェースのこの選択は、ネットワーク管理者(すなわち、手動の構成)によって行われて、ネットワーク形態次第です。 10のデフォルト好みの価値は各MAPに割り当てられるかもしれません。 MAPがいつでも様々な理由(例えば、ノードオーバーロードか負荷分割法)のため好みの値を変えることができることに注意されるべきです。 ゼロの好みの値は、MAP SHOULD NOTが新しいモバイルノードによって選ばれていることを意味します。 この値にノードオーバーロードか部分的なノード障害の場合で達することができました。
The MAP option is propagated towards ARs in its domain. Each router along the path to an AR will increment the Distance field by one. If a router that is also a MAP receives advertisements from other MAPs, it MUST add its own MAP option and propagate both options to the next router or to the AR (if it has direct connectivity with the AR).
MAPオプションはドメインでARsに向かって伝播されます。 ARへの経路に沿った各ルータはDistance分野を1つ増加するでしょう。 またMAPであるルータが他のMAPsから広告を受け取るなら、それは、次のルータ、または、ARにそれ自身のMAPオプションを加えて、両方のオプションを伝播しなければなりません(それにARがあるダイレクト接続性があるなら)。
Soliman, et al. Experimental [Page 15] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[15ページ]RFC4140HMIPv6 August 2005
7.2. Mobile Node Operation
7.2. モバイルノード手術
When an HMIPv6-aware mobile node receives a router advertisement, it should search for the MAP option. One or more options may be found for different MAP IP addresses.
HMIPv6意識しているモバイルノードがルータ通知を受け取るとき、それはMAPオプションを捜し求めるべきです。 1つ以上のオプションが異なったMAP IPアドレスに関して見つけられるかもしれません。
A mobile node SHOULD register with the MAP having the highest preference value. A MAP with a preference value of zero SHOULD NOT be used for new local BUs (i.e., the mobile node can refresh existing bindings but cannot create new ones). However, a mobile node MAY choose to register with one MAP over another, depending on the value received in the Distance field, provided that the preference value is above zero.
持っている中で好みの値最も高いMAPがあるモバイルノードSHOULDレジスタ。 SHOULD NOTがない好みの値が新しい地方のBUs(すなわち、モバイルノードは、既存の結合をリフレッシュできますが、新しいものを作成できない)に使用されているMAP。 しかしながら、モバイルノードは、別のものの上に1MAPとともに記名するのを選ぶかもしれません、Distance分野の対価領収によって、ゼロより上に好みの値があれば。
A MAP option containing a valid lifetime value of zero means that this MAP MUST NOT be selected by the MN. A valid lifetime of zero indicates a MAP failure. When this option is received, a mobile node MUST choose another MAP and create new bindings. Any existing bindings with this MAP can be assumed to be lost. If no other MAP is available, the mobile node MUST revert to using the Mobile IPv6 protocol, as specified in [1].
ゼロの有効な生涯値を含むMAPオプションは、このMAP MUST NOTがミネソタによって選択されることを意味します。 ゼロの有効な寿命はMAPの故障を示します。 このオプションが受け取られているとき、モバイルノードは、別のMAPを選んで、新しい結合を作成しなければなりません。 このMAPとのどんな既存の結合も失われると思うことができます。 他のどんなMAPも利用可能でないなら、モバイルノードはモバイルIPv6プロトコルを使用するのに戻らなければなりません、[1]で指定されるように。
If a multihomed mobile node has access to several ARs simultaneously (on different interfaces), it SHOULD use an LCoA on the link defined by the AR that advertises its current MAP.
「マルチ-家へ帰」っているモバイルであるなら、ノードは同時(異なったインタフェースで)に数個のARsに近づく手段を持って、それはリンクの上のLCoAが現在のMAPの広告を出すARで定義したSHOULD使用です。
A mobile node MUST store the received option(s) in order to choose at least one MAP to register with. Storing the options is essential, as they will be compared to other options received later for the purpose of the movement detection algorithm.
モバイルノードは、少なくとも1MAPを選ぶために容認されたオプションを保存しなければなりません。ともに記名するために。 オプションを保存するのは不可欠です、動き検出アルゴリズムの目的のために後で受け取られた別の選択肢と比べるとき。
If no MAP options are found in the router advertisement, the mobile node MUST use the Mobile IPv6 protocol, as specified in [1].
MAPオプションが全くルータ通知で見つけられないなら、モバイルノードはモバイルIPv6プロトコルを使用しなければなりません、[1]で指定されるように。
If the R flag is set, the mobile node MUST use its RCoA as the Home Address when performing the MAP registration. RCoA is then bound to the LCoA in the MAP's Binding Cache.
MAP登録を実行するとき、R旗が設定されるなら、モバイルノードはホームAddressとしてRCoAを使用しなければなりません。 そして、RCoAはMAPのBinding CacheのLCoAに縛られます。
A mobile node MAY choose to register with more than one MAP simultaneously, or use both the RCoA and its LCoA as care-of addresses simultaneously with different correspondent nodes.
同時に1MAPとともに記名するか、またはRCoAとそのLCoAの両方を使用する、モバイルノードが、選ぶかもしれない注意、-、同時に、異なった通信員ノードで扱います。
8. Updating Previous MAPs
8. 前の地図をアップデートします。
When a mobile node moves into a new MAP domain, the mobile node may send a BU to the previous MAP requesting it to forward packets addressed to the mobile node's new CoA. An administrator MAY restrict the MAP from forwarding packets to LCoAs outside the MAP's
モバイルノードが新しいMAPドメインに移行すると、モバイルノードはモバイルノードの新しいCoAに扱われたパケットを進めるようそれに要求する前のMAPにBUを送るかもしれません。 管理者はMAPのところの外でMAPを推進パケットからLCoAsに制限するかもしれません。
Soliman, et al. Experimental [Page 16] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[16ページ]RFC4140HMIPv6 August 2005
domain. However, it is RECOMMENDED that MAPs be allowed to forward packets to LCoAs associated with some of the ARs in neighbouring MAP domains, provided that they are located within the same administrative domain.
ドメイン。 しかしながら、MAPsが隣接しているMAPドメインでいくつかのARsに関連しているLCoAsにパケットを送ることができるのは、RECOMMENDEDです、それらが同じ管理ドメインの中に位置していれば。
For instance, a MAP could be configured to forward packets to LCoAs associated with ARs that are geographically adjacent to ARs on the boundary of its domain. This will allow for a smooth inter-MAP handover as it allows the mobile node to continue to receive packets while updating the new MAP, its HA and, potentially, correspondent nodes.
例えば、地理的にドメインを境としたARsに隣接しているARsに関連しているLCoAsにパケットを送るためにMAPを構成できました。 モバイルノードが、それで新しいMAP、HA、および潜在的に通信員ノードをアップデートしている間、パケットを受け続けることができて、これは滑らかな相互MAP引き渡しを考慮するでしょう。
9. Notes on MAP Selection by the Mobile Node
9. モバイルノードによる地図選択に関する注
HMIPv6 provides a flexible mechanism for local mobility management within a visited network. As explained earlier, a MAP can exist anywhere in the operator's network (including the AR). Several MAPs can be located within the same domain independently of each other. In addition, overlapping MAP domains are also allowed and recommended. Both static and dynamic hierarchies are supported.
HMIPv6は訪問されたネットワークの中でローカルの移動性管理にフレキシブルなメカニズムを提供します。 より早く説明されるように、MAPはオペレータのネットワークでどこでも存在できます(ARを含んでいて)。 数個のMAPsが互いの如何にかかわらず同じドメインの中に位置できます。 さらに、重なっているMAPドメインは、また、許容されていてお勧めです。 静的なものと同様にダイナミックな階層構造はサポートされます。
When the mobile node receives a router advertisement including a MAP option, it should perform actions according to the following movement detection mechanisms. In a Hierarchical Mobile IP network such as the one described in this document, the mobile node should be:
モバイルノードがMAPオプションを含むルータ通知を受け取るとき、以下の動き検出メカニズムによると、それは動作を実行するべきです。本書では説明されたものなどのHierarchicalのモバイルIPネットワークでは、モバイルノードは以下の通りであるべきです。
- "Eager" to perform new bindings
- "Lazy" in releasing existing bindings
- 既存の結合をリリースするのにおいて「怠惰な」新しい結合を実行することを「切望しています」。
The above means that the mobile node should register with any "new" MAP advertised by the AR (Eager). The method by which the mobile node determines whether the MAP is a "new" MAP is described in section 9.1. The mobile node should not release existing bindings until it no longer receives the MAP option (or receives it with a lifetime of zero) or the lifetime of its existing binding expires (Lazy). This Eager-Lazy approach, described above, will assist in providing a fallback mechanism in case of the failure of one of the MAP routers, as it will reduce the time it takes for a mobile node to inform its correspondent nodes and HA about its new care-of address.
モバイルノードがAR(切望している)によって広告を出されるどんな「新しい」MAPにも登録するはずである上の手段。 モバイルノードがMAPが「新しい」MAPであるかどうか決定するメソッドはセクション9.1で説明されます。 もうオプション(または、ゼロの生涯でそれを受ける)か既存の結合の寿命が吐き出す(怠惰な)MAPを受けないまで、モバイルノードは既存の結合をリリースするはずがありません。 上で説明されたこのEager怠惰なアプローチが、MAPルータの1つの失敗の場合に後退メカニズムを提供するのを助けて、わざわざモバイルノードがその通信員のノードとHAのそれが受け取ったことを知らせる短縮するのに従ってそれが新しい、注意、-、アドレス。
9.1. MAP Selection in a Distributed-MAP Environment
9.1. 分配された地図環境における地図選択
The mobile node needs to consider several factors to optimally select one or more MAPs, where several MAPs are available in the same domain.
モバイルノードは、いくつかの要素が数個のMAPsが同じドメインで利用可能である1MAPsを最適に選択すると考える必要があります。
Soliman, et al. Experimental [Page 17] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[17ページ]RFC4140HMIPv6 August 2005
There are no benefits foreseen in selecting more than one MAP and
forcing packets to be sent from the higher MAP down through a
hierarchy of MAPs. This approach may add forwarding delays and
eliminate the robustness of IP routing between the highest MAP and
the mobile node; therefore, it is prohibited by this specification.
Allowing more than one MAP ("above" the AR) within a network should
not imply that the mobile node forces packets to be routed down the
hierarchy of MAPs. However, placing more than one MAP "above" the AR
can be used for redundancy and as an optimisation for the different
mobility scenarios experienced by mobile nodes. The MAPs are used
independently of each other by the MN (e.g., each MAP is used for
communication to a certain set of CNs).
1MAPを選択して、パケットをより高いMAPからMAPsの階層構造まで送らせる際に見通された利益が全くありません。 このアプローチは、最も高いMAPとモバイルノードの間で推進遅れを加えて、IPルーティングの丈夫さを取り除くかもしれません。 したがって、それはこの仕様で禁止されています。 1MAPを許容する、(“above"、AR) 中では、パケットがモバイルノードによってネットワークによってやむを得ずMAPsの階層構造の下側に発送されないつもりであるべきです。 しかしながら、1MAP “above"を置いて、冗長とモバイルノードによって経験された異なった移動性シナリオのための最適化としてARを使用できます。 MAPsは互いの如何にかかわらずミネソタによって使用されます(例えば各MAPはコミュニケーションにCNsのあるセットに使用されます)。
In terms of the Distance-based selection in a network with several MAPs, a mobile node may choose to register with the furthest MAP to avoid frequent re-registrations. This is particularly important for fast mobile nodes that will perform frequent handoffs. In this scenario, the choice of a more distant MAP would reduce the probability of having to change a MAP and informing all correspondent nodes and the HA. This specification does not provide an algorithm for the distance-based MAP selection. However, such an algorithm may be introduced in future extensions utilising information about the speed of mobility from lower layers.
数個のMAPsとのネットワークにおけるDistanceベースの選択で、モバイルノードは、頻繁な再登録証明書を避けるために最も遠いMAPとともに記名するのを選ぶかもしれません。 頻繁なhandoffsを実行する速いモバイルノードには、これは特に重要です。 このシナリオでは、より遠方のMAPの選択はMAP、すべての通信員ノードを知らせて、およびHAを変えなければならないという確率を減少させるでしょう。 この仕様は距離ベースのMAP選択のためのアルゴリズムを提供しません。 しかしながら、下層から移動性の速度の情報を利用する今後の拡大でそのようなアルゴリズムを導入するかもしれません。
In a scenario where several MAPs are discovered by the mobile node in one domain, the mobile node may need some sophisticated algorithms to be able to select the appropriate MAP. These algorithms would have the mobile node speed as an input (for distance based selection) combined with the preference field in the MAP option. However, this specification proposes that the mobile node uses the following algorithm as a default, where other optimised algorithms are not available. The following algorithm is simply based on selecting the MAP that is most distant, provided that its preference value did not reach a value of zero. The mobile node operation is shown below:
数個のMAPsが1つのドメインでモバイルノードによって発見されるシナリオでは、モバイルノードは、いくつかの高度なアルゴリズムが適切なMAPを選択できる必要があるかもしれません。 入力(距離が選択を基礎づけたので)がMAPオプションにおける選択領域に結合したので、これらのアルゴリズムには、モバイルノード速度があるでしょう。 しかしながら、この仕様は、モバイルノードがデフォルトとして以下のアルゴリズムを使用するよう提案します。(そこでは、他の最適化されたアルゴリズムが利用可能ではありません)。 以下のアルゴリズムは単に最も遠方であるMAPを選択するのに基づいています、好みの値がゼロの値に達しなかったならば。 モバイルノード手術は以下に示されます:
1. Receive and parse all MAP options
2. Arrange MAPs in a descending order, starting with the furthest
away MAP (i.e., MAP option having largest Dist field)
3. Select first MAP in list
4. If either the preference value or the valid lifetime fields are
set to zero, select the following MAP in the list.
5. Repeat step (4) while new MAP options still exist, until a MAP is
found with a non-zero preference value and a non-zero valid
lifetime.
1. すべてのMAPオプション2を受けて、分析してください。 遠くの最も遠さからMAP(すなわち、持っている中でDist分野最も大きいMAPオプション)3を始めて、降順でMAPsをアレンジしてください。 リスト4で最初のMAPを選択してください。 好みの値か有効な生涯分野のどちらかがゼロに設定されるなら、リストで以下のMAPを選択してください。 5. 新しいMAPオプションがまだ存在している間、ステップ(4)を繰り返してください、MAPが非ゼロ好みの価値と非ゼロの有効な生涯で見つけられるまで。
Soliman, et al. Experimental [Page 18] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[18ページ]RFC4140HMIPv6 August 2005
Implementing the steps above would result in mobile nodes selecting, by default, the most distant or furthest available MAP. This will continue until the preference value reduces to zero. Following this, mobile nodes will start selecting another MAP.
デフォルトで最も遠方の、または、最も遠い利用可能なMAPを選択するのは上にモバイルノードに結果として生じて、ステップを実装するでしょう。 好みの値がゼロまで減少するまで、これは続くでしょう。 これに続いて、モバイルノードは別のMAPを選択し始めるでしょう。
9.2. MAP Selection in a Flat Mobility Management Architecture
9.2. 平坦な移動性管理体系における地図選択
Network operators may choose a flat architecture in some cases where a Mobile IPv6 handover may be considered a rare event. In these scenarios, operators may choose to include the MAP function in ARs only. The inclusion of the MAP function in ARs can still be useful to reduce the time required to update all correspondent nodes and the HA. In this scenario, a mobile node may choose a MAP (in the AR) as an anchor point when performing a handoff. This kind of dynamic hierarchy (or anchoring) is only recommended for cases where inter-AR u0movement is not frequent.
ネットワーク・オペレータはモバイルIPv6引き渡しがめったにない事件であると考えられるかもしれないいくつかの場合における平坦なアーキテクチャを選ぶかもしれません。 これらのシナリオでは、オペレータは、ARsだけにMAP機能を含んでいるのを選ぶかもしれません。 ARsでのMAP機能の包含は、すべての通信員ノードとHAをアップデートするのに必要である時間を短縮するためにまだ役に立っている場合があります。 移管を実行するとき、このシナリオでは、モバイルノードはアンカー・ポイントとしてMAP(ARの)を選ぶかもしれません。 この種類のダイナミックな階層構造(または、投錨)は相互AR u0movementが頻繁でないケースのために推薦されるだけです。
10. Detection and Recovery from MAP Failures
10. 地図の故障からの検出と回復
This specification introduces a MAP that can be seen as a local Home Agent in a visited network. A MAP, like a Home Agent, is a single point of failure. If a MAP fails, its binding cache content will be lost, resulting in loss of communication between mobile and correspondent nodes. This situation may be avoided by using more than one MAP on the same link and by utilising some form of context transfer protocol between them. Alternatively, future versions of the Virtual Router Redundancy Protocol [4] or HA redundancy protocols may allow networks to recover from MAP failures.
この仕様は訪問されたネットワークで地元のホームのエージェントと考えることができるMAPを導入します。 ホームのエージェントのように、MAPは1ポイントの失敗です。 MAPが失敗すると、拘束力があるキャッシュ内容は失われるでしょう、モバイルと通信員ノードとのコミュニケーションの損失をもたらして。 この状況は、同じリンクの上に1MAPを使用して、それらの間で何らかのフォームの文脈転送プロトコルを利用することによって、避けられるかもしれません。 あるいはまた、Virtual Router Redundancyプロトコル[4]かHA冗長プロトコルの将来のバージョンで、ネットワークはMAPの故障から回復するかもしれません。
In cases where such protocols are not supported, the mobile node would need to detect MAP failures. The mobile node can detect this situation when it receives a router advertisement containing a MAP option with a lifetime of zero. The mobile node should start the MAP discovery process and attempt to register with another MAP. After it has selected and registered with another MAP, it will also need to inform correspondent nodes and the Home Agent if its RCoA has changed. Note that in the presence of a protocol that transfers binding cache entries between MAPs for redundancy purposes, a new MAP may be able to provide the same RCoA to the mobile node (e.g., if both MAPs advertise the same prefix in the MAP option). This would save the mobile node from updating correspondent nodes and the Home Agent.
そのようなプロトコルがサポートされない場合では、モバイルノードは、MAPの故障を検出する必要があるでしょう。 それがゼロの生涯でMAPオプションを含むルータ通知を受け取るとき、モバイルノードはこの状況を検出できます。 モバイルノードは別のMAPに登録するMAP発見プロセスと試みを始めるはずです。 また、別のMAPを選択して、ともに記名した後に、それは、RCoAが変化したかどうかを通信員ノードとホームのエージェントに知らせる必要があるでしょう。 冗長目的のために拘束力があるキャッシュエントリーをMAPsの間に移すプロトコルがあるとき新しいMAPが同じRCoAをモバイルノードに提供できるかもしれないことに注意してください(例えば、両方のMAPsがMAPオプションにおける同じ接頭語の広告を出すなら)。 これは通信員ノードとホームのエージェントをアップデートするのからのモバイルノードを保存するでしょう。
Access routers can be triggered to advertise a MAP option with a lifetime of zero (indicating MAP failure) in different ways:
ゼロ(MAPの故障を示す)の生涯で異なった方法でMAPオプションの広告を出すためにアクセスルータを引き起こすことができます:
- By manual intervention.
- In a dynamic manner.
- 手動の介入で。 - ダイナミックな方法で。
Soliman, et al. Experimental [Page 19] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[19ページ]RFC4140HMIPv6 August 2005
ARs can perform Dynamic detection of MAP failure by sending ICMP Echo request messages to the MAP regularly (e.g., every ten seconds). If no response is received, an AR may try to aggressively send echo requests to the MAP for a short period of time (e.g., once every 5 seconds for 15 seconds); if no reply is received, a MAP option may be sent with a valid lifetime value of zero.
ARsは、要求メッセージをICMP Echoに送ることによって、MAPの故障のDynamic検出をMAPに定期的(例えばあらゆる10秒)に実行できます。 どんな応答も受け取られていないなら、ARは積極的に短期間の間のMAP(例えば、15秒間のかつての5秒毎)にエコー要求を送ろうとするかもしれません。 どんな回答も受け取られていないなら、ゼロの有効な生涯値と共にMAPオプションを送るかもしれません。
This specification does not mandate a particular recovery mechanism. However, any similar mechanism between the MAP and an AR SHOULD be secure to allow for message authentication, integrity protection, and protection against replay attacks.
この仕様は特定の回収機構を強制しません。 しかしながら、どんな同様のメカニズム、もMAPとAR SHOULDの間では、通報認証、保全保護、および反射攻撃に対する保護を考慮するために安全であってください。
11. IANA Considerations
11. IANA問題
Section 4 introduces a new flag (M) to the Binding Update specified in RFC 3775.
セクション4はRFC3775で指定されたBinding Updateに新しい旗(M)を紹介します。
Section 5 introduces a new IPv6 Neighbour Discovery Option called the MAP Option. IANA has assigned the Option Type value 23 for the MAP Option within the option numbering space for IPv6 Neighbour Discovery messages.
セクション5はMAP Optionと呼ばれる新しいIPv6 NeighbourディスカバリーOptionを導入します。 IANAは、MAP OptionのためにIPv6 Neighbourディスカバリーメッセージのためにスペースに付番しながら、オプションの中でOption Type値23を割り当てました。
12. Security Considerations
12. セキュリティ問題
This specification introduces a new concept to Mobile IPv6, namely, a Mobility Anchor Point that acts as a local Home Agent. It is crucial that the security relationship between the mobile node and the MAP is strong; it MUST involve mutual authentication, integrity protection, and protection against replay attacks. Confidentiality may be needed for payload traffic, but is not required for binding updates to the MAP. The absence of any of these protections may lead to malicious mobile nodes impersonating other legitimate ones or impersonating a MAP. Any of these attacks will undoubtedly cause undesirable impacts to the mobile node's communication with all correspondent nodes having knowledge of the mobile node's RCoA.
この仕様はすなわち、モバイルIPv6、地元のホームのエージェントとして務めるMobility Anchor Pointに新しい概念を紹介します。 可動のノードとMAPの間の安全保障関係が強いのは、重要です。 それは互いの認証、保全保護、および反射攻撃に対する保護にかかわらなければなりません。 秘密性は、ペイロード交通に必要であるかもしれませんが、拘束力があるアップデートにMAPに必要ではありません。 これらの保護のどれかの不在は他の正統のものをまねるか、またはMAPをまねる悪意がある可動のノードにつながるかもしれません。 これらの攻撃のいずれも確かに可動のノードのRCoAに関する知識を持っているすべての通信員ノードとの可動のノードのコミュニケーションに望ましくない衝撃を引き起こすでしょう。
Three different relationships (related to securing binding updates) need to be considered:
異なった関係(拘束力があるアップデートを保証すると関連される)が考えられる必要がある3:
1) The mobile node - MAP
2) The mobile node - Home Agent
3) The mobile node - correspondent node
1) 可動のノード--MAP2) 可動のノード--ホームのエージェント3) 可動のノード--通信員ノード
12.1. Mobile Node-MAP Security
12.1. モバイルノード地図セキュリティ
In order to allow a mobile node to use the MAP's forwarding service, initial authorisation (specifically for the service, not for the RCoA) MAY be needed. Authorising a mobile node to use the MAP
可動のノードがMAPの推進サービスを利用するのを許容するために、初期の認可(特にRCoAではなく、サービスのための)が必要であるかもしれません。 可動のノードがMAPを使用するのを認可します。
Soliman, et al. Experimental [Page 20] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[20ページ]RFC4140HMIPv6 August 2005
service can be done based on the identity of the mobile node exchanged during the SA negotiation process. The authorisation may be granted based on the mobile node's identity, or based on the identity of a Certificate Authority (CA) that the MAP trusts. For instance, if the mobile node presents a certificate signed by a trusted entity (e.g., a CA that belongs to the same administrative domain, or another trusted roaming partner), it would be sufficient for the MAP to authorise the use of its service. Note that this level of authorisation is independent of authorising the use of a particular RCoA. Similarly, the mobile node would trust the MAP if it presents a certificate signed by the same CA or by another CA that the mobile node is configured to trust (e.g., a roaming partner).
SA交渉の過程の間に交換された可動のノードのアイデンティティに基づいてサービスできます。 認可は、可動のノードのアイデンティティに基づいて承諾されるか、またはMAPが信じるCertificate Authority(カリフォルニア)のアイデンティティに基づくかもしれません。 例えば、可動のノードが信じられた実体(例えば、同じ管理ドメイン、または別の信じられたローミングパートナーのものであるカリフォルニア)によってサインされた証明書を提示するなら、MAPがサービスの使用を認可するのは、十分でしょう。 このレベルの認可が特定のRCoAの使用を認可するのから独立していることに注意してください。 同様に、可動のノードが信じるために構成される同じカリフォルニアか別のカリフォルニアによってサインされた証明書(例えば、ローミングパートナー)を提示するなら、可動のノードはMAPを信じるでしょう。
HMIPv6 uses an additional registration between the mobile node and its current MAP. As explained in this document, when a mobile node moves into a new domain (i.e., served by a new MAP), it obtains an RCoA, an LCoA and registers the binding between these two addresses with the new MAP. The MAP then verifies whether the RCoA has not been registered yet and, if so, it creates a binding cache entry with the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to send a new BU that specifies the binding between RCoA and its new LCoA. This BU needs to be authenticated, otherwise any host could send a BU for the mobile node's RCoA and hijack the mobile node's packets. However, because the RCoA is temporary and is not bound to a particular node, a mobile node does not have to initially (before the first binding update) prove that it owns its RCoA (unlike the requirement on home addresses in Mobile IPv6) when it establishes a Security Association with its MAP. A MAP only needs to ensure that a BU for a particular RCoA was issued by the same mobile node that established the Security Association for that RCoA.
HMIPv6は可動のノードとその現在のMAPの間の追加登録を使用します。 本書では説明されるように、可動のノードが新しいドメイン(すなわち、新しいMAPが役立たれている)に動くと、それは、RCoA、LCoAを入手して、これらの2つのアドレスの間の結合を新しいMAPに登録します。 次に、MAPは、RCoAがまだ登録されていないかどうか確かめます、そして、そうだとすれば、それはRCoAとLCoAとの拘束力があるキャッシュエントリーを作成します。 可動のノードが新しいLCoAを手に入れるときはいつも、それは、RCoAとその新しいLCoAの間に結合を指定する新しいBUを送る必要があります。 このBUが、認証される必要があって、さもなければ、どんなホストも、可動のノードのRCoAのためにBUを送って、可動のノードのパケットをハイジャックできました。 しかしながら、RCoAが一時的であり、特定のノードに縛られないので、可動のノードは、初めは、MAPと共にSecurity Associationを設立するとRCoA(モバイルIPv6のホームアドレスに関する要件と異なった)を所有していると立証する必要はありません(最初の拘束力があるアップデートの前に)。 MAPは、特定のRCoAのためのBUがそのRCoAのためにSecurity Associationを設立したのと同じ可動のノードによって発行されたのを保証する必要があるだけです。
The MAP does not need to have prior knowledge of the identity of the mobile node nor its Home Address. As a result the SA between the mobile node and the MAP can be established using any key establishment protocols such as IKE. A return routability test is not necessary.
MAPは可動のノードのアイデンティティに関する先の知識を持つ必要性かそのどんなホームにもAddressをしません。 その結果、IKEなどのどんな主要な設立プロトコルも使用することで可動のノードとMAPの間のSAを設立できます。 リターンroutabilityテストは必要ではありません。
The MAP needs to set the SA for the RCoA (not the LCoA). This can be performed with IKE [2]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA. This is achieved by using the RCoA as the identity in IKE Phase 2 negotiation. This step is identical to the use of the home address in IKE phase 2.
MAPは、RCoA(LCoAでない)にSAを設定する必要があります。 IKE[2]と共にこれを実行できます。 可動のノードは、ソースアドレスとしてLCoAを使用しますが、RCoAがSAで使用されるべきであると指定します。 これは、アイデンティティとしてIKE Phase2交渉にRCoAを使用することによって、達成されます。 このステップはIKEフェーズ2におけるホームアドレスの使用と同じです。
If a binding cache entry exists for a given RCoA, the MAP's IKE policy check MUST point to the SA used to install the entry. If the mobile node's credentials stored in the existing SA do not match the ones provided in the current negotiation, the MAP MUST reject the new
拘束力があるキャッシュエントリーが与えられたRCoAのために存在しているなら、MAPのIKE方針チェックはエントリーをインストールするのに使用されるSAを示さなければなりません。 現在の交渉では、MAP MUSTが新しさを拒絶するなら既存のSAに格納された可動のノードの信任状がものに合っていないなら
Soliman, et al. Experimental [Page 21] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[21ページ]RFC4140HMIPv6 August 2005
SA establishment request for such RCoA with an INVALID-ID-INFORMATION notification [2]. This is to prevent two different mobile nodes from registering (intentionally or not) the same RCoA. Upon receiving this notification, the mobile node SHOULD generate a new RCoA and restart the IKE negotiation. Alternatively, a MAP may decide that, if a binding cache entry already exists for a particular RCoA, no new security association should be established for such RCoA; this is independent of the mobile node credentials. This prevents the mobile node from being able to re-establish a security association for the same RCoA (i.e., to change session keys). However, this is not a major problem because the SA will typically only be used to protect signalling traffic when a MN moves, and not for the actual data traffic sent to arbitrary nodes.
SA設立はそのようなもののためにINVALID ID情報通知[2]でRCoAを要求します。 または、これが2つの異なった可動のノードが登録するのを防ぐためのものである、(故意に、)、同じRCoA。 この通知を受け取ると、可動のノードSHOULDは新しいRCoAを発生させて、IKE交渉を再開します。 あるいはまた、MAPは、拘束力があるキャッシュエントリーが特定のRCoAのために既に存在しているならどんな新しいセキュリティ協会もそのようなRCoAのために設立されるべきでないと決めるかもしれません。 これは可動のノード信任状から独立しています。 これは、可動のノードが同じRCoA(すなわち、変化セッションキーへの)のためにセキュリティ協会を復職させることができるのを防ぎます。 しかしながら、SAがミネソタが動くとき、合図交通を保護するのに通常使用されるだけであるので、これはそして、任意のノードに送られた実際のデータ通信量への大した問題ではありません。
Binding updates between the MAP and the mobile node MUST be protected with either AH or ESP in transport mode. When ESP is used, a non- null authentication algorithm MUST be used.
交通機関におけるAHか超能力のどちらかでMAPと可動のノードの間の拘束力があるアップデートを保護しなければなりません。 超能力が使用されているとき、非ヌルの認証アルゴリズムを使用しなければなりません。
12.2. Mobile Node-Correspondent Node Security
12.2. モバイルノード通信員ノードセキュリティ
Mobile IPv6 [1] defines a return routability procedure that allows mobile and correspondent nodes to authenticate binding updates and acknowledgements. This specification does not impact the return routability test defined in [1]. However, it is important to note that mobile node implementers need to be careful when selecting the source address of the HOTI and COTI messages, defined in [1]. The source address used in HOTI messages MUST be the mobile node's home address. The packet containing the HOTI message is encapsulated twice. The inner encapsulating header contains the RCoA in the source address field and the home agent's address in the destination address field. The outer encapsulating header contains the mobile node's LCoA in the source address field and the MAP's address in the destination field.
モバイルIPv6[1]は可動、そして、通信員ノードが拘束力があるアップデートと承認を認証できるリターンroutability手順を定義します。 この仕様は[1]で定義されたリターンroutabilityテストに影響を与えません。 しかしながら、[1]で定義されたHOTIとCOTIメッセージのソースアドレスを選択するとき、implementersが必要とするその可動のノードが慎重であることに注意するのは重要です。 HOTIメッセージで使用されるソースアドレスは可動のノードのホームアドレスであるに違いありません。 HOTIメッセージを含むパケットは二度カプセルに入れられます。 内側の要約のヘッダーは目的地アドレス・フィールドのソースアドレス分野と家のエージェントのアドレスにRCoAを保管しています。 外側の要約のヘッダーはあて先フィールドのソースアドレス分野とMAPのアドレスに可動のノードのLCoAを保管しています。
12.3. Mobile Node-Home Agent Security
12.3. モバイルノードホームエージェントセキュリティ
The security relationship between the mobile node and its Home Agent, as discussed in [1], is not impacted by this specification.
この仕様で可動のノードとそのホームのエージェントの間の[1]で議論する安全保障関係は影響を与えられません。
13. Acknowledgments
13. 承認
The authors would like to thank Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their valuable input to this document. The authors would also like to thank the members of the French RNRT MobiSecV6 project (BULL, France Telecom and INRIA) for testing the first implementation and for their valuable feedback. The INRIA HMIPv6 project is partially funded by the French Government.
作者はこのドキュメントへの彼らの貴重な入力についてコニー・ラーソン(エリクソン)とマティアス・ペテルソン(エリクソン)に感謝したがっています。 また、作者は最初の実現をテストして、彼らの有益なフィードバックについてフランスのRNRT MobiSecV6プロジェクト(BULL、フランステレコム、およびINRIA)のメンバーに感謝したがっています。 INRIA HMIPv6プロジェクトはフランスの政府によって部分的に資金を供給されます。
Soliman, et al. Experimental [Page 22] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[22ページ]RFC4140HMIPv6 August 2005
In addition, the authors would like to thank the following members of the working group in alphabetical order: Samita Chakrabarti (Sun), Gregory Daley (Monash University), Francis Dupont (GET/Enst Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash University), and Alper Yegin (Samsung) for their comments on the document.
さらに、作者はアルファベット順にワーキンググループの以下のメンバーに感謝したがっています: 彼らのコメントのためのドキュメントの上のゴパルDommety(シスコ)、エバGustaffson(エリクソン)デーブ・ジョンソン(ライス大学)、アニカイェンソン(エリクソン)ジェームス・ケンフ(Docomo研究室)、マルッティKuparinen(エリクソン)のSamita Chakrabarti(Sun)、グレゴリー・デイリー(モナッシュ大学)、フランシス・デュポン(GET/Enstブルターニュ)、Fergal Ladley、ガブリエル・モンテネグロ(Sun)、ニック・「シャーキー」ムーア(モナッシュ大学)エリックNordmark(Sun)、Basavarajパティル(ノキア)、ブレットPentland(モナッシュ大学)、およびAlper Yegin(三星)。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[1] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[2] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
14.2. Informative References
14.2. 有益な参照
[4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
2005.
[4] Koodli(R.)は「速く、モバイルIPv6"、RFCのために、4068、2005年7月を引き渡します」。
[5] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000.
[5] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[6]ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
Soliman, et al. Experimental [Page 23] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[23ページ]RFC4140HMIPv6 August 2005
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6
付録A: 速いモバイルIPv6身柄の引き渡しとHMIPv6
Fast Handovers are required to ensure that the layer 3 (Mobile IP) handover delay is minimised, thus also minimising, and possibly eliminating, the period of service disruption which normally occurs when a mobile node moves between two ARs. This period of service disruption usually occurs due to the time required by the mobile node to update its HA using Binding Updates after it moves between ARs. During this time period the mobile node cannot resume or continue communications. The mechanism to achieve Fast Handovers with Mobile IPv6 is described in [5] and is briefly summarised here. This mechanism allows the anticipation of the layer 3 handover, such that data traffic can be redirected to the mobile node's new location before it moves there.
速く、Handoversは、層3(モバイルIP)の引き渡し遅れが最小となって、その結果、また、最小となって、ことによると排泄しているのを保証しなければなりません、可動のノードが2ARsの間を動くと通常、起こる勤続期間分裂。 通常、この勤続期間分裂はARsの間を動いた後にBinding Updatesを使用することでHAをアップデートするために可動のノードによって必要とされた時間のため起こります。 この期間、可動のノードは、コミュニケーションを再開できませんし、続けることができません。 モバイルIPv6と共にFast Handoversを達成するメカニズムについて、[5]で説明されて、簡潔にここに略言します。 このメカニズムは層の予期に3引き渡しを許します、そこに動く前に可動のノードの新しい位置にデータ通信量を向け直すことができるように。
While the mobile node is connected to its previous Access Router (PAR) and is about to move to a new Access Router (NAR), the Fast Handovers in Mobile IPv6 requires in sequence:
可動のノードは、前のAccess Router(PAR)に接続されて、新しいAccess Router(NAR)に動くことになっていようとしていますが、モバイルIPv6のFast Handoversは連続して以下を必要とします。
1) The mobile node to obtain a new care-of address at the NAR while
connected to the PAR.
1) 新しい状態でaを得る可動のノード、注意、-、NARでは、PARに接続されている間、記述します。
2) New CoA to be used at NAR case: the mobile node to send a F-BU
(Fast BU) to its previous anchor point (i.e., PAR) to update its
binding cache with the mobile node's new CoA while still attached
to PAR.
2) NARで使用されるべき新しいCoAは以下をケースに入れます。 可動のノードの新しいCoAと共に拘束力があるキャッシュをアップデートするために、F-BU(速いBU)を前のアンカー・ポイント(すなわち、PAR)に送る可動のノードはまだPARに付いていました。
3) The previous anchor point (i.e., PAR) to start forwarding packets
destined for the mobile node to the mobile node's new CoA at NAR
(or old CoA tunnelled to NAR, if new CoA is not applicable).
3) パケットを進め始める前のアンカー・ポイント(すなわち、PAR)は可動のノードのためにNARで可動のノードの新しいCoAに運命づけられました(新しいCoAが適切でないなら、古いCoAはNARにトンネルを堀りました)。
4) Old CoA to be used at NAR case: the mobile node to send a F-BU
(Fast BU) to its previous anchor point (i.e., PAR), after it has
moved and attached to NAR, in order to update its binding cache
with the mobile node's new CoA.
4) NARで使用されるべき古いCoAは以下をケースに入れます。 それの後の前のアンカー・ポイント(すなわち、PAR)にF-BU(速いBU)を送る可動のノードは、NARに動いて、付きました、可動のノードの新しいCoAと共に拘束力があるキャッシュをアップデートするために。
The mobile node or PAR may initiate the Fast Handover procedure by using wireless link-layer information or link-layer triggers that inform that the mobile node will soon be handed off between two wireless access points respectively attached to PAR and NAR. If the "trigger" is received at the mobile node, the mobile node will initiate the layer-3 handover process by sending a Proxy Router Solicitation message to PAR. Instead, if the "trigger" is received at PAR, then it will transmit a Proxy Router Advertisement to the appropriate mobile node, without the need for solicitations. The basic Fast Handover message exchanges are illustrated in Figure A.1.
可動のノードかPARが可動のノードがすぐそれぞれPARとNARに付けられた2ワイヤレス・アクセスポイントの間で離れて手渡される無線のリンクレイヤ情報か知らせるリンクレイヤ引き金を使用するのによるFast Handover手順に着手するかもしれません。 可動のノードに「引き金」を受け取ると、Proxy Router SolicitationメッセージをPARに送ることによって、可動のノードは層-3業務引き継ぎ作業に着手するでしょう。 代わりに、PARに「引き金」を受け取るなら、適切な可動のノードにProxy Router Advertisementを伝えるでしょう、懇願の必要性なしで。 基本的なFast Handover交換処理は図A.1で例証されます。
Soliman, et al. Experimental [Page 24] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[24ページ]RFC4140HMIPv6 August 2005
+-----------+ 1a. HI +-----+
| | ---------------->| NAR |
| PAR | 1b. HAck | |
+-----------+ <--------------- +-----+
^ | ^
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK)
| v v
+------------+
| MN |
+------------+ - - - - - ->
Movement
+-----------+ 1a。 HI+-----+ | | ---------------->| NAR| | 平価| 1b。 ハッキング| | +-----------+ <。--------------- +-----+ ^ | ^ (2a。 RtSolPr) | | 2b| | | Pr| 3. 速いBU(F-BU)| | RtAdv| 4. 速いBa(F逆)| v対+------------+ | ミネソタ| +------------+--、--、--、--、--、->運動
Figure A.1: Fast Mobile IPv6 Handover Protocol
A.1は計算します: 速いモバイルIPv6引き渡しプロトコル
The mobile node obtains a new care-of address while connected to PAR by means of router advertisements containing information from the NAR (Proxy Router Advertisement, which may be sent due to a Proxy Router Solicitation). The PAR will validate the mobile node's new CoA by sending a Handover Initiate (HI) message to the NAR. The new CoA sent in the HI message is formed by appending the mobile node's current interface identifier to the NAR's prefix. Based on the response generated in the Handover Acknowledge (HAck) message, the PAR will either generate a tunnel to the mobile node's new CoA (if the address was valid) or generate a tunnel to the NAR's address (if the address was already in use on the new subnet). If the address was already in use on the new subnet, it is assumed that there will be no time to perform another attempt to configure the mobile node with a CoA on the new link. Therefore, the NAR will generate a host route for the mobile node using its old CoA. Note that message 1a may precede message 2b or occur at the same time.
可動のノードが新しい状態でaを得る、注意、-、NAR(Proxy Router Solicitationのため送られるかもしれないプロキシRouter Advertisement)からの情報を含むルータ通知によってPARに接続されている間、記述します。 PARは、Handover Initiate(HI)メッセージをNARに送ることによって、可動のノードの新しいCoAを有効にするでしょう。 新しいCoAは、HIメッセージが可動のノードの現在のインタフェース識別子をNARの接頭語に追加することによって形成されるのを送りました。 Handover Acknowledge(HAck)メッセージで発生する応答に基づいて、PARは可動のノードの新しいCoA(アドレスが有効であったなら)にトンネルを発生させるか、またはNARのアドレスにトンネルを発生させるでしょう(アドレスが新しいサブネットで既に使用中であったなら)。 アドレスが新しいサブネットで既に使用中であったなら、新しいリンクの上にCoAで可動のノードを構成する別の試みを実行する時間が全くないと思われます。 したがって、NARは、可動のノードのために古いCoAを使用することでホストルートを発生させるでしょう。 メッセージ1aがメッセージ2bに先行するか、または同時に現れるかもしれないことに注意してください。
In [5], the ARs act as local Home Agents, which hold binding caches for the mobile nodes and receive Binding Updates. This makes these ARs function like the MAP specified in this document. Also, it is quite possible that the ARs are not directly connected, but communicate through an aggregation router. Therefore, such an aggregation router is also an ideal position for the MAP functionality. These are two ways of integrating the HMIPv6 and Fast Handover mechanisms. The first involves placing MAPs in place of the ARs, which is a natural step. The second scenario involves placing the MAP in an aggregation router "above" the ARs. In this case, [5] specifies forwarding of packets between PAR and NAR. This could be inefficient in terms of delay and bandwidth efficiency because packets will traverse the MAP-PAR link twice and packets will arrive out of order at the mobile node. Using the MAP in the aggregation
[5]では、ARsは地元のホームのエージェントとして務めます。(そのエージェントは、可動のノードのための拘束力があるキャッシュを保持して、Binding Updatesを受け取ります)。 これで、MAPが本書では指定したようにこれらのARsは機能します。 また、ARsが直接接続されないのも、かなり可能ですが、集合ルータを通って交信してください。 したがって、また、そのような集合ルータはMAPの機能性のための理想的な位置です。 これらはHMIPv6とFast Handoverメカニズムを統合する2つの方法です。1番目は、ARsに代わってMAPsを置くことを伴います。ARsは生まれながらのステップです。 2番目のシナリオは、集合ルータ“above"のMAP ARsを置くことを伴います。 この場合、[5]はPARとNARの間のパケットの推進を指定します。 パケットが二度MAP-PARリンクを横断して、パケットが可動のノードで故障していた状態で到着するので、これは遅れと帯域幅効率で効率が悪いかもしれません。 集合にMAPを使用します。
Soliman, et al. Experimental [Page 25] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[25ページ]RFC4140HMIPv6 August 2005
router would improve the efficiency of Fast Handovers, which could make use of the MAP to redirect traffic, thus saving delay and bandwidth between the aggregation router and the PAR.
ルータは交通を向け直すのにMAPを利用できたFast Handoversの効率を高めるでしょう、その結果、集合ルータとPARの間の遅れと帯域幅を救います。
+---------+
| MAP |
+-------------->| |
| +---------+
| | ^
| 1a. HI | |
| | |
| | | 1b. HAck
| v |
+---------+ | +---------+
| | | | NAR |
| PAR | | | |
+---------+ | +---------+
^ | |
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU) from mobile node to
| | MAP
| | RtAdv | 4. Fast BA (F-BACK) from MAP to
| | | mobile node
| v v
+------------+
| MN | Movement
+------------+ - - - - - ->
+---------+ | 地図| +-------------->|、|、| +---------+ | | ^ | 1a。 こんにちは| | | | | | | | 1b。 ハッキング| v| +---------+ | +---------+ | | | | NAR| | 平価| | | | +---------+ | +---------+ ^ | | (2a。 RtSolPr) | | 2b| | | Pr| 3. 可動のノードからの速いBU(F-BU)| | 地図| | RtAdv| 4. 地図からの速いBa(F逆)| | | 可動のノード| v対+------------+ | ミネソタ| 動き+------------+--、--、--、--、--、->。
Figure A.2: Fast Mobile IPv6 Handover Protocol using HMIPv6
A.2は計算します: HMIPv6を使用する速いモバイルIPv6引き渡しプロトコル
In Figure A.2, the HI/HAck messages now occur between the MAP and NAR in order to check the validity of the newly requested care-of address and to establish a temporary tunnel should the new care-of address not be valid. Therefore, the same functionality of the Fast Handover procedure is kept, but the anchor point is moved from the PAR to the MAP.
HI/HAckメッセージが現在新たに要求されていることの正当性をチェックするためにMAPとNARの間に図A.2では、現れる、注意、-、アドレス、aを証明するために、一時的なトンネルがそうするべきである、新しさ、注意、-、アドレス、有効であってください。 したがって、Fast Handover手順の同じ機能性は保たれますが、アンカー・ポイントはPARからMAPに移されます。
As in the previous Fast Handover procedure, in the network-determined case the layer-2 "triggers" at the PAR will cause the PAR to send a Proxy Router Advertisement to the mobile node with the MAP option. In the mobile-determined case, this is preceded by a Proxy Router Solicitation from the mobile node. The same layer-2 trigger at PAR in the network-determined case could be used to independently initiate Context Transfer (e.g., QoS) between PAR and NAR. In the mobile-determined case, the trigger at PAR could be replaced by the reception of a Proxy Router Solicitation or F-BU. Context Transfer is being worked on in the IETF Seamoby WG.
前のFast Handover手順、ネットワークが決定しているケースのように、PARの層-2「引き金」がPARにMAPオプションと共に可動のノードにProxy Router Advertisementを送らせるでしょう。 可動に決定している場合では、これはProxy Router Solicitationによって可動のノードから先行されています。 PARとNARの間で独自に、Context Transfer(例えば、QoS)を開始するのにネットワークが決定している場合におけるPARの同じ層-2引き金を使用できました。 可動に決定している場合では、PARの引き金をProxy Router SolicitationかF-BUのレセプションに取り替えることができました。 IETF Seamoby WGで文脈Transferを扱われています。
Soliman, et al. Experimental [Page 26] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[26ページ]RFC4140HMIPv6 August 2005
The combination of Fast Handover and HMIPv6 allows the anticipation of the layer 3 handoff, such that data traffic can be efficiently redirected to the mobile node's new location before it moves there. However, it is not easy to determine the correct time to start forwarding traffic from the MAP to the mobile node's new location, which has an impact on how smooth the handoff will be. The same issues arise in [5] with respect to when to start forwarding between PAR and NAR. Packet loss will occur if this is performed too late or too early with respect to the time in which the mobile node detaches from PAR and attaches to NAR. Such packet loss is likely to occur if the MAP updates its binding cache upon receiving the anticipated F-BU, because it is not known exactly when the mobile node will perform or complete the layer-2 handover to NAR, relative to when the mobile node transmits the F-BU. Also, some measure is needed to support the case in which the mobile node's layer-2 handover unexpectedly fails (after Fast Handover has been initiated) or when the mobile node moves quickly back-and-forth between ARs (ping-pong). Simultaneous bindings [6] provide a solution to these issues. In [6], a new Simultaneous Bindings Flag is added to the Fast Binding Update (F-BU) message and a new Simultaneous Bindings suboption is defined for the Fast Binding Acknowledgement (F-BAck) message. Using this enhanced mechanism, upon layer-3 handover, traffic for the mobile node will be sent from the MAP to both PAR and NAR for a certain period, thus isolating the mobile node from layer-2 effects such as handover timing, ping-pong, or handover failure and providing the mobile node with uninterrupted layer-3 connectivity.
Fast HandoverとHMIPv6の組み合わせは層の3移管の予期を許します、そこに動く前に効率的に可動のノードの新しい位置にデータ通信量を向け直すことができるように。 しかしながら、MAPから新しい影響力を持っている可動のノードの位置までの交通をどれくらい滑らかであるのを移管がなるか進め始めるか正しい時間を決定するのは簡単ではありません。 同じ問題は[5]にPARとNARの間でいつ進め始めるかに関して起こります。 これがあまりに遅いかあまりに早く可動のノードがNARにPARから取り外して、付く時間に関して実行されると、パケット損失は起こるでしょう。 予期されたF-BUを受けるときMAPが拘束力があるキャッシュをアップデートするなら、そのようなパケット損失は起こりそうです、可動のノードが層-2引き渡しをNARに実行するか、または終了する場合それがまさに知られていないので、可動のノードがF-BUを伝える時に比例して。 また、何らかの測定が、どの可動のノードの層-2の引き渡しが不意に失敗するか、そして、(Fast Handoverが開始された後に)または可動のノードがいつARs(ピンポン)の間をすばやく前後に動くかのケースを支えるのに必要です。 同時の結合[6]はこれらの問題の解決法を提供します。 [6]では、新しいSimultaneous Bindings FlagはFast Binding Update(F-BU)メッセージに追加されます、そして、新しいSimultaneous Bindings suboptionはFast Binding Acknowledgement(F-BAck)メッセージのために定義されます。 層-3引き渡しのときにこの高められたメカニズムを使用して、ある期間、MAPからPARとNARの両方に可動のノードのための交通を送るでしょう、その結果、引き渡しタイミング、ピンポン、または引き渡し失敗などの層-2回の影響から可動のノードを隔離して、とぎれない層-3の接続性を可動のノードに提供して。
Soliman, et al. Experimental [Page 27] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[27ページ]RFC4140HMIPv6 August 2005
Authors' Addresses
作者のアドレス
Hesham Soliman Flarion Technologies
HeshamソリマンFlarion Technologies
EMail: h.soliman@flarion.com
メール: h.soliman@flarion.com
Claude Castelluccia INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France
クロードCastelluccia INRIAローヌアルプ655大通りde l'Europe38330Montbonnotサンマルタンフランス
EMail: claude.castelluccia@inria.fr Phone: +33 4 76 61 52 15
メール: claude.castelluccia@inria.fr 電話: +33 4 76 61 52 15
Karim El Malki Ericsson AB LM Ericssons Vag. 8 126 25 Stockholm Sweden
カリム高架鉄道MalkiエリクソンAB LMエリクソンVag。 8 126 25ストックホルムスウェーデン
EMail: karim@elmalki.homeip.net
メール: karim@elmalki.homeip.net
Ludovic Bellier INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France
ルードビックBellier INRIAローヌアルプ655大通りde l'Europe38330Montbonnotサンマルタンフランス
EMail: ludovic.bellier@inria.fr
メール: ludovic.bellier@inria.fr
Soliman, et al. Experimental [Page 28] RFC 4140 HMIPv6 August 2005
ソリマン、他 実験的な[28ページ]RFC4140HMIPv6 August 2005
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Soliman, et al. Experimental [Page 29]
ソリマン、他 実験的[29ページ]
一覧
スポンサーリンク
