RFC5380 日本語訳
5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management. H.Soliman, C. Castelluccia, K. ElMalki, L. Bellier. October 2008. (Format: TXT=58330 bytes) (Obsoletes RFC4140) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Soliman
Request for Comments: 5380 Elevate Technologies
Obsoletes: 4140 C. Castelluccia
Category: Standards Track INRIA
K. ElMalki
Athonet
L. Bellier
INRIA
October 2008
コメントを求めるワーキンググループH.ソリマンの要求をネットワークでつないでください: 5380が上げる、技術は以下を時代遅れにします。 4140年のC.Castellucciaカテゴリ: 標準化過程INRIA K.ElMalki Athonet L.Bellier INRIA2008年10月
Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
階層的なモバイルIPv6(HMIPv6)移動性管理
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
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のための階層的な移動性管理は、モバイルノードと、通信員ノードと、そのホームのエージェントの間で合図する量を減少させるように設計されています。 また、引き渡し速度に関してモバイルIPv6の性能を向上させるのに本書では説明されたMobility Anchor Point(MAP)は使用できます。
Soliman, et al. Standards Track [Page 1] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[1ページ]RFC5380HMIPv6 October 2008
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operations ..........................................6
4. Mobile IPv6 Extension - Local Binding Update ....................9
5. Neighbour Discovery Extension: The MAP Option ...................9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................11
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................13
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................14
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................15
7.1. Mobile Node Operation .....................................15
8. Updating Previous MAPs .........................................16
9. Note on MAP Selection by the Mobile Node .......................16
9.1. MAP Selection in Distributed MAP Environment ..............17
9.2. MAP Selection in a Flat Mobility Architecture .............18
10. Detection and Recovery from MAP Failures ......................18
11. Tunelling Impacts on MTU ......................................19
12. Security Considerations .......................................19
12.1. Mobile Node - MAP Security ...............................20
12.2. Mobile Node - Correspondent Node Security ................22
12.3. Mobile Node - Home Agent Security ........................22
13. IANA Considerations ...........................................22
14. Acknowledgements ..............................................22
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
Appendix A. Changes from RFC 4140 .................................24
1. 序論…3 2. 用語…4 3. HMIPv6の概要…5 3.1. HMIPv6操作…6 4. モバイルIPv6拡張子--局所束縛アップデート…9 5. 発見拡大に近くに住んでください: 地図オプション…9 6. 操作について議定書の中で述べてください…10 6.1. モバイルノード手術…11 6.1.1. 通信員ノードにパケットを送ります…12 6.2. 操作を写像してください…13 6.3. ホームエージェント操作…13 6.4. 通信員ノード手術…13 6.5. 地図ドメインの中の地方の移動性管理最適化…14 6.6. 位置のプライバシー…14 7. 発見を写像してください…15 7.1. モバイルノード手術…15 8. 前の地図をアップデートします…16 9. モバイルノードは地図の上で選択に注意してください…16 9.1. 分散地図環境における選択を写像してください…17 9.2. 平坦な移動性アーキテクチャにおける選択を写像してください…18 10. 地図の故障からの検出と回復…18 11. TunellingにMTUで影響を与えます…19 12. セキュリティ問題…19 12.1. モバイルノード--セキュリティを写像してください…20 12.2. モバイルノード--通信員ノードセキュリティ…22 12.3. モバイルノード--ホームエージェントセキュリティ…22 13. IANA問題…22 14. 承認…22 15. 参照…23 15.1. 標準の参照…23 15.2. 有益な参照…23 付録A.はRFC4140から変化します…24
Soliman, et al. Standards Track [Page 2] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[2ページ]RFC5380HMIPv6 October 2008
1. Introduction
1. 序論
This specification introduces the concept of a hierarchical Mobile IPv6 network, utilising a new node called the Mobility Anchor Point (MAP).
この仕様は階層的なモバイルIPv6ネットワークの概念を紹介します、Mobility Anchor Point(MAP)と呼ばれる新しいノードを利用して。
Mobile IPv6 [RFC3775] allows nodes to move within the Internet topology while maintaining reachability and ongoing connections between mobile and correspondent nodes. To do this, a mobile node sends binding updates (BUs) to its home agent (HA) every time it moves.
モバイルと通信員ノードの間で可到達性と進行中の接続を維持している間、モバイルIPv6[RFC3775]はインターネットトポロジーの中でノードを移行させます。 これをするために、移行するときはいつも、モバイルノードは拘束力があるアップデート(BUs)をホームのエージェント(HA)に送ります。
The mobile node may send data packets via its home agent immediately after sending the binding update, but the home agent will not be able to route traffic back to the mobile node before it receives the binding update. This incurs at least half a round-trip delay before packets are again forwarded to the right place. There is an additional delay for sending data packets if the mobile node chooses to wait for a binding acknowledgement (BA). The round-trip times can be relatively long if the mobile node and its home agent are in different parts of the world.
モバイルノードは拘束力があるアップデートを送る直後ホームのエージェントを通してデータ・パケットを送るかもしれませんが、拘束力があるアップデートを受ける前にホームのエージェントはモバイルノードにトラフィックを発送であって戻しできないでしょう。 これは少なくともパケットの前の往復の遅れが再び送られる半分を適当な場所へ被ります。 モバイルノードが、拘束力がある承認(BA)を待つのを選ぶなら、送付データ・パケットのための追加遅れがあります。 モバイルノードとそのホームのエージェントが世界のいろいろな地方にいるなら、往復の回は比較的長い場合があります。
Additional delay is also incurred if the mobile node employs route optimisation. 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). This can be done in parallel with sending binding updates to the home agent, and there are further optimisations that reduce the required 1.5 round-trips [RFC4449] [RFC4651] [RFC4866].
また、モバイルノードがルート最適化を使うなら、追加遅れは被られます。 拘束力があるアップデートを認証するのはモバイルノードとそれぞれの通信員ノード(すなわち、最も良いケースシナリオ、パケット損失がないのにおける全体のリターンroutability手順のための)の間で往復のおよそ1.5回を必要とします。 拘束力があるアップデートをホームのエージェントに送ることと平行してこれができます、そして、さらに、必要な1.5の周遊旅行[RFC4449][RFC4651][RFC4866]を抑える最適化があります。
Nevertheless, the signalling exchanges required to update your location will always cause some disruption to active connections. Some packets will be lost. Together with link layer and IP layer connection setup delays, there may be effects to upper-layer protocols. Reducing these delays during the time-critical handover period will improve the performance of Mobile IPv6.
それにもかかわらず、交換があなたの位置をアップデートするのを必要とした合図はいつも活発な接続の何らかの分裂を引き起こすでしょう。 いくつかのパケットが失われるでしょう。 リンクレイヤとIP層の接続設定遅れと共に、上側の層のプロトコルへの効果があるかもしれません。 時間重要な引き渡しの期間、これらの遅れを減少させると、モバイル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がポイントで利益を得ることができる地元のアンカーは外部のネットワークと共に合図する移動性を減少させました。
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). The MAP will limit the amount of Mobile IPv6 signalling outside the local domain.
これらの理由で、Mobility Anchor Pointと呼ばれる新しいモバイルIPv6ノードは、使用されていて、ルータの階層的なネットワークでどんなレベルでも位置できます、Access Router(AR)を含んでいて。 MAPは局所領域の外で合図するモバイルIPv6の量を制限するでしょう。
Soliman, et al. Standards Track [Page 3] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[3ページ]RFC5380HMIPv6 October 2008
The introduction of the MAP provides a solution to the issues outlined earlier, in the following way:
MAPの導入は前、以下の方法で概説された問題に解決法を提供します:
o The mobile node sends binding updates to the local MAP rather than
the home agent (HA) (which is typically further away) and
correspondent nodes (CNs).
o モバイルノードはホームエージェント(HA)(通常さらに遠さにある)と通信員ノード(CNs)よりむしろ地方のMAPに拘束力があるアップデートを送ります。
o Only one binding update message needs to be transmitted by the
mobile node (MN) before traffic from the HA and all CNs is
re-routed to its new location. This is independent of the number
of CNs with which the MN is communicating.
o 1つの拘束力があるアップデートメッセージだけが、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. Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and home agents, while using Mobile IPv6 route optimisation. The security differences between the MAP and the home agent are described in Section 12.
MAPは本質的には地元のホームのエージェントです。 モバイルIPv6の階層的な移動性マネジメント・モデルを紹介する目的はモバイルIPv6か他のIPv6プロトコルで影響を最小とならせている間、モバイルIPv6の性能を高めることです。 その上、モバイルIPv6ルート最適化を使用している間、HMIPv6はモバイルノードに通信員ノードとホームのエージェントからそれらの位置を隠させます。 MAPとホームのエージェントのセキュリティ差はセクション12で説明されます。
It is pertinent to note that the use of the MAP does not rely on, or assume the presence of, a permanent home agent. In other words, a mobile node need not have a permanent home address or home agent in order to be HMIPv6-aware or use the features in this specification. A MAP may be used by a mobile node in a nomadic manner to achieve mobility management within a local domain. Section 6.5 describes such a scenario.
MAPの使用が永久的なホームのエージェントにを当てにもしませんし、存在を仮定もしないことに注意するのは適切です。 言い換えれば、モバイルノードは、永久的なホームアドレスかホームのエージェントがHMIPv6意識しているためにいる必要はありませんし、またこの仕様に基づく特徴を使用する必要はありません。 MAPは遊牧民的な方法によるモバイルノードによって使用されて、局所領域の中で移動性管理を達成するかもしれません。 セクション6.5はそのようなシナリオについて説明します。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
In addition, the following terms are introduced:
さらに、次の用語は紹介されます:
Access Router (AR)
アクセスルータ(アルゴン)
The AR is the mobile node's default router. The AR aggregates the
outbound traffic of mobile nodes.
ARはモバイルノードのデフォルトルータです。 ARはモバイルノードのアウトバウンドトラフィックに集めます。
Mobility Anchor Point (MAP)
移動性アンカー・ポイント(地図)
A Mobility Anchor Point is a router located 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.
Mobility Anchor Pointはモバイルノードによって訪問されたネットワークで位置するルータです。 MAPは地方のHAとしてミネソタによって使用されます。 1MAPsが訪問されたネットワークの中に存在できます。
Soliman, et al. Standards Track [Page 4] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[4ページ]RFC5380HMIPv6 October 2008
Regional Care-of Address (RCoA)
地方、注意、-、アドレス(RCoA)
An RCoA is an address allocated by the MAP to the mobile node.
RCoAはMAPによってモバイルノードに割り当てられたアドレスです。
HMIPv6-Aware Mobile Node
HMIPv6意識しているモバイルノード
An HMIPv6-aware mobile node is a mobile 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意識しているモバイルノードはデフォルトルータから受け取られたMAPオプションを受け取って、処理できるモバイルノードです。 また、HMIPv6意識しているモバイルノードは局所束縛アップデートを送ることができなければなりません(Mとのアップデートを縛って、旗はセットしました)。
On-Link Care-of Address
オンリンク、注意、-、アドレス
The LCoA is the on-link CoA configured on a mobile node's
interface based on the prefix advertised by its default router.
In [RFC3775], this is simply referred to as the care-of address.
However, in this memo LCoA is used to distinguish it from the
RCoA.
LCoAはデフォルトルータによって広告に掲載された接頭語に基づくモバイルノードのインタフェースで構成されたリンクのCoAです。 中[RFC3775]と、これが単に呼ばれる、注意、-、アドレス。 しかしながら、このメモでは、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.
ミネソタは、RCoAとLCoAの間の結合を確立するために局所束縛アップデートをMAPに送ります。
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 operations will not be affected.
この階層的なモバイル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 about 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 correspondent nodes it communicates with.
MAPドメインに入るモバイルノードは1時頃に情報を含むRouter Advertisementsか、より地方のMAPsを受けるでしょう。 ミネソタはMAPのサブネット(RCoA)に関するアドレスで現在の位置(リンクの上のCoA)を縛ることができます。 地方のHAとして機能して、MAPはそれが役立っていて、カプセル化するモバイルノードを代表してすべてのパケットを受けて、直接モバイルノードの現在のアドレスにそれらを送るでしょう。 モバイルノードが地方のMAPドメイン(LCoA)の中で現在のアドレスを変えるなら、それは、新しいアドレスをMAPに登録する必要があるだけです。 Regional CoA(RCoA)だけが、通信員ノードとHAに登録される必要があります。 ミネソタがMAPドメインの中で移行する(定義に関して以下を見てください)限り、RCoAは変化しません。 これはモバイルノードのものをそれがコミュニケートする通信員ノードに透明な移動性にします。
Soliman, et al. Standards Track [Page 5] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[5ページ]RFC5380HMIPv6 October 2008
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ドメインの境界は、添付のモバイルノードに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がミネソタ(例えば、同じサイト)の近くにあるかを決定するメソッドがあります。
3.1. HMIPv6 Operations
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(ことによると、同じドメインをカバーしている)を位置させるのは十分です。
Soliman, et al. Standards Track [Page 6] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[6ページ]RFC5380HMIPv6 October 2008
+-------+
| 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 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.
訪問されたネットワークへの到着のときに、モバイルノードはMAPのグローバルアドレスを発見するでしょう。 このアドレスは、Router Advertisements(RAs)を通してAccess Routersに保存されて、モバイルノードに伝えられます。 RAsのための新しいオプションは後でこの仕様に基づき定義されます。 これが、MAP(MAPディスカバリー)の存在に関するモバイルノードを知らせるのに必要です。 また、発見フェーズはモバイルノードからMAPの距離のモバイルノードを知らせるでしょう。 例えば、MAP機能は、図1に示されるように実装されて、また、同時に、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 Neighbour Discovery [RFC4861] and 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
モバイルノードが1つのサブネットから次まで移行するとき、MAPディスカバリーのプロセスは持続します。 毎回、モバイルノードは動きを検出します、また、それがまだ同じMAPドメインにあるかを検出するでしょう。 また、動きを検出するのに使用されるRouter Advertisementはモバイルノードを知らせるでしょう、Neighbourディスカバリー[RFC4861]とMAPオプションで、それがまだ同じMAPドメインにあるか否かに関係なく。 モバイルノードがMAPドメインの中を移動するのを同じように受けるのでそれが、続ける
Soliman, et al. Standards Track [Page 7] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[7ページ]RFC5380HMIPv6 October 2008
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.
Router AdvertisementsにARからMAPオプションを含んでいます。 広告を出しているMAPのアドレスにおける変化が受け取られているなら、HAと通信員ノードに拘束力があるアップデートを送ることによって、モバイルノードは変化に影響しなければなりません。
If the mobile node is not HMIPv6-aware, then no MAP Discovery will be performed, resulting in the mobile node using the Mobile IPv6 [RFC3775] 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, which the mobile node acquires via RFC 4877 [RFC4877] Section 9 mechanisms when it first contacts a given MAP. 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[RFC3775]プロトコルを使用することでモバイルノードをもたらして。 他方では、モバイルノードがHMIPv6意識している、それ、SHOULDは、HMIPv6実装を使用するのを選びます。 そうだとすれば、モバイルノードは、最初に、そのホームアドレスとリンクアドレスの(LCoA)を含むBUをそれに送ることによってMAPとともに記名する必要があるでしょう。 BUで使用されるホームアドレスはRCoAです。(モバイルノードは最初に与えられたMAPに連絡するときのRFC4877[RFC4877]部9のメカニズムでそのRCoAを獲得します)。 異なった通信員のノードかHAsから受け取ると、MAP MUSTは、それらの最終的な目的地にパケットを送ることができるように拘束力があるキャッシュにおけるこの情報を保存します。
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 [RFC3775]) will give the mobile node the necessary information.
モバイルノードは、いつも何か容認されたパケットの元の送り主が、ルート最適化が必要であるかどうかと決心しているのを知る必要があるでしょう。 MAPがオリジナルのパケットのコンテンツを変更しないので、この情報はモバイルノードに利用可能になるでしょう。 容認されたパケット([RFC3775]で説明されるように)の正常処理はモバイルノードに必要事項を与えるでしょう。
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 Figure 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 [RFC3775]. 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を通してすべてのパケットを送るのを避けて、その結果、ネットワーク回線容量の、より効率的な用法をもたらすでしょう。 また、モバイルノードは[RFC3775]で指定されるようにリンクアドレスのCoAとしての現在の(LCoA)を使用できます。 拘束力があるアップデートにおけるLCoAが別のMAPに発信したのでモバイルノードがMAPのサブネットからRCoAを寄贈してはいけないことに注意してください。 拘束力があるアップデートにLCoAを含むのは、リンクの上に広告に掲載された接頭語から得られたモバイルノードのアドレスであるに違いありません。
Soliman, et al. Standards Track [Page 8] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[8ページ]RFC5380HMIPv6 October 2008
4. Mobile IPv6 Extension - Local Binding Update
4. モバイルIPv6拡張子--局所束縛アップデート
This section outlines the extensions proposed to the binding update specified in [RFC3775].
このセクションは[RFC3775]で指定された拘束力があるアップデートに提案された拡大について概説します。
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| 予約されます。| 生涯| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Local Binding Update
図2: 局所束縛アップデート
M
M
If set to 1, it indicates a MAP registration.
1に設定されるなら、それはMAP登録を示します。
5. Neighbour Discovery Extension: The MAP Option
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アドレス| | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MAP option
図3: MAPオプション
Soliman, et al. Standards Track [Page 9] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[9ページ]RFC5380HMIPv6 October 2008
Type
タイプ
IPv6 Neighbour Discovery option. Its value is 23.
IPv6 Neighbourディスカバリーオプション。 値は23です。
Length
長さ
8-bit unsigned integer. The length of the option and MUST be set
to 3.
8ビットの符号のない整数。 長さ、3にゆだねて、設定していなければなりません。
Dist
Dist
A 4-bit unsigned integer identifying the distance between MAP and
the receiver of the advertisement, measure in the number of hops
and starting from 1 if the MAP is on the same link as the mobile
node. A distance value of zero MUST NOT be used.
広告のMAPと受信機の間の距離を特定する4ビットの符号のない整数にホップの数と同じリンクの上にMAPがあるならモバイルノードとして1から始める際に測定してください。 ゼロの距離値を使用してはいけません。
Pref
Pref
The preference field, used as an indicator of operator preference.
A 4-bit unsigned integer. A decimal value of 15 indicates the
highest preference. When comparing two potential MAPs, the mobile
node SHOULD inspect this field as a tie-breaker for MAPs that have
equal Dist values.
オペレータ好みのインディケータとして使用される選択領域。 4ビットの符号のない整数。 15のデシマル値は最も高い好みを示します。 2潜在的MAPsを比較するとき、モバイルノードSHOULDは等しいDist値を持っているMAPsのためのタイブレークとしてこの分野を点検します。
R
R
When set to 1, it indicates that the mobile node is allocated the
RCoA by the MAP based on Section 9 of [RFC4877].
1に設定されると、それは、RCoAが[RFC4877]のセクション9に基づくMAPによってモバイルノードに割り当てられるのを示します。
Valid Lifetime
有効な生涯
The minimum value (in seconds) of both the valid lifetime of the
prefix used to form the MAP's address and that used to form the
RCoA. This value indicates the validity of the MAP's address and
the RCoA.
MAPのアドレスを形成するのに使用される接頭語の有効な生涯、その両方の最小値(秒の)は以前はよくRCoAを形成していました。 この値はMAPのアドレスとRCoAの正当性を示します。
Global Address
グローバルアドレス
One of the MAP's global addresses.
MAPのグローバルなアドレスの1つ。
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オプションで受け取られたサブネット接頭語を結合することによって、状態がない方法で形成されます。
Soliman, et al. Standards Track [Page 10] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[10ページ]RFC5380HMIPv6 October 2008
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). After employing [RFC4877] to acquire an RCoA, 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 [RFC3775] 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 an HA) will then return a binding acknowledgement to the MN. This acknowledgement either identifies the binding as successful or contains the appropriate fault code. No new error codes need to be 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.
モバイルノードが新しいMAPドメイン(すなわち、MAP変化)に移行すると、2CoAsを構成するのが必要です: MAPのリンクの上のRCoAとリンクの上のCoA(LCoA)。 RCoAを獲得するのに[RFC4877]を使った後に、モバイルノードは旗が設定するAとMがあるMAPに地方のBUを送ります。 地方のBUは[RFC3775]で定義されたBUであり、ホームAddressオプションにモバイルノードのRCoAを含んでいます。 代替のCoAオプションは全くこのメッセージで必要ではありません。 LCoAはBUのソースアドレスとして使用されます。 このBUはモバイルノードのRCoA(ホームアドレスと同様の)をLCoAに縛るでしょう。 そして、MAP(HAとして、機能する)は拘束力がある承認をミネソタに返すでしょう。 この承認は、結合がうまくいっていると認識するか、または適切な欠点コードを含んでいます。 どんな新しいエラーコードも、この操作のためのモバイルノードによってサポートされる必要がありません。 モバイルノードは静かにルーティングヘッダータイプ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にトンネルを堀られます。 外側のヘッダーは、ソースアドレス・フィールドにモバイルノードのLCoAを保管していて、目的地アドレス・フィールドにMAPのアドレスを保管しています。 内側のヘッダーは、ソースアドレス・フィールドにモバイルノードの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 MAY 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
MAPとともに記名した後に、モバイルノードは結合(RCoA、ホームアドレス)を指定するBUを送ることによって、新しいRCoAをHAに登録しなければなりません、モバイルIPv6のように。 モバイルノードのホームアドレスがAddressがゆだねて、RCoAが使用されているホームで使用される、注意、-
Soliman, et al. Standards Track [Page 11] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[11ページ]RFC5380HMIPv6 October 2008
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.
ソースでアドレスが分野であると扱ってください。 また、モバイルノードは同様のBU(すなわち、それはホームアドレスとRCoAの間の結合を指定する)を現在の通信員ノードに送るかもしれません。
The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering the RCoA with other nodes (e.g., CN or HA, if available). 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.
他のノードにRCoAを登録する前にモバイルノードSHOULDがMAPから拘束力がある承認を待つ、(例えば、CNかHA、利用可能である、) HAと通信員ノードでRCoAを縛るとき、拘束力がある寿命が拘束力がある承認で受け取られる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までトンネルを堀られるでしょう。 正常な方法によるモバイルのノードの意志の反-カプセルになったパケットと加工処理したそれら。
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. If these nodes are connected to the 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 [RFC3775]. When communicating through the HA, the message formats in [RFC3775] are used.
モバイルノードはHAを通した、または、ルートで最適化された方法による通信員ノードとコミュニケートできます、[RFC3775]で説明されるように。 HAを通って交信するとき、[RFC3775]のメッセージ・フォーマットは使用されています。
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 [RFC3775], 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)における拘束力があるキャッシュエントリーを作成していました。 また、[RFC3775]に従って、モバイルノードは出発しているパケットにホームAddressオプションを含まなければなりません。 ホームAddressオプションはモバイルノードのホームアドレスを含まなければなりません。
Soliman, et al. Standards Track [Page 12] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[12ページ]RFC5380HMIPv6 October 2008
6.2. MAP Operations
6.2. 地図操作
The MAP acts like an 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 bind the RCoA (contained in the BU as a home address) to the mobile node's LCoA. 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 [RFC3775]. 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では、ホームアドレスとして含まれている)をモバイルノードのLCoAに縛ることです。 うまくいくなら、うまくいっている登録を示して、MAP MUSTは拘束力がある承認をモバイルノードに返します。 これは[RFC3775]での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 employs [RFC4877] Section 9 procedures for the allocation of RCoA, and subsequently acts as an 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 [RFC3775].
MAPはRCoAの配分に[RFC4877]セクション9手順を使って、次に、RCoAのためにHAとして機能します。 次に、RCoAに扱われたパケットは、モバイルノードのLCoAにプロキシNeighbour Advertisementを使用して、MAPによって妨害されて、カプセルに入れられて、発送されます。 この操作は[RFC3775]で説明されたHAのものと同じです。
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 that need to stop mobile nodes from continuing to use the MAP after moving to a different administrative domain. If a mobile
MAP MAY、リンクの上のモバイルノードがLCoAsを引き出すのに使用できる有効な接頭語のリストで、構成されてください。 これはモバイルノードが、異なった管理ドメインに移行した後にMAPを使用し続けているのを止める必要があるネットワーク・オペレータの役に立ちます。 モバイルです。
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の「リンクの上の有効な接頭語」リストにない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 [RFC3775].
HMIPv6のサポートはHAの操作に完全にわかりやすいです。 モバイルノードのホームアドレスに扱われたパケットはHAによってRCoAに送られるでしょう、[RFC3775]で説明されるように。
6.4. Correspondent Node Operations
6.4. 通信員ノード手術
HMIPv6 is completely transparent to correspondent nodes.
HMIPv6は通信員ノードに完全に透明です。
Soliman, et al. Standards Track [Page 13] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[13ページ]RFC5380HMIPv6 October 2008
6.5. Local Mobility Management Optimisation within a MAP Domain
6.5. 地図ドメインの中の地方の移動性管理最適化
In [RFC3775], 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.
[RFC3775]では短期的なコミュニケーション、特に失敗で容易に再試行されるかもしれないコミュニケーションのためにモバイルノードが、直接1つを使用するのを選ぶかもしれないと述べられている、それ、注意、-、パケットの源として扱っても、その結果、パケットにおけるホームAddressオプションの使用を必要としません。 CoAのそのような使用は追加オプションの欠如のため各パケットを送るオーバーヘッドを下げるでしょう。 さらに、それはモバイルノードと通信員ノードの間の最適のルートを提供するでしょう。
HMIPv6-aware mobile nodes can use their RCoA as the source address without using a Home Address option. In other words, the RCoA can be used as a 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.
ホームAddressオプションを使用しないで、HMIPv6意識しているモバイルノードはソースアドレスとしてそれらの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 with near-optimal routing. Although such use of RCoA does not provide global mobility (i.e., communication is broken when a mobile node changes its RCoA), 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 [RFC3775], this mechanism can provide a way of obtaining route optimisation without sending BUs to the correspondent nodes.
RCoAのこの使用法は、モバイルIPv6(すなわち、どんな結合もホームAddressオプションもインターネットの上に送らない)の費用を持っていませんが、近い最適ルーティングでローカルの移動性管理をまだモバイルノードに提供しています。 RCoAのそのような使用はグローバルな移動性を提供しませんが(モバイルノードがRCoAを変えるとき、すなわち、コミュニケーションは壊れています)、それはいくつかのアプリケーション(例えば、ウェブ閲覧)の役に立つでしょう。 アプリケーションで使用されるソースアドレスとしてのRCoAの正当性はMAPドメインのサイズとモバイルノードの速度に依存するでしょう。 その上、通信員ノードにおけるBU処理のサポートが[RFC3775]で強制されないので、このメカニズムは送付BUsなしでルート最適化を通信員ノードに得る方法を提供できます。
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 correspondent nodes and its home agent by using its RCoA in the source field of the packets that it sends. As a result, address-based location tracking of a mobile node by its correspondent nodes or its home agent is more difficult because they only know its RCoA and not its LCoA.
HMIPv6では、モバイルノードは、それが送るパケットのソースフィールドでRCoAを使用することによって、通信員ノードとそのホームのエージェントからLCoAを隠します。 その結果、彼らがLCoAではなく、そのRCoAを知っているだけであるので、通信員ノードかそのホームのエージェントによるモバイルノードのアドレスベースの位置追尾は、より難しいです。
Soliman, et al. Standards Track [Page 14] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[14ページ]RFC5380HMIPv6 October 2008
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.
このセクションは、モバイルノードがどのようにMAPアドレスとサブネット接頭語を得るか、そして、ドメインのARsがどのようにMAPsを発見するかを説明します。
This specification requires network administrators to manually configure the MAP option information in ARs; future mechanisms may be defined to allow MAPs to be discovered dynamically.
この仕様は、ネットワーク管理者が手動でARsのMAPオプション情報を構成するのを必要とします。 将来のメカニズムは、MAPsがダイナミックに発見されるのを許容するために定義されるかもしれません。
7.1. Mobile Node Operation
7.1. モバイルノード手術
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. 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.
HMIPv6意識しているモバイルノードがRouter Advertisementを受けるとき、それはMAPオプションを捜し求めるべきです。 1つ以上のオプションが異なったMAP IPアドレスに関して見つけられるかもしれません。 持っている中で好みの値最も高いMAPがあるモバイルノードSHOULDレジスタ。 SHOULD NOTがない好みの値が新しい地方のBUs(すなわち、モバイルノードは、既存の結合をリフレッシュできますが、新しいものを作成できない)に使用されているMAP。 しかしながら、モバイルノードは、別のものの上に1MAPとともに記名するのを選ぶかもしれなくて、値に依存するのは野原を遠くに受けました、ゼロより上に好みの値があれば。
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 NOT attempt to use HMIPv6.
ゼロの有効な生涯値を含むMAPオプションは、このMAP MUST NOTがミネソタによって選択されることを意味します。 ゼロの有効な寿命はMAPの故障を示します。 このオプションが受け取られているとき、モバイルノードは、別のMAPを選んで、新しい結合を作成しなければなりません。 このMAPとのどんな既存の結合も失われると思うことができます。 他のどんなMAPも利用可能でないなら、モバイルノードは、HMIPv6を使用するのを試みてはいけません。
If a multi-homed 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.
aである、マルチ、家へ帰り、モバイルノードは同時(異なったインタフェースで)に数個の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 the R flag is set, the mobile node MUST place its RCoA in place of the home address in the binding update message. This causes the RCoA to be bound to the LCoA in the MAP's binding cache.
R旗が設定されるなら、モバイルノードは拘束力があるアップデートメッセージのホームアドレスに代わってRCoAを置かなければなりません。 これで、MAPの拘束力があるキャッシュにLCoAにRCoAを向かわせます。
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の両方を使用する、モバイルノードが、選ぶかもしれない注意、-、同時に、異なった通信員ノードで扱います。
Soliman, et al. Standards Track [Page 15] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[15ページ]RFC5380HMIPv6 October 2008
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 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.
モバイルノードが新しいMAPドメインに移行すると、モバイルノードはモバイルノードの新しいCoAに扱われたパケットを進めるようそれに要求する前のMAPにBUを送るかもしれません。 管理者はMAPのドメインの外でMAPを推進パケットからLCoAsに制限するかもしれません。 しかしながら、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. Note 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オプションを含むRouter Advertisementを受けるとき、以下の動き検出メカニズムによると、それは動作を実行するべきです。本書では説明されたものなどの階層的なモバイルIPネットワークでは、モバイルノードは以下の通りであるべきです。
o "Eager" to perform new bindings.
o 新しい結合を実行することを「切望しています」。
o "Lazy" in releasing existing bindings.
o 既存の結合をリリースするのにおいて「怠惰です」。
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のそれが受け取ったことを知らせる短縮するのに従ってそれが新しい、注意、-、アドレス。
Soliman, et al. Standards Track [Page 16] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[16ページ]RFC5380HMIPv6 October 2008
9.1. MAP Selection in 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を最適に選択すると考える必要があります。
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.
数個のMAPsとのネットワークにおける距離ベースの選択で、モバイルノードは、頻繁な再登録証明書を避けるために最も遠いMAPとともに記名するのを選ぶかもしれません。 頻繁なhandoffsを実行する速いモバイルノードには、これは特に重要です。 このシナリオでは、より遠方のMAPの選択はMAP、すべての通信員ノードを知らせて、およびHAを変えなければならないという確率を減少させるでしょう。
In a scenario where several MAPs are discovered by the mobile node in one domain, the mobile node may need 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 use 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.
1. すべてのMAPオプションを受けて、分析してください。
2. Arrange MAPs in a descending order, starting with the furthest
MAP (i.e., MAP option having largest Dist field).
2. 最も遠いMAP(すなわち、持っている中でDist分野最も大きいMAPオプション)から始まって、降順でMAPsをアレンジしてください。
3. Select first MAP in list.
3. リストで最初のMAPを選択してください。
4. If either the preference value or the valid lifetime fields are
set to zero, select the following MAP in the list.
4. 好みの値か有効な生涯分野のどちらかがゼロに設定されるなら、リストで以下のMAPを選択してください。
Soliman, et al. Standards Track [Page 17] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[17ページ]RFC5380HMIPv6 October 2008
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.
5. 新しいMAPオプションがまだ存在している間、ステップ(4)を繰り返してください、MAPが非ゼロ好みの価値と非ゼロの有効な生涯で見つけられるまで。
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 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 movement is not frequent.
ネットワーク・オペレータはモバイルIPv6引き渡しがめったにない事件であると考えられるかもしれないいくつかの場合における平坦なアーキテクチャを選ぶかもしれません。 これらのシナリオでは、オペレータは、ARsだけにMAP機能を含んでいるのを選ぶかもしれません。 ARsでのMAP機能の包含は、すべての通信員ノードとHAをアップデートするのに必要である時間を短縮するためにまだ役に立っている場合があります。 移管を実行するとき、このシナリオでは、モバイルノードはアンカー・ポイントとしてMAP(ARの)を選ぶかもしれません。 この種類のダイナミックな階層構造(または、投錨)は相互AR運動が頻繁でないケースのために推薦されるだけです。
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 a form of context transfer protocol between them. However, MAP redundancy is outside the scope of this document.
この仕様は訪問されたネットワークで地元のホームのエージェントと考えることができるMAPを導入します。 ホームのエージェントのように、MAPは1ポイントの失敗です。 MAPが失敗すると、拘束力があるキャッシュ内容は失われるでしょう、モバイルと通信員ノードとのコミュニケーションの損失をもたらして。 この状況は、同じリンクの上に1MAPを使用して、それらの間で文脈転送プロトコルのフォームを利用することによって、避けられるかもしれません。 しかしながら、このドキュメントの範囲の外に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 then 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オプションを含むRouter Advertisementを受けるとき、モバイルノードはこの状況を検出できます。 そして、モバイルノードは別のMAPに登録するMAPディスカバリープロセスと試みを始めるはずです。 また、別のMAPを選択して、ともに記名した後に、それは、RCoAが変化したかどうかを通信員ノードとホームのエージェントに知らせる必要があるでしょう。 冗長目的のために拘束力があるキャッシュエントリーをMAPsの間に移すプロトコルがあるとき新しいMAPが同じRCoAをモバイルノードに提供できるかもしれないことに注意してください(例えば、両方のMAPsがMAPオプションにおける同じ接頭語の広告を出すなら)。 これは通信員ノードとホームのエージェントをアップデートするのからのモバイルノードを保存するでしょう。
Soliman, et al. Standards Track [Page 18] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[18ページ]RFC5380HMIPv6 October 2008
Access Routers can be triggered to advertise a MAP option with a lifetime of zero (indicating MAP failure) in different ways:
ゼロ(MAPの故障を示す)の生涯で異なった方法でMAPオプションの広告を出すためにアクセスRoutersを引き起こすことができます:
o By manual intervention.
o 手動の介入で。
o In a dynamic manner.
o ダイナミックな方法で。
One way of performing dynamic detection of MAP failure can be done by probing the MAP regularly (e.g., every 10 seconds). If no response is received, an AR MAY try to aggressively probe 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. The exact mechanisms for probing MAPs is outside the scope of this document. The above text simply shows one example of detecting failures.
定期的(例えばあらゆる10秒)にMAPを調べることによって、MAPの故障のダイナミックな検出を実行する1つの方法ができます。 どんな応答も受け取られていないなら、短期間の間に積極的にMAPを調べるためにAR MAY試みます(例えば、15秒間のかつての5秒毎)。 どんな回答も受け取られていないなら、ゼロの有効な生涯値と共にMAPオプションを送るかもしれません。 このドキュメントの範囲の外にMAPsを調べるための正確なメカニズムがあります。 上のテキストは単に検出失敗に関する1つの例を示しています。
This specification does not mandate a particular recovery mechanism. However, any 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の間では、通報認証、保全保護、および反射攻撃に対する保護を考慮するために安全であってください。
Note that the above suggestion for detecting MAP failure may not detect MAP failures that might take place between probes, i.e.,if a MAP reboots between probes.
MAPの故障を検出するための上の提案が徹底的調査の間の場所を取るかもしれないMAPの故障を検出しないかもしれないことに注意してください、すなわち、MAPが徹底的調査の間でリブートするなら。
11. Tunelling Impacts on MTU
11. MTUで影響をTunellingします。
This specification requires the mobile node to tunnel outgoing traffic to the MAP. Similarly, the MAP tunnels inbound packets to the mobile node. If the mobile node has a home agent elsewhere on the Internet, this will result in double encapsulations of inbound and outbound packets. This may have impacts on the mobile node's path MTU. Hence, mobile nodes MUST consider the encapsulation of traffic between the node and the MAP when calculating the available MTU for upper layers.
この仕様は、外向的なトラフィックにMAPにトンネルを堀るためにモバイルノードを必要とします。 同様に、MAPはモバイルノードに本国行きのパケットにトンネルを堀ります。 モバイルノードにホームのエージェントがインターネットのほかの場所にいると、これは本国行きの、そして、外国行きのパケットの二重カプセル化をもたらすでしょう。 これはモバイルノードの経路MTUに影響力を持っているかもしれません。 上側の層のための利用可能なMTUについて計算するとき、したがって、モバイルノードはノードとMAPの間のトラフィックのカプセル化を考えなければなりません。
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, such as when the mobile node is unwilling to reveal any traffic to the access network beyond what is needed for the mobile node to attach to the network and communicate with a MAP. Confidentiality is not required for binding updates to the MAP. The absence of any of these protections may lead to malicious mobile
この仕様はすなわち、モバイルIPv6、地元のホームのエージェントとして務めるMobility Anchor Pointに新しい概念を紹介します。 モバイルノードとMAPの間の安全保障関係が強いのは、重要です。 それは互いの認証、保全保護、および反射攻撃に対する保護にかかわらなければなりません。 秘密性がモバイルノードがいつなどかなどのペイロードトラフィックにモバイルノードがネットワークに付いて、MAPとコミュニケートするのに必要であるものを超えてアクセスネットワークにどんなトラフィックも明らかにするために不本意な状態で必要であるかもしれません。 秘密性は拘束力があるアップデートにMAPに必要ではありません。 これらの保護のどれかの不在は悪意があるモバイルにつながるかもしれません。
Soliman, et al. Standards Track [Page 19] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[19ページ]RFC5380HMIPv6 October 2008
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.
他の正統のものをまねるか、またはMAPをまねるノード。 これらの攻撃のいずれも確かにモバイルノードのRCoAに関する知識を持っているすべての通信員ノードとのモバイルノードのコミュニケーションに望ましくない影響を引き起こすでしょう。
Three different relationships (related to securing binding updates) need to be considered:
異なった関係(拘束力があるアップデートを保証すると関連される)が考えられる必要がある3:
1. The mobile node - MAP
1. モバイルノード--MAP
2. The mobile node - correspondent node
2. モバイルノード--通信員ノード
3. The mobile node - home agent
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 service can be done based on the identity of the mobile node exchanged during the security association (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 trusts 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). It is likely that some deployments would be satisfied with the use of self-signed certificates for either the mobile node or the MAP or both. This guarantees that the mobile node and the MAP are authenticated for address allocation and future binding updates without the need for identity authentication. Hence, the use of trusted third-party certificates is not required by this specification.
モバイルノードがMAPの推進サービスを利用するのを許容するために、初期の認可(特にRCoAではなく、サービスのための)が必要であるかもしれません。 セキュリティ協会(SA)交渉プロセスの間に交換されたモバイルノードのアイデンティティに基づいてモバイルノードがMAPサービスを利用するのを認可できます。 認可は、モバイルノードのアイデンティティに基づいて承諾されるか、またはMAPが信じるCertificate Authority(カリフォルニア)のアイデンティティに基づくかもしれません。 例えば、モバイルノードが信じられた実体(例えば、同じ管理ドメイン、または別の信じられたローミングパートナーのものであるカリフォルニア)によって署名される証明書を提示するなら、MAPがサービスの使用を認可するのは、十分でしょう。 このレベルの認可が特定のRCoAの使用を認可するのから独立していることに注意してください。 同様に、モバイルノードが信じるために構成される同じカリフォルニアか別のカリフォルニアによって署名された証明書(例えば、ローミングパートナー)を提示するなら、モバイルノードはMAPを信じます。 いくつかの展開が自己署名入りの証書のモバイルノードかMAPか両方のどちらかの使用に満たされそうでしょう。 これは、モバイルノードとMAPがアドレス配分と将来の拘束力があるアップデートのためにアイデンティティ認証の必要性なしで認証されるのを保証します。 したがって、信じられた第三者証明書の使用はこの仕様によって必要とされません。
It is important to note that in this specification, authentication and authorisation are effectively the same thing. All the MAP needs in order to allocate the mobile node an RCoA is to authenticate the mobile node and verify that it belongs to a trusted group (based on its certificate).
認証と認可がこの仕様では、事実上同じものであることに注意するのは重要です。 MAPがモバイルノードにRCoAを割り当てるために必要とするのは、モバイルノードを認証して、信じられたグループに属すことを確かめるだけである(証明書に基づいています)ことです。
IKEv2 MUST be supported by the mobile node and the MAP. IKEv2 allows the use of Extensible Authentication Protocol (EAP) as a mechanism to bootstrap the security association between the communicating peers.
モバイルノードとMAPはIKEv2を支えなければなりません。 IKEv2はメカニズムとしての拡張認証プロトコル(EAP)の使用に交信している同輩の間のセキュリティ協会を独力で進ませます。
Soliman, et al. Standards Track [Page 20] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[20ページ]RFC5380HMIPv6 October 2008
Hence, EAP can be used with IKEv2 to leverage the Authentication, Authorization, and Accounting (AAA) infrastructure to bootstrap the SA between the mobile node and the MAP. Such a mechanism is useful in scenarios where an administrator wishes to avoid the configuration and management of certificates on mobile nodes. A MAP MAY support the use of EAP over IKEv2.
したがって、モバイルノードとMAPの間のSAを独力で進むのにAuthentication、Authorization、およびAccounting(AAA)インフラストラクチャを利用するIKEv2と共にEAPを使用できます。 そのようなメカニズムは管理者がモバイルノードにおける証明書の構成と管理を避けたがっているシナリオで役に立ちます。 MAP MAYはIKEv2の上でEAPの使用をサポートします。
If EAP is used with IKEv2, the EAP method runs between the mobile node and a AAA server. Following a successful authentication, the resulting keying material can be used to bootstrap IKEv2 between the MAP and the mobile node. The specification of which EAP methods should be used or how keys are transported between the MAP and the AAA server is outside the scope of this document.
EAPがIKEv2と共に使用されるなら、EAPメソッドはモバイルノードとAAAサーバの間で稼働しています。うまくいっている認証に続いて、MAPとモバイルノードの間をIKEv2を独力で進むのに材料を合わせる結果になることは使用できます。 このドキュメントの範囲の外にどのEAPメソッドが使用されるべきであるか、そして、またはキーがMAPとAAAサーバの間でどのように輸送されるかに関する仕様があります。
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 and an LCoA and registers the binding between these two addresses with the new MAP. The MAP then verifies the BU and 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 its 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.
HMIPv6はモバイルノードとその現在のMAPの間の追加登録を使用します。 本書では説明されるように、モバイルノードが新しいドメイン(すなわち、新しいMAPが役立たれている)に移行すると、それは、RCoAとLCoAを入手して、これらの2つのアドレスの間の結合を新しいMAPに登録します。 MAPはRCoAとLCoAと共に次に、BUについて確かめて、拘束力があるキャッシュエントリーを作成します。 モバイルノードが新しいLCoAを手に入れるときはいつも、それは、RCoAとその新しいLCoAの間に結合を指定する新しいBUを送る必要があります。 このBUは、認証される必要があります。 さもなければ、どんなホストも、モバイルノードのRCoAのためにBUを送って、モバイルノードのパケットをハイジャックできました。
The MAP does not need to have prior knowledge of the identity of the mobile node or 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 IKEv2. A return routability test is not necessary.
MAPはモバイルノードのアイデンティティに関する知識かそのホームアドレスを優先的に必要としません。 その結果、IKEv2などのどんな主要な設立プロトコルも使用することでモバイルノードとMAPの間のSAを設立できます。 リターンroutabilityテストは必要ではありません。
The MAP needs to set the SA for the RCoA (not the LCoA). This can be performed with IKEv2 [RFC4306]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA.
MAPは、RCoA(LCoAでない)にSAを設定する必要があります。 IKEv2[RFC4306]と共にこれを実行できます。 モバイルノードは、ソースアドレスとしてLCoAを使用しますが、RCoAがSAで使用されるべきであると指定します。
This is achieved by using the RCoA as the identity in the IKE CHILD_SA negotiation. This step is identical to the use of the home address in IKE CHILD_SA when negotiating with the home agent.
これは、アイデンティティとしてIKE CHILD_SA交渉にRCoAを使用することによって、達成されます。 ホームのエージェントと交渉するとき、このステップはIKE CHILD_SAにおけるホームアドレスの使用と同じです。
The IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] for allocating dynamic home addresses SHOULD be used by the MAP to allocate the RCoA for mobile nodes. Binding updates between the MAP and the mobile node MUST be protected with either Authentication Header (AH) or Encapsulating Security Payload (ESP) in transport mode. When ESP is used, a non-null authentication algorithm MUST be used.
IPsec Peer Authorization Database(PAD)エントリーと構成ペイロードは、ダイナミックなホームアドレスSHOULDを割り当てるために中で[RFC4877]について説明しました。MAPによって使用されて、モバイルノードのためにRCoAを割り当ててください。 Authentication Header(AH)かEncapsulating Security有効搭載量(超能力)のどちらかで交通機関でMAPとモバイルノードの間の拘束力があるアップデートを保護しなければなりません。 超能力が使用されているとき、非ヌル認証アルゴリズムを使用しなければなりません。
Soliman, et al. Standards Track [Page 21] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[21ページ]RFC5380HMIPv6 October 2008
The Security Policy Database (SPD) entries in both the home agent and the mobile node are identical to those set up for the home agent and mobile node, respectively, as outlined in [RFC4877].
ホームのエージェントとモバイルノードの両方のSecurity Policy Database(SPD)エントリーは[RFC4877]に概説されているようにそれぞれホームのエージェントとモバイルノードに設定されたものと同じです。
12.2. Mobile Node - Correspondent Node Security
12.2. モバイルノード--通信員ノードセキュリティ
Mobile IPv6 [RFC3775] 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 [RFC3775]. 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 [RFC3775]. The source address used in HoTI messages SHOULD be the mobile node's home address unless the mobile node wishes to use the RCoA for route optimisation. 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[RFC3775]はモバイルと通信員ノードが拘束力があるアップデートと承認を認証できるリターンroutability手順を定義します。 この仕様は[RFC3775]で定義されたリターンroutabilityテストに影響を与えません。 しかしながら、[RFC3775]で定義されたHoTIとCoTIメッセージのソースアドレスを選択するとき、implementersが必要とするそのモバイルノードが慎重であることに注意するのは重要です。 ソースアドレスはHoTIでメッセージSHOULDを使用しました。モバイルノードがルート最適化にRCoAを使用したいと思わない場合、モバイルノードのホームアドレスになってください。 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 [RFC3775], is not impacted by this specification.
この仕様でモバイルノードとそのホームのエージェントの間の[RFC3775]で議論する安全保障関係は影響を与えられません。
The relationship between the MAP and the mobile node is not impacted by the presence of a home agent.
MAPとモバイルノードとの関係はホームのエージェントの存在によって影響を与えられません。
13. IANA Considerations
13. IANA問題
Both the MAP option and M flag were allocated for RFC 4140 and will continue to be used by this specification.
MAPオプションとMが旗を揚げさせる両方が、RFC4140のために割り当てられて、この仕様で使用され続けるでしょう。
14. Acknowledgements
14. 承認
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プロジェクトはフランスの政府によって部分的に資金を供給されます。
In addition, the authors would like to thank the following members of the working group, in alphabetical order: Samita Chakrabarti (Sun), Gregory Daley, Gopal Dommety (Cisco), Francis Dupont (GET/Enst Bretagne), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti
さらに、作者はアルファベット順にワーキンググループの以下のメンバーに感謝したがっています: Samita Chakrabarti(Sun)、グレゴリー・デイリー、ゴパルDommety(シスコ)、(GET/Enstブルターニュ)、フランシスデュポンエバGustaffson(エリクソン)デーブ・ジョンソン(ライス大学)、アニカイェンソン(エリクソン)ジェームス・ケンフ(Docomo研究室)、マルッティ
Soliman, et al. Standards Track [Page 22] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[22ページ]RFC5380HMIPv6 October 2008
Kuparinen (Ericsson), Fergal Ladley, Gabriel Montenegro (Microsoft), Nick "Sharkey" Moore, Vidya Narayanan (Qualcomm), Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (NEC), Thomas Schmidt, and Alper Yegin (Samsung) for their comments on the document.
ドキュメントの彼らのコメントのためのKuparinen(エリクソン)、Fergal Ladley、ガブリエル・モンテネグロ(マイクロソフト)、ニック・「シャーキー」ムーア、Vidyaナラヤナン(クアルコム)、エリックNordmark(Sun)、Basavarajパティル(ノキア)、ブレットPentland(NEC)、トーマス・シュミット、およびAlper Yegin(三星)。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April
2007.
[RFC4877]DevarapalliとV.とF.デュポン、「IKEv2と改訂されたIPsecアーキテクチャとのモバイルIPv6操作」、RFC4877、2007年4月。
15.2. Informative References
15.2. 有益な参照
[RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization
Using a Static Shared Key", RFC 4449, June 2006.
[RFC4449]パーキンス、C.、「モバイルIPv6が静的な共有されたキーを使用する経路最適化であると機密保護します」、RFC4449、2006年6月。
[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of
Enhancements to Mobile IPv6 Route Optimization", RFC 4651,
February 2007.
[RFC4651] フォークト、C.、およびJ.Arkko、「モバイルIPv6への増進の分類学と分析は最適化を発送します」、RFC4651、2007年2月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866] ArkkoとJ.とフォークト、C.とW.ハダド、「モバイルIPv6"、RFC4866、2007年5月のための高められた経路最適化。」
Soliman, et al. Standards Track [Page 23] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[23ページ]RFC5380HMIPv6 October 2008
Appendix A. Changes from RFC 4140
RFC4140からの付録A.変化
o Dynamic MAP Discovery was removed.
o ダイナミックなMAPディスカバリーを取り除きました。
o Updated the security section to use IKEv2 instead of IKEv1.
o IKEv1の代わりにIKEv2を使用するためにセキュリティ部をアップデートしました。
o The document clarified that HMIPv6 can be used without the need
for a home agent.
o ドキュメントははっきりさせられました。ホームのエージェントの必要性なしでHMIPv6は使用できます。
o Several editorials throughout the document.
o ドキュメント中のいくつかの社説。
o IKEv2 only is now used to allocate the RCoA.
o IKEv2だけが、現在、RCoAを割り当てるのに使用されます。
RFC 4140 was implemented and interop tested by at least two different organisations. A test suite including test cases for RFC 4140 was also developed by Ericsson and run against both implementations. No major issues were found. The scalability of Dynamic MAP Discovery, defined in RFC 4140, was seen as inappropriate for large-scale deployments and prone to loops. It was removed from this specification.
RFC4140は実装されました、そして、interopは少なくとも2つの異なった機構でテストされました。 RFC4140のためのテストケースを含むテストスイートは、また、エリクソンが開発されて、両方の実装に対して動かされました。 大変な問題は全く見つけられませんでした。 RFC4140で定義されたDynamic MAPディスカバリーのスケーラビリティは大規模な展開に不適当で輪の傾向があるとみなされました。 この仕様からそれを取り除きました。
At this time, there is no publicly known deployment of this specification.
このとき、この仕様の公的に知られている展開が全くありません。
Authors' Addresses
作者のアドレス
Hesham Soliman Elevate Technologies
Heshamソリマンは技術を上げます。
EMail: hesham@elevatemobile.com
メール: hesham@elevatemobile.com
Claude Castelluccia INRIA
クロードCastelluccia INRIA
Phone: +33 4 76 61 52 15 EMail: claude.castelluccia@inria.fr
以下に電話をしてください。 +33 4 76 61 52 15はメールされます: claude.castelluccia@inria.fr
Karim ElMalki Athonet
カリムElMalki Athonet
EMail: karim@elmalki.homeip.net
メール: karim@elmalki.homeip.net
Ludovic Bellier INRIA
ルードビックBellier INRIA
EMail: ludovic.bellier@inria.fr
メール: ludovic.bellier@inria.fr
Soliman, et al. Standards Track [Page 24] RFC 5380 HMIPv6 October 2008
ソリマン、他 標準化過程[24ページ]RFC5380HMIPv6 October 2008
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Soliman, et al. Standards Track [Page 25]
ソリマン、他 標準化過程[25ページ]
一覧
スポンサーリンク
