Internet Engineering Task Force (IETF) A. Makela
Request for Comments: 6521 Aalto University/Comnet
Category: Experimental J. Korhonen
ISSN: 2070-1721 Nokia Siemens Networks
February 2012
Home Agent-Assisted Route Optimization between Mobile IPv4 Networks
モバイルIPv4ネットワークとの間にホームエージェント支援ルート最適化
Abstract
抽象
This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes.
この文書では、IPv4ネットワークモビリティプロトコルのためのホームエージェント支援ルート最適化機能について説明します。関数は、すべてのノードが単一のホームエージェントに接続されている場合に最適なルーティングを容易にするように設計されています。従って、ユースケースは、単一の組織または類似のエンティティ内経路最適化です。機能は、対象のピア・ノードの発見（ホームエージェントから受信した情報に基づいて）およびそれらのネットワークプレフィックス、及びそのようなノード間のダイレクトトンネルの確立を可能にします。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6521.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6521で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction and Motivations ....................................3
2. Terms and Definitions ...........................................6
3. Mobile IPv4 Route Optimization between Mobile Networks ..........8
3.1. Maintaining Route Optimization Information .................9
3.1.1. Advertising Route-Optimizable Prefixes ..............9
3.1.2. Route Optimization Cache ...........................11
3.2. Return Routability Procedure ..............................13
3.2.1. Router Keys ........................................15
3.2.2. Nonces .............................................15
3.2.3. Updating Router Keys and Nonces ....................16
3.3. Mobile-Correspondent Router Operations ....................16
3.3.1. Triggering Route Optimization ......................17
3.3.2. Mobile Router Routing Tables .......................17
3.3.3. Inter-Mobile Router Registration ...................18
3.3.4. Inter-Mobile Router Tunnels ........................20
3.3.5. Constructing Route-Optimized Packets ...............21
3.3.6. Handovers and Mobile Routers Leaving Network .......21
3.4. Convergence and Synchronization Issues ....................22
4. Data Compression Schemes .......................................23
4.1. Prefix Compression ........................................23
4.2. Realm Compression .........................................25
4.2.1. Encoding of Compressed Realms ......................25
4.2.2. Searching Algorithm ................................27
4.2.3. Encoding Example ...................................27
5. New Mobile IPv4 Messages and Extensions ........................30
5.1. Mobile Router Route Optimization Capability Extension .....30
5.2. Route Optimization Reply ..................................31
5.3. Mobile-Correspondent Authentication Extension .............32
5.4. Care-of Address Extension .................................33
5.5. Route Optimization Prefix Advertisement Extension .........34
5.6. Home Test Init Message ....................................36
5.7. Care-of Test Init Message .................................36
5.8. Home Test Message .........................................37
5.9. Care-of Test Message ......................................38
6. Special Considerations .........................................39
6.1. NATs and Stateful Firewalls ...............................39
6.2. Handling of Concurrent Handovers ..........................40
6.3. Foreign Agents ............................................40
6.4. Multiple Home Agents ......................................40
6.5. Mutualness of Route Optimization ..........................41
6.6. Extensibility .............................................42
6.7. Load Balancing ............................................43
7. Scalability ....................................................43
8. Example Signaling Scenarios ....................................44
8.1. Registration Request ......................................44
8.2. Route Optimization with Return Routability ................45
8.3. Handovers .................................................46
9. Protocol Constants .............................................48
10. IANA Considerations ...........................................48
11. Security Considerations .......................................50
11.1. Return Routability .......................................50
11.2. Trust Relationships ......................................51
12. Acknowledgements ..............................................51
13. References ....................................................51
13.1. Normative References .....................................51
13.2. Informative References ...................................52
Traditionally, there has been no method for route optimization in Mobile IPv4 [RFC5944] apart from an early attempt [MIP-RO]. Unlike Mobile IPv6 [RFC6275], where route optimization has been included from the start, with Mobile IPv4, route optimization hasn't been addressed in a generalized scope.
伝統的に、初期の試み[MIP-RO]から離れてモバイルIPv4 [RFC5944]でのルート最適化のための方法がなかったです。ルート最適化はモバイルIPv4を用いて、最初から含まれているモバイルIPv6 [RFC6275]とは異なり、ルート最適化は、一般的な範囲で対処されていません。
Even though general route optimization may not be of interest in the scope of IPv4, there are still specific applications for route optimization in Mobile IPv4. This document proposes a method to optimize routes between networks behind Mobile Routers (MRs), as defined by Network Mobility (NEMO) [RFC5177]. Although NAT and the pending shortage of IPv4 addresses make widespread deployment of end-to-end route optimization infeasible, using route optimization from
一般的なルート最適化は、IPv4のスコープに興味がない場合でも、モバイルIPv4における経路最適化のための特定のアプリケーションが残っています。この文書は、ネットワークモビリティ（NEMO）[RFC5177]で定義されるようにモバイルルータ（MRS）の背後にあるネットワークとの間のルートを最適化する方法を提案しています。 NATとIPv4アドレスの保留不足から経路最適化を使用して、エンド・ツー・エンドの経路最適化の広範な展開が実行不可能にするが、
MR to MR is still a practical scenario. Note that the method specified in this document is only for route optimization between MRs; any network prefix not advertised by an MR would still be routed via the home agent, although an MR could advertise very large address spaces, e.g., by acting as an Internet gateway.
MRへのMRはまだ実用的なシナリオです。この文書で指定された方法は、MRの間のルート最適化のためだけであることに注意してください。 MRは、インターネットゲートウェイとして作用することにより、例えば、非常に大きなアドレス空間を宣伝ができるがMRによってアドバタイズされない任意のネットワークプレフィックスは、まだ、ホームエージェントを経由してルーティングされます。
A particular use case concerns setting up redundant yet economical enterprise networks. Recently, a trend has emerged where customers prefer to maintain connectivity via multiple service providers. Reasons include redundancy, reliability, and availability issues. These kinds of multihoming scenarios have traditionally been solved by using such technologies as multihoming BGP. However, a more lightweight and economical solution is desirable.
特定のユースケースは、冗長未だ経済的な企業ネットワークの設定に関する。顧客が複数のサービスプロバイダを経由して接続を維持することを好むところ最近、傾向が浮上しています。理由は、冗長性、信頼性、および可用性の問題を含んでいます。マルチホーミングシナリオのこれらの種類は、伝統的にマルチホーミングBGPなどの技術を使用することによって解決されています。しかし、より軽量かつ経済的なソリューションであることが望ましいです。
From a service provider perspective, a common topology for an enterprise customer network consists of one to several sites (typically headquarters and various branch offices). These sites are typically connected via various Layer 2 technologies (ATM or Frame Relay Permanent Virtual Circuits (PVCs)), MPLS VPNs, or Layer 3 site-to-site VPNs. With a Service Level Agreement (SLA), a customer can obtain very reliable and well-supported intranet connectivity. However, compared to the cost of "consumer-grade" broadband Internet access, the SLA-guaranteed version can be considered very expensive. These consumer-grade options, however, are not a reliable approach for mission-critical applications.
サービスプロバイダの観点から、企業顧客のネットワークのための一般的なトポロジは、いくつかのサイト（通常は本社とさまざまな支店）への1つから構成されています。これらのサイトは、通常、様々なレイヤ2つのテクノロジー（ATMやフレームリレーPVC）、MPLS VPNの、またはレイヤ3サイト間VPNを介して接続されています。サービスレベル契約（SLA）を使用すると、顧客は非常に信頼性の高い、よくサポートするイントラネット接続性を得ることができます。しかし、「消費者向けの」ブロードバンドインターネットアクセスのコストに比べて、SLA保証バージョンは非常に高価とみなすことができます。これらの消費者グレードのオプションは、しかし、ミッションクリティカルなアプリケーションのための信頼性の高いアプローチではありません。
Mobile IP, especially MRs, can be used to improve reliability of connectivity even when implemented over consumer-grade Internet access. The customer becomes a client for a virtual service provider, which does not take part in the actual access technology. The service provider has a backend system and an IP address pool that it distributes to customers. Access is provided by multiple, independent, possibly consumer-grade ISPs, with Mobile IP providing seamless handovers if service from a specific ISP fails. The drawback of this solution is that it creates a star topology; all Mobile IP tunnels end up at the service provider-hosted home agent, causing a heavy load at the backend. Route optimization between mobile networks addresses this issue, by taking the network load off of the home agent and the backend.
モバイルIP、特にMRは、消費者向けインターネット接続を介して実装しても、接続の信頼性を向上させるために使用することができます。顧客は、実際のアクセス技術に関与しない仮想サービスプロバイダ、クライアントになります。サービスプロバイダは、バックエンドシステムと、それが顧客に配布するIPアドレスプールを併設しています。アクセスは、特定のISPからのサービスに障害が発生した場合、モバイルIPは、シームレスハンドオーバを提供するとともに、複数の独立した、おそらく消費者グレードのISPによって提供されます。この解決策の欠点は、スター型トポロジを作成することです。すべてのモバイルIPトンネルは、バックエンドで大きな負荷を引き起こし、サービスプロバイダがホストするホームエージェントで終わります。モバイルネットワーク間のルート最適化は、ホームエージェントとバックエンドのオフネットワークの負荷を取ることによって、この問題を解決します。
An example network is pictured below:
例えば、ネットワークは下図されています。
+----------------------------+
| Virtual Operator Backend |
+------------+ +-----+
| Home Agent | | AAA |
+------------+---------+-----+
|
.--.
_(. `)
_( ISP `)_
( Peering `)
( ` . Point ) )
`--(_______)--'
____ / | \
/ | \
.--. .--. .--.
_( `. _( `. _( `.
( ISP A ) ( ISP B ) ( ISP C )
( ` . ) ) ( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-' `--(___.-'
| ______/ \ /
| / \ /
| / \ /
+----+ +----+
|MR A| |MR B|
+----+ +----+
| |
.--. .--.
_( `. _( `.
( Site A ) ( Site B )
( ` . ) ) ( ` . ) )
`--(___.-' `--(___.-'
Virtual Service Provider Architecture Using NEMOv4
NEMOv4を使用した仮想サービスプロバイダのアーキテクチャ
In this example case, the organization network consists of two sites that are connected via two ISPs for redundancy reasons. Mobile IP allows fast handovers without the problems of multihoming and BGP peering between each individual ISP and the organization. The traffic, however, takes a non-optimal route through the virtual operator backend.
この例の場合には、組織のネットワークは、冗長性の理由から、2つのISPを介して接続された2つの部位から構成されています。モバイルIPは、個々のISPと組織の間でマルチホーミングとBGPピアリングの問題もなく、高速ハンドオーバを可能にします。トラフィックは、しかし、仮想オペレータのバックエンドを通じて非最適な経路をとります。
Route optimization addresses this issue, allowing traffic between Sites A and B to flow directly through ISP B's network, or in case of a link failure, via the ISP peering point (such as the Metropolitan Area Ethernet (MAE), e.g., MAE-West). The backend will not suffer from heavy loads.
ルート最適化アドレスISP Bのネットワークを介して直接流れるようにサイトAとBの間のトラフィックを許可するこの問題、またはISPピアリングポイントを介して（例えば首都圏イーサネット（MAE）、MAE-西としてリンク障害の場合、 ）。バックエンドは重い負荷に苦しむことはありません。
The specification in this document is meant to be Experimental, with the primary design goal of keeping the load on the backend to a minimum. Additional design goals include extensibility to a more generalized scope, such as not requiring all MRs to be homed on the same home agent. Experiences are mostly sought regarding applicability to real-world operations, and protocol-specific issues such as signaling scalability, interworking with other Mobile IP extensions not specifically addressed in this document, and behavior of end-user applications over route-optimized paths.
この文書に記載されている仕様は最小限にバックエンドの負荷を維持する主要な設計目標で、実験的であることを意味します。追加の設計目標は、同じホームエージェントをホームとするすべてのMRを必要としないなど、より一般的な範囲に拡張性を、含まれています。経験は、主に、実世界の業務への適用について求め、そのようなスケーラビリティを信号伝達などのプロトコル固有の問題、その他のモバイルIPの拡張子を持つインターワーキングは、具体的には、この文書では扱われていない、とルート最適化パスオーバーエンドユーザーアプリケーションの動作をしています。
The aforementioned use case is the original application. Moving this specification to Standards Track should be considered after enough deployment experience has been gathered. Besides the aforementioned issues, additional elements that might require refinement based on real-world experiences are delivery of information on networks managed by peer MRs; conducting MR <-> MR authentication; reaction to, and recovery methods for, connectivity breakdowns and other break-before-make topology changes; keepalive timer intervals; formats of signaling extensions; behavior in NAT/firewalled environments; and the prefix and realm compression algorithms.
前述のユースケースは、元のアプリケーションです。標準化過程にこの仕様を移動することは十分に展開の経験が収集された後に検討すべきです。上記の問題のほかに、現実世界の経験をもとに洗練を必要とするかもしれない追加要素は、ピアのMRによって管理されるネットワーク上の情報の配信です。 ; - <> MR認証MRを行います、接続の故障やその他のブレーク・ビフォア・メークトポロジの変更のために反応、および回復方法。キープアライブタイマー間隔。拡張子のシグナリングフォーマット。 NAT /ファイアウォール環境での動作。そして、プレフィックスと領域の圧縮アルゴリズム。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Care-of Address (CoA)
気付けアドレス（CoA）
RFC 5944 [RFC5944] defines a care-of address as the termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it is away from home. The protocol can use two different types of CoA: a "foreign agent care-of address", which is an address of a foreign agent with which the mobile node is registered, and a "co-located care-of address", which is an externally obtained local address that the mobile node has associated with one of its own network interfaces. However, in the case of Network Mobility, foreign agents are not used, so no foreign CoAs are used either.
RFC 5944 [RFC5944]は、それがホームから離れている間、移動ノードに転送されたデータグラムのために、モバイルノードに向かってトンネルの終端点として気付アドレスを定義します。モバイルノードが登録されているフォーリンエージェントのアドレスである「アドレス外部エージェントの気付」、および「同一位置気付アドレス」である：プロトコルは、CoAを二つの異なるタイプを使用することができモバイルノードが自身のネットワークインターフェースのうちの1つに関連付けられた外部から取得したローカルアドレス。しかし、ネットワークモビリティの場合には、外国人のエージェントが使用されていないので、何も外国のCoAのいずれかに使用されていません。
Correspondent Router (CR)
コレスポンデントルータ（CR）
RFC 5944 [RFC5944] defines a correspondent node as a peer with which a mobile node is communicating. A CR is a peer MR that MAY also represent one or more entire networks.
RFC 5944 [RFC5944]は、移動ノードが通信しているピアとして通信相手ノードを定義します。 CRはまた、1つ以上のネットワーク全体を表すことができるピアMRです。
Home Address (HoA)
ホームアドレス（HoA）
RFC 5944 [RFC5944] defines a home address as an IP address that is assigned for an extended period of time to a mobile node. It remains unchanged regardless of where the node is attached to the Internet.
RFC 5944 [RFC5944]は、移動ノードに長期間割り当てられたIPアドレスとしてホームアドレスを定義します。それは関係なく、ノードがインターネットに接続されている場所の変更されません。
Home Agent (HA)
ホームエージェント（HA）
RFC 5944 [RFC5944] defines a home agent as a router on a mobile node's home network that tunnels datagrams for delivery to the mobile node when it is away from home and maintains current location information for the mobile node. For this application, the "home network" sees limited usage.
RFC 5944 [RFC5944]は、それがホームから離れている移動ノードの現在位置情報を保持するとき、移動ノードへの配信のためにデータグラムをトンネルモバイルノードのホームネットワーク上のルータとしてホームエージェントを定義します。このアプリケーションでは、「ホームネットワークは、」限定された使用方法を見ています。
Host Network Prefix
ネットワークプレフィックスをホスト
A host network prefix is a network prefix with a mask of /32, e.g., 192.0.2.254/32, consisting of a single host.
ホスト・ネットワーク・プレフィックスは、単一のホストからなる、例えば、192.0.2.254/32 / 32のマスクを持つネットワークプレフィックスです。
Mobility Binding
モビリティバインディング
RFC 5944 [RFC5944] defines Mobility Binding as the association of an HoA with a CoA, along with the lifetime remaining for that association.
RFC 5944 [RFC5944]は、その関連の残り寿命とともに、モビリティのCoAとHoAとの関連などの結合定義します。
Mobile Network Prefix
モバイルネットワークプレフィックス
RFC 5177 [RFC5177] defines a mobile network prefix as the network prefix of the subnet delegated to an MR as the mobile network.
RFC 5177 [RFC5177]は、モバイルネットワークとしてMRに委任サブネットのネットワークプレフィックスとしてモバイルネットワークプレフィックスを定義します。
Mobile Router (MR)
モバイルルータ（MR）
RFC 5177 [RFC5177] and RFC 5944 [RFC5944] define a mobile router as a mobile node that can be a router that is responsible for the mobility of one or more entire networks moving together, perhaps on an airplane, a ship, a train, an automobile, a bicycle, or a kayak.
RFC 5177 [RFC5177]及びRFC 5944 [RFC5944]は、おそらく飛行機に、一緒に移動する一つ以上のネットワーク全体の移動性を担っているルータとすることができるモバイルノードとモバイルルータを定義する、船、列車、自動車、自転車、またはカヤックの。
Route Optimization Cache
ルート最適化キャッシュ
A Route Optimization Cache is defined as a data structure, maintained by MRs, containing possible destinations for route optimization. The cache contains information (HoAs) on potential CRs and their associated mobile networks.
ルート最適化キャッシュは、経路最適化のための可能な宛先を含むのMRによって維持されるデータ構造として定義されます。キャッシュは、潜在的なCRSおよびそれに関連するモバイルネットワーク上の情報（のHoA）が含まれています。
Return Routability (RR)
リターンルータビリティ（RR）
Return routability is defined as a procedure to bind an MR's HoA to a CoA on a CR with a degree of trust.
リターン・ルータビリティは、信頼の程度とCR上のCoAにMRのHoAをバインドするための手順として定義されます。
| (Concatenation)
| （連結）
Some formulas in this specification use the symbol "|" to indicate bytewise concatenation, as in A | B. This concatenation requires that all of the octets of the datum A appear first in the result, followed by all of the octets of the datum B.
「|」は、本明細書の一部の数式は、記号を使用しますAのように、バイト単位連結を示すために| B.この連結は、データムBのオクテットの全て続いて、基準Aのオクテットのすべてが結果に最初に表示されている必要が
First (size, input)
最初の（サイズ、入力）
Some formulas in this specification use a functional form "First (size, input)" to indicate truncation of the "input" data so that only the first "size" bits remain to be used.
最初の「サイズ」のビットは使用されずに残っているように、この明細書におけるいくつかの式は、機能的な形態「まず（サイズ、入力）」「入力」データの切り捨てを示すために使用します。
This section describes the changed functionality of the HA and the MR compared to the base NEMOv4 operation defined in [RFC5177]. The basic premise is still the same; MRs, when registering with the HA, may inform the HA of the mobile network prefixes they are managing (explicit mode), or the HA already knows the prefix assignments. However, instead of prefix <-> MR mapping information only remaining on the HA and the single MR, this information will now be distributed to the other MRs as well.
このセクションでは、HAの変更された機能と[RFC5177]で定義されたベースNEMOv4操作に比べMRが記載されています。基本的な前提は同じです。 MRは、HAに登録するとき、彼らは管理しているモバイルネットワークプレフィックスのHA（明示モード）を通知することができる、またはHAはすでにプレフィックスの割り当てを知っています。しかし、代わりに接頭辞の< - >のみHAと単一MR上に残ったMRマッピング情報、この情報は、現在、他のMRに配布されます。
Home agent-assisted route optimization is primarily intended for helping to optimize traffic patterns between multiple sites in a single organization or administrative domain; however, extranets can also be reached with optimized routes, as long as all MRs connect to the same HA. The procedure aims to maintain backward compatibility; with legacy nodes or routers, full connectivity is always preserved, even though optimal routing cannot be guaranteed.
ホームエージェント支援ルート最適化は、主に単一の組織または管理ドメインで複数のサイト間のトラフィックパターンを最適化することを支援するためのものです。ただし、エクストラネットもあれば、すべてのMRは、同一のHAに接続するように、最適化された経路で到達することができます。手順は、下位互換性を維持することを目指し、レガシーノードまたはルータと、完全な接続を常に最適なルーティングを保証できない場合でも、保存されています。
The scheme requires an MR to be able to receive messages from other MRs unsolicited -- that is, without first initiating a request. This behavior -- accepting unsolicited messages -- is similar to the registration revocation procedure [RFC3543]. Many of the mechanisms are the same, including the fact that advertising route optimization support upon registration implies the capability to receive Registration Requests and Return Routability messages from other MRs.
最初の要求を開始せずに、つまり - スキームが求められていない他のMRからのメッセージを受信することができるようにMRが必要です。この動作 - 迷惑メッセージを受け付けは - 登録取消手続き[RFC3543]に似ています。メカニズムの多くは、登録時の広告経路最適化のサポートは、他のMRからの登録要求とリターンルータビリティメッセージを受信する能力を意味しているという事実を含め、同じです。
Compared to IPv6, where mobile node <-> correspondent node bindings are maintained via Mobility Routing header and home address options, Mobile IPv4 always requires the use of tunnels. Therefore, inter-mobile-router tunnel establishment has to be conducted.
< - >モバイルノードのIPv6と比較すると、相手ノードのバインディングは、モビリティルーティングヘッダとホームアドレスオプションを介して維持され、モバイルIPv4は常にトンネルを使用する必要があります。したがって、インターモバイルルータトンネル確立が行われなければなりません。
During registration, a registering MR MAY request information on route-optimizable network prefixes. The MR MAY also allow redistribution of information on its managed network prefixes regardless of whether they are explicitly registered or already configured. These are indicated with a Mobile Router Route Optimization Capability Extension; see Section 5.1. If the HA accepts the request for route optimization, this is indicated with a Route Optimization Reply Extension (Section 5.2) in the Registration Reply.
登録時に、登録MRはルート最適化可能なネットワークプレフィックスに関する情報を要求することができます。 MRにもかかわらず、彼らは明示的に登録またはすでに設定されているかどうか、その管理するネットワークプレフィックス情報の再分配を可能にすることができます。これらは、モバイルルータルート最適化の機能拡張で示されています。セクション5.1を参照してください。 HAは、ルート最適化のための要求を受け入れた場合、これは、ルート最適化で示される登録応答に延長（5.2節）を返信します。
Note that the redistribution of network prefix information from the HA happens only during the registration signaling. There are no "routing updates" from the HA except during re-registrations triggered by handovers, registration timeouts, and specific solicitation. The solicitation re-registration MAY occur if a CR receives a Registration Request from an unknown MR (see Section 3.3.3).
HAからネットワークプレフィックス情報の再配布のみ登録シグナリング中に起こることに留意されたいです。ハンドオーバ、登録タイムアウト、および特定の勧誘によってトリガ再登録時以外HAからの「ルーティングアップデートは」ありません。 CRは、未知のMR（3.3.3項を参照）からの登録要求を受信した場合、再登録勧誘が発生することがあります。
As noted, an HA that supports NEMO already maintains information on which network prefixes are reachable behind specific MRs. The only change to this functionality is that this information can now be distributed to other MRs upon request. This request is implied by including a Route Optimization Capability Extension (Section 5.1) and setting the 'R' bit.
前述のように、NEMOをサポートHAは、既にネットワークプレフィックスは、特定のMRの背後に到達されている情報を保持します。この機能への唯一の変更は、この情報が現在要求に応じて他のMRに配布することができるということです。この要求は、ルート最適化機能拡張（セクション5.1）を含むと「R」ビットをセットすることによって暗示されています。
When an HA receives a Registration Request, standard authentication and authorization procedures are conducted.
HAは、登録要求を受信した場合、標準の認証と承認の手続きが行われています。
If registration is successful and the Route Optimization Capability Extension was present in the Registration Request, the reply message MUST include the Route Optimization Reply Extension (Section 5.2) to indicate that the Route Optimization Capability Extension was understood. Furthermore, the extension also informs the MR whether NAT was detected between the HA and the MR using the procedure in RFC 3519 [RFC3519], which is based on the discrepancy between the requester's indicated CoA and the packet's source address.
登録が成功するとルート最適化機能拡張が登録要求に存在していた場合、応答メッセージは、ルート最適化を含まなければなりませんルート最適化機能拡張が理解されたことを示すために、拡張（5.2節）を返信します。さらに、拡張はまた、RFC 3519の手順を使用してNATをHAとMRの間に検出されたかどうかをMRに通知要求者との間の相違に基づいている[RFC3519]は、-CoAおよびパケットの送信元アドレスを示します。
The reply message MAY also include one Route Optimization Prefix Advertisement Extension, which informs the MR of existing mobile network prefixes and the MRs that manage them, if eligible for redistribution. The networks SHOULD be included in order of priority, with the prefixes determined, by policy, as most desirable targets for route optimization listed first. The extension is constructed as shown in Section 5.5. The extension consists of a list where each MR, identified by its HoA, is listed with corresponding prefix(es) and their respective realm(s).
返信メッセージも再配布の対象とならば、既存のモバイルネットワークプレフィックスと、それらを管理するMRのMRを知らせる1ルート最適化プレフィックス広告拡張を含むことができます。ネットワークは、ルート最適化のための最も望ましい標的が最初にリストされるようプレフィックスは、ポリシーによって決定して、優先度の順に含まれるべきです。セクション5.5に示すように、拡張子が構築されます。拡張は、そのHoAとによって識別される各MRが、対応する接頭語（ES）と、それぞれの領域（S）と記載されているリストで構成されています。
Each network prefix can be associated with a realm [RFC4282], usually in the form 'organization.example.com'. Besides the routers in the customer's own organization, the prefix list may also include other MRs, e.g., a default prefix (0.0.0.0/0) pointing toward an Internet gateway for Internet connectivity or additional prefixes belonging to possible extranets. The realm information can be used to make policy decisions on the MR, such as preferring optimization within a specific realm only. Furthermore, the unique realm information can be used to differentiate between overlapping address spaces utilized by the same or different organizations concurrently and adjusting forwarding policies accordingly.
各ネットワークプレフィックスは「organization.example.com」通常の形で、領域[RFC4282]に関連付けることができます。お客様自身の組織内のルータのほかに、プレフィクスリストは、他のMRを含むことができ、例えば、インターネット接続または可能なエクストラネットに属している追加のプレフィックスのためのインターネットゲートウェイに向かって指しているデフォルトのプレフィックス（0.0.0.0/0）。レルム情報は、唯一の特定の領域内の最適化を好むように、MRの政策決定を行うために使用することができます。さらに、固有のレルム情報は、同一または異なる組織同時に、それに応じて転送ポリシーを調整することにより、利用重複アドレススペースを区別するために使用することができます。
In a typical scenario, where network prefixes are allocated to MRs connecting to a single HA, the prefixes are usually either continuous or at least very close to each other. Due to these characteristics, an optional prefix compression mechanism is provided. Another optional compression scheme is in use for realm information, where realms often share the same higher-level domains. These compression mechanisms are further explained in Section 4.
ネットワークプレフィックスは、単一のHAへの接続のMRに割り当てられている典型的なシナリオでは、プレフィクスは、通常、連続的又は互いに少なくとも非常に近いのいずれかです。これらの特性には、オプションのプレフィックス圧縮機構が設けられています。別の任意の圧縮方式は、レルムは、しばしば同じ上位ドメインを共有するレルムについては、使用されています。これらの圧縮機構は、さらに、第4章で説明されています。
Upon receiving a Registration Reply with a Route Optimization Prefix Advertisement Extension, the MR SHALL insert the MR HoAs included in the extension as host-prefixes to the local Route Optimization Cache if they do not already exist. If present, any additional prefix information SHALL also be inserted into the Route Optimization Cache.
ルート最適化プレフィックス広告拡張子の登録応答を受信すると、MRは、彼らがまだ存在しない場合はMRのHoAは、ローカルルート最適化のキャッシュにホストプレフィックスとして延長に含ま挿入しないものとします。存在する場合、追加のプレフィックス情報もルート最適化のキャッシュに挿入されるものとします。
The MR MAY discard entries from a desired starting point onward, due to memory or other policy-related constraints. The intention of listing the prefixes in order of priority is to provide implicit guidance for this decision. If the capacity of the device allows, the MR SHOULD use information on all advertised prefixes.
MRは、メモリまたは他のポリシー関連の制約に起因以降、所望の出発点からエントリを捨てるかもしれ。優先度の高い順に接頭辞をリストの意図は、この決定のための暗黙的なガイダンスを提供することです。デバイスの容量が許すならば、MRは、すべてのアドバタイズされたプレフィクスに関する情報を使用すべきです。
MRs supporting route optimization will maintain a Route Optimization Cache.
ルート最適化を支援するMRはルート最適化のキャッシュを維持します。
The Route Optimization Cache contains mappings between potential CR HoAs, network(s) associated with each HoA, information on reachability related to NAT and other divisions, and information related to the RR procedure. The cache is populated based on information received from the HA in Route Optimization Prefix Advertisement Extensions and in registration messages from CRs. Portions of the cache may also be configured statically.
ルート最適化キャッシュは、潜在的CRのHoAとの間のマッピングを含む、RR手順に関連するそれぞれのHoA、NATおよび他の部門に関連する到達可能性に関する情報、及び情報に関連するネットワーク（複数可）。キャッシュは、ルート最適化プレフィックス広告ExtensionsでとのCRからの登録メッセージでHAから受信した情報に基づいて移入されます。キャッシュの一部はまた、静的に構成することができます。
The Route Optimization Cache contains the following information for all known CRs. Note that some fields may contain multiple entries. For example, during handovers, there may be both old and new CoAs listed.
ルート最適化キャッシュは、すべての既知のCRについて以下の情報が含まれています。いくつかのフィールドは、複数のエントリを含んでいてもよいことに注意してください。例えば、ハンドオーバの際に、記載された新旧両方のCoAがあるかもしれません。
CR-HoA
CR-花
Correspondent router's home address. Primary key identifying each CR.
コレスポンデントルータのホーム・アドレス。各CRを識別する主キー。
CR-CoA(s)
CR-CoAを（S）
Correspondent router's care-of address(es). May be empty if none known. Potential tunnel's destination address(es).
コレスポンデントルータの気付アドレス（複数可）。何も知らない場合は、空のかもしれません。潜在的なトンネルの宛先アドレス（複数可）。
MR-CoA
MR-CoAを
Mobile router's care-of address currently used with this CR. Tunnel's source address.
モバイルルータの気付アドレスが、現在、このCRで使用します。トンネルの送信元アドレス。
Tunnels
トンネル
Tunnel interface(s) associated with this CR. The tunnel interface itself handles all the necessary operations to keep the tunnel operational, e.g., sending keepalive messages required by UDP encapsulation.
このCRに関連付けられたトンネルインターフェース（複数可）。トンネルインターフェース自体は、例えば、UDPカプセル化によって必要とされるキープアライブメッセージを送信し、動作トンネルを維持するために必要なすべての操作を処理します。
NAT states
NATの状態
A table of booleans. Contains entries for all pairs of potential MR-CoAs and CR-CoAs that are known to require NAT awareness. The table is populated either statically or based on information received during operation. A setting of true indicates that the MR can establish a UDP tunnel toward the CR, using this pair of CoAs. A received advertisement can indicate that the value should be set to false for all of the respective CR's CoAs. Settings in this table affect tunnel establishment direction; see Section 3.3.4 and the registration procedure when deciding which CoAs to include in the Care-of Address Extension in the Registration Reply. The existence of an entry mandates the use of UDP encapsulation.
ブール値のテーブル。 NAT意識を必要とすることが知られている可能性のあるMR-CoAをとCR-CoAを、すべてのペアのエントリが含まれています。テーブルは、静的または動作中に受信した情報に基づいてポピュレートされます。真の設定は、MRのCoAがこのペアを使用して、CRに向けてUDPトンネルを確立することができることを示しています。受信した広告は、値は、それぞれのCRのCoAをすべてfalseに設定する必要があることを示すことができます。このテーブルの設定は、トンネル確立の方向に影響を与えます。アシルCoAは、気付アドレス拡張登録応答中に含めるかを決めるとき、セクション3.3.4および登録手順を参照してください。エントリの存在は、UDPカプセル化の使用を義務付け。
RRSTATEs
RRSTATEs
Return routability state for each CR-HoA - MR-CoA pair. States are INACTIVE, IN PROGRESS, and ACTIVE. If state is INACTIVE, the RR procedure must be completed before forwarding route-optimized traffic. If state is IN PROGRESS or ACTIVE, the information concerning this CR MUST NOT be removed from the Route Optimization Cache as long as a tunnel to the CR is established.
MR-CoAのペア - 各CR-のHoAためルータビリティ状態を返します。国は、INACTIVE PROGRESS IN、およびACTIVEです。状態がアクティブでない場合、RR手順は、ルート最適化されたトラフィックを転送する前に完了しなければなりません。状態の進行またはアクティブである場合、このCRに関する情報があれば、CRへのトンネルが確立されるルート最適化キャッシュから削除してはいけません。
KRms
CCP
Registration management key for each CR-HoA - MR-CoA pair. This field is only used if configured statically -- if the KRm was computed using the RR procedure, it is calculated in situ based on nonces and the router key. If configured statically, RRSTATE is permanently set to ACTIVE.
MR-CoAのペア - 各CR-のHoAの登録管理キー。静的に設定されている場合、このフィールドは使用されている - KRMはRR手順を使用して計算された場合、それは一回だけとルータキーに基づいてその場で計算されます。静的に設定されている場合、RRSTATEは恒久的にACTIVEに設定されています。
Care-of nonce indices
気付けナンス指数
If the KRm was established with the RR procedure, contains the care-of nonce index for each MR-CoA - CR-HoA pair.
CR-HoAを対 - KRMはRR手順で確立された場合、気付けナンス指数各MR-CoAのために含まれています。
Care-of keygen token
気付生成トークン
If the KRm was established with the RR procedure, contains the care-of keygen token for each MR-CoA - CR-HoA pair.
CR-HoAを対 - KRMはRR手順で確立された場合は、気付キー生成トークン各MR-CoAのために含まれています。
Home nonce indices
ホームナンス指数
If the KRm was established with the RR procedure, contains the Home nonce index for each CR-HoA.
KRMはRR手順で確立された場合は、各CR-HoAをホームナンスのインデックスが含まれています。
Home keygen token
ホーム鍵生成トークン
If the KRm was established with the RR procedure, contains the home keygen token for each CR-HoA.
KRMはRR手順で確立された場合は、各CR-のHoAのホーム鍵生成トークンが含まれています。
Network prefixes
ネットワークプレフィックス
A list of destination network prefixes reachable via this CR. Includes network and prefix length, e.g., 192.0.2.0/25. Always contains at least a single entry: the CR-HoA host network prefix in the form of 192.0.2.1/32.
宛先ネットワークのリストは、このCRを介して到達可能プレフィックス。 192.0.2.0/25、例えば、ネットワークプレフィックス長が含まれています。 192.0.2.1/32の形でCR-HoAをホスト・ネットワーク・プレフィクス：常に少なくとも単一のエントリを含みます。
Realms
レルム
Each prefix may be associated with a realm. May also be empty, if the realm is not provided by advertisement or configuration.
各プレフィックスは、レルムに関連付けることができます。レルムは広告や設定によって提供されていない場合にも、空になることがあります。
Prefix_Valid
Prefix_Valid
Boolean field for each prefix - CR-HoA pair, which is set to true if this prefix's owner has been confirmed. The host network prefix consisting of the CR itself does not need validation beyond the RR procedure. For other prefixes, the confirmation is done by soliciting the information from the HA. Traffic for prefixes that have unconfirmed ownership should not be routed through the tunnel.
CR-HoAとのペア、このプレフィックスの所有者が確認されている場合はtrueに設定されている - 各プレフィックスのためのブールフィールド。 CR自体からなるホストネットワークプレフィックスは、RR手順を超えての検証を必要としません。他の接頭辞のために、確認はHAからの情報を募集することによって行われます。未確認の所有権を持っているプレフィックスのトラフィックがトンネルを経由してルーティングするべきではありません。
Information that is no longer valid due to expirations or topology changes MAY be removed from the Route Optimization Cache as desired by the MR.
MRが望むように起因する有効期限やトポロジの変更にはもはや有効ではない情報は、ルート最適化、キャッシュから除去することができます。
The purpose of the RR procedure is to establish CoA <-> HoA bindings in a trusted manner. The RR procedure for Mobile IPv6 is described in [RFC6275]. The same principles apply to the Mobile IPv4 version: two messages are sent to the CR's HoA -- one via the HA using the MR's HoA, and the other directly from the MR's CoA, with two responses coming through the same routes. The registration management key is derived from token information carried on these messages. This registration management key (KRm) can then be used to authenticate Registration Requests (comparable to Binding Updates in Mobile IPv6).
信頼できるようにしたHoAバインディング - <> RR手順の目的は、CoAを確立することです。モバイルIPv6のためのRR手順は、[RFC6275]に記載されています。同じ原理は、モバイルIPv4バージョンに適用される2つのメッセージは、CRのHoAに送信される - 2つの応答は、同じ経路を通って来ると、MRのCoAに直接MRのHoAを使用し、そして他のHAを介して。登録管理キーは、これらのメッセージに担持トークン情報から導出されます。この登録管理キー（KRM）は、その後、（モバイルIPv6のバインディングアップデートに匹敵する）登録要求を認証するために使用することができます。
The RR procedure is a method provided by Mobile IP to establish the KRm in a relatively lightweight fashion. If desired, the KRms can be configured on MRs statically, or by using a desired external secure key provisioning mechanism. If KRms are known to the MRs via some other mechanism, the RR procedure can be skipped. Such provisioning mechanisms are out of scope for this document.
RR手順は比較的軽量な方法でKRMを確立するために、モバイルIPによって提供される方法です。所望であれば、KRmsは静的のMRに設定さ、または所望の外部セキュア鍵プロビジョニング・メカニズムを使用してすることができます。 KRmsは、いくつかの他の機構を介してのMRにはよく知られている場合、RR手順をスキップすることができます。そのようなプロビジョニングメカニズムは、この文書の範囲外です。
The main assumption on traffic patterns is that the MR that initiates the RR procedure can always send outbound messages, even when behind a NAT or firewall. This basic assumption made for NAT Traversal in [RFC3519] is also applicable here. In the case where the CR is behind such obstacles, it receives these messages via the reverse tunnel to the CR's HoA; thus, any problem regarding the CR's connectivity is addressed during registration with the HA.
トラフィックパターンの主な仮定は、RR手順を開始MRは常に場合でも、NATやファイアウォールの背後に、アウトバウンドメッセージを送ることができるということです。 [RFC3519]でNATトラバーサルのために作られたこの基本的な前提は、ここにも適用可能です。 CRは、障害物の背後にある場合には、CRのHoAへの逆方向トンネルを介してこれらのメッセージを受信します。このように、CRの接続に関するすべての問題は、HAへの登録時にアドレス指定されます。
The RR procedure consists of four Mobile IP messages: Home Test Init (HoTI), Care-of Test Init (CoTI), Home Test (HoT), and Care-of Test (CoT). They are constructed as shown in Sections 5.6 through 5.9. If the MR has included the Mobile Router Route Optimization Capability Extension in its Registration Request, it MUST be able to accept Return Routability messages. The messages are delivered as Mobile IP signaling packets. The destination address of the HoTI and CoTI messages is set to the CR's HoA, with the sources being the MR's HoA and CoA, respectively.
ホーム試験開始（HoTIに）、気付テスト開始（CoTIの）、ホームテスト（ホット）、及び気付テスト（COT）：RR手順が4つのモバイルIPメッセージで構成されています。 5.9経由セクション5.6に示すように、彼らが構築されています。 MRは、その登録要求にモバイルルータのルート最適化機能の拡張が含まれている場合は、往復経路メッセージを受け入れることができなければなりません。メッセージは、モバイルIPシグナリングパケットとして配信されます。 HoTIメッセージ及びCoTIのメッセージの宛先アドレスは、ソースがそれぞれ、MRのHoAとCoA、ことと、CRのHoAに設定されています。
The RR procedure begins with the MR sending HoTI and CoTI messages, each containing a (different) 64-bit random value -- the cookie. The cookie is used to bind a specific signaling exchange together.
クッキー - RR手順は、HoTIメッセージ及びCoTIのメッセージ（異なる）64ビットのランダム値を含む、それぞれの送信MR始まります。クッキーは、一緒に、特定のシグナリング交換を結合するために使用されます。
Upon receiving the HoTI or CoTI message, the CR MUST have a secret correspondent router key (Kcr) and nonce. If it does not have this material yet, it MUST produce it before continuing with the RR procedure.
HoTI又はCoTIメッセージを受信すると、CRは、秘密のコレスポンデントルータの鍵（Kcrを）及びnonceを持たなければなりません。それはまだ、この材料を持っていない場合は、RR手順に進む前に、それを生成しなければなりません。
The CR responds to HoTI and CoTI messages by constructing HoT and CoT messages, respectively, as replies. The HoT message contains a home init cookie, current home nonce index, and home keygen token. The CoT message contains a care-of init cookie, current care-of nonce index, and care-of keygen token.
CRは、応答として、それぞれ高温及びCoTメッセージを構築したHoTIとのCoTIメッセージに応答します。 HoTメッセージは、ホーム開始クッキー、現在のホームナンス指数、およびホーム鍵生成トークンが含まれています。 CoTメッセージは、気付開始クッキー、現在の気付けナンス指数を含み、気付生成トークン。
The home keygen token is constructed as follows:
次のようにホーム鍵生成トークンが構築されます。
Home keygen token = First (64, HMAC_SHA1 (Kcr, (home address | nonce | 0)))
ホーム鍵生成トークン=最初の（64、HMAC_SHA1（Kcrを、（自宅住所|ナンス| 0）））
The care-of keygen token is constructed as follows:
次のように気付keygenのトークンが構築されます。
Care-of keygen token = First (64, HMAC_SHA1 (Kcr, (care-of address | nonce | 1)))
（1））| |ナンス64、HMAC_SHA1（Kcrを、（気付アドレス）生成トークン=最初のケア
Note that the CoA in this case is the source address of the received CoTI message packet. The address may have changed in transit due to network address translation. This does not affect the registration process; subsequent Registration Requests are expected to arrive from the same translated address.
この場合のCoAが受信CoTIメッセージパケットの送信元アドレスであることに留意されたいです。アドレスは、ネットワークアドレス変換のために輸送中に変更された可能性があります。これは、登録プロセスには影響を与えません。その後の登録要求は、同じ変換されたアドレスから到着すると予想されています。
The RR procedure SHOULD be initiated when the Route Optimization Cache's RRSTATE field for the desired CoA with the target CR is INACTIVE. If the state was INACTIVE, the state MUST be set to IN PROGRESS when the RR procedure is initiated. In the case of a handover occurring, the MR SHOULD only send a CoTI message to obtain a new care-of keygen token; the home keygen token may still be valid. If the reply to a registration indicates that one or both of the tokens have expired, the RRSTATE MUST be set to INACTIVE. The RR procedure may then be restarted as needed.
ターゲットCRを用いて所望のCoAのための経路最適化CacheのRRSTATEフィールドが非アクティブのときRR手順を開始すべきです。状態は不活性であった場合はRR手順が開始されると、状態は、IN PROGRESSに設定しなければなりません。発生したハンドオーバの場合には、MRは、新しい気付けキー生成トークンを取得するためにCoTIメッセージを送信すべきです。ホーム鍵生成トークンがまだ有効かもしれません。登録への返信は、トークンの一方または両方の期限が切れていることを示している場合、RRSTATEはINACTIVEに設定しなければなりません。必要に応じて、RR手順は、次に再起動することができます。
Upon completion of the RR procedure, the Route Optimization Cache's RRSTATE field is set to ACTIVE, allowing for Registration Requests to be sent. The MR will establish a KRm. By default, this will be done using the SHA1 hash algorithm, as follows:
RR手順が完了すると、ルート最適化キャッシュのRRSTATEフィールドが送信される登録要求を考慮して、ACTIVEに設定されています。 MRは、KRMを確立します。次のようにデフォルトでは、これは、SHA1ハッシュアルゴリズムを使用して行われます。
KRm = SHA1 (home keygen token | care-of keygen token)
KRM = SHA1（ホーム鍵生成トークン|気付生成トークン）
When de-registering (by setting the Registration Request's lifetime to zero), the care-of keygen token is not used. Instead, the KRm is generated as follows:
解除登録するとき（ゼロへの登録要求の有効期間を設定することにより）、気付keygenのトークンが使用されていません。その代わりに、次のようにKRMが生成されます。
KRm = SHA1 (home keygen token)
KRM = SHA1（ホーム鍵生成トークン）
As in Mobile IPv6, the CR does not maintain any state for the MR until after receiving a Registration Request.
モバイルIPv6のように、CRは、登録要求を受信した後まで、MRのためにどのような状態を維持しません。
Each MR maintains a Kcr, which MUST NOT be shared with any other entity. The Kcr is used for authenticating peer MRs in the situation where an MR is acting as a CR. This is analogous to the node key (Kcn) in Mobile IPv6. A CR uses its router key to verify that the keygen tokens sent by a peer MR in a Registration Request are the CR's own. The router key MUST be a random number, 16 octets in length, generated with a good random number generator [RFC4086].
各MRは、他のエンティティと共有してはならないKcrをし、維持します。 Kcrをは、MRがCRとして機能している状況で、ピアのMRを認証するために使用されます。これは、モバイルIPv6のノード鍵（Kcnを）に類似しています。 CRは、登録要求にピアMRによって送信さkeygenのトークンはCR自身であることを確認するために、そのルータのキーを使用しています。ルータキーは、良好な乱数発生器[RFC4086]を用いて生成された乱数、長さが16個のオクテットでなければなりません。
The MR MAY generate a new key at any time to avoid persistent key storage. If desired, it is RECOMMENDED that the keys be expired in conjunction with nonces; see Section 3.2.3.
MRは、永続的なキーストレージを避けるために、いつでも新しいキーを生成してもよいです。必要であれば、鍵がナンスと一緒に期限切れにすることをお勧めします。 3.2.3項を参照してください。
Each MR also maintains one or more indexed nonces. Nonces SHOULD be generated periodically with a good random number generator [RFC4086]. The MR may use the same nonces with all MRs. Nonces MAY be of any length, with the RECOMMENDED length being 64 bits.
各MRは、1つ以上のインデックス付きナンスを維持します。ナンスは、良好な乱数発生器[RFC4086]で周期的に生成されるべきです。 MRは、すべてのMRと同じナンスを使用することができます。ナンスが推奨長さが64ビットであることと、任意の長さのものであってもよいです。
The router keys and nonce updating guidelines are similar to those for Mobile IPv6. MRs keep both the current nonce and the small set of valid previous nonces whose lifetimes have not expired yet. A nonce should remain valid for at least MAX_TOKEN_LIFETIME seconds (see Section 9) after it has first been used in constructing an RR response. However, the CR MUST NOT accept nonces beyond MAX_NONCE_LIFETIME seconds (see Section 9) after the first use. As the difference between these two constants is 30 seconds, a convenient way to enforce the above lifetimes is to generate a new nonce every 30 seconds. The node can then continue to accept keygen tokens that have been based on the last 8 (MAX_NONCE_LIFETIME / 30) nonces. This results in keygen tokens being acceptable MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been sent to the mobile node, depending on whether the token was sent at the beginning or end of the first 30-second period. Note that the correspondent node may also attempt to generate new nonces on demand, or only if the old nonces have been used. This is possible as long as the correspondent node keeps track of how long ago the nonces were used for the first time and does not generate new nonces on every return routability request.
ルータキーとナンス更新ガイドラインは、モバイルIPv6のためのものと同様です。 MRは、現在のナンスと寿命がまだ期限が切れていない有効な前のナンスの小さなセットの両方を保持します。ナンスは、それが最初のRRレスポンスを構築するのに使用された後、少なくともMAX_TOKEN_LIFETIME秒（セクション9を参照）のために有効なままにしてください。しかし、CRは、最初の使用後（セクション9を参照）MAX_NONCE_LIFETIME秒を超えたナンスを受け入れてはいけません。これら2つの定数間の差は30秒であるため、上記の寿命を強制するための便利な方法は、新しいナンス30秒ごとに生成することです。ノードは、最後の8（MAX_NONCE_LIFETIME / 30）ナンスに基づいている鍵生成トークンを受け入れるように続けることができます。これは、トークンが最初の30秒期間の開始または終了時に送信されたかどうかに応じて、モバイルノードに送信された後秒MAX_NONCE_LIFETIMEに受け入れMAX_TOKEN_LIFETIMEあるkeygenのトークンになります。コレスポンデントノードはまた、必要に応じて新しいナンスを生成しようとすること、または古いナンスが使用されている場合にだけ注意してください。コレスポンデントノードが長いナンスが初めて使用されたどのくらい前のトラックを保持し、すべてのリターンルータビリティ要求に新しいナンスを生成しないと、これは可能です。
If the Kcr is being updated, the update SHOULD be done at the same time as the nonce is updated. This way, nonce indexes can be used to refer to both Kcrs and nonces.
Kcrをが更新されている場合は、更新はnonceが更新されると同時に行われるべきです。このように、一回だけのインデックスがKcrsとナンスの両方を参照するために使用することができます。
This section deals with the operation of mobile and correspondent routers performing route optimization. Note that in the context of this document, all routers work as both MR and CR. The term "mobile router" applies to the router initiating the route optimization procedure, and "correspondent router" indicates the peer router.
このセクションでは、経路最適化を行う移動し、対応ルータの動作を扱っています。本文書の文脈において、すべてのルータがMRとCRの両方として働くことに留意されたいです。用語「モバイルルータは、」ルート最適化手順を開始するルータに適用され、「コレスポンデントルータは、」ピアルータを示します。
There are two issues regarding IPv4 that are different when compared to Mobile IPv6 route optimization. First of all, since Mobile IPv4 always uses tunnels, there must be a tunnel established between the MR's and the CR's CoAs. The CR learns of the MR's CoA, because it is included in the Registration Request. The MR learns the CR's CoA via a new extension, "Care-of Address", in the Registration Reply. The second issue is a security consideration: In a Registration Request, the MR claims to represent an arbitrary IPv4 network. If the CR has not yet received this information (HoA <-> network prefix), it SHOULD perform a re-registration with the HA to verify the claim.
モバイルIPv6経路最適化と比較して異なっていたIPv4に関する2つの問題があります。モバイルIPv4は常にトンネルを使用するので、まず、MRのとCRの間のCoA確立されたトンネルが存在しなければなりません。それは登録要求に含まれているため、CRは、MRのCoAを知ります。 MRは、登録応答で新しい拡張子、「気付アドレス」、経由CRのCoAを学習します。第二の問題は、セキュリティ上の考慮事項である：登録要求に、MRは、任意のIPv4ネットワークを表すために主張しています。 CRは、まだこの情報（< - >のHoAネットワークプレフィックス）を受信していない場合は、請求を検証するためにHAとの再登録を実行する必要があります。
An additional aspect is that the MR MAY use a different CoA for different CRs (and the HA). This is useful in situations where the network provides only partial-mesh connectivity and specific interfaces must be used to reach specific destinations. In addition, this allows for load balancing.
さらなる態様は、MRが異なるのCR（およびHA）のための異なるCoAを使用できることです。これは、ネットワークが部分的にしかメッシュ接続性を提供し、特定のインターフェイスを特定の宛先に到達するために使用されなければならない状況で有用です。また、これは、ロードバランシングが可能になります。
Since each MR knows the eligible route-optimizable networks, the route optimization between all CRs can be established at any time; however, a better general practice is to conduct route optimization only on demand. It is RECOMMENDED that route optimization be started only when sending a packet that originates from a local managed network (and if the network is registered as route optimizable) and whose destination address falls within the network prefixes of the Route Optimization Cache. With a small number of MRs, such on-demand behavior may not be necessary, and full-mesh route optimization may be in place constantly.
各MRが適格ルート最適化可能なネットワークを知っているので、すべてのCR間の経路最適化はいつでも確立することができます。しかし、より良い一般的でのみオンデマンドで経路最適化を行うことです。ローカルの管理対象ネットワーク（およびネットワークは、経路最適化可能として登録されている場合）から発信パケットを送信する場合にのみ、ルート最適化を開始することを推奨し、宛先アドレスがルート最適化キャッシュのネットワークプレフィックスに収まっています。 MRの数が少ない、などのオンデマンド動作は必要ないかもしれない、とフルメッシュ経路最適化は常に場所にあってもよいです。
Each MR maintains a routing table. In a typical situation, the MR has one or more interface(s) to the local networks, one or more interface(s) to wide-area networks (such as those provided by ISPs), and a tunnel interface to the HA. Additional tunnel interfaces become activated as route optimization is being performed.
各MRは、ルーティングテーブルを維持します。典型的な状況では、MRは、1つ以上のローカルネットワーク（例えば、ISPが提供されるような）広域ネットワークへの1つまたは複数のインターフェース（複数可）へのインターフェース（複数可）、及びHAへのトンネルインタフェースを有します。経路最適化が行われているように、追加のトンネルインターフェイスがアクティブになります。
The routing table SHOULD typically contain network prefixes managed by CRs associated with established route-optimized tunnel interfaces. A default route MAY point to the reverse tunnel to the HA if not overridden by prefix information. The routing table MAY also include additional routes if required by the tunneling implementation.
ルーティングテーブルは、典型的には、確立されたルート最適化トンネルインターフェイスに関連付けられたCRが管理するネットワークプレフィックスを含むべきです。プレフィックス情報によってオーバーライドされない場合、デフォルトルートは、HAへのリバーストンネルを指すこと。トンネリングの実装によって必要とされる場合、ルーティングテーブルは、追加のルートを含むかもしれません。
The routes for the HoAs of any CRs SHOULD also be pointing toward their respective tunnels that are using the optimized path.
任意のCRのためのHoA経路も最適化されたパスを使用しているそれぞれのトンネルに向かって指しているべきです。
If two prefixes overlap each other, e.g., 192.0.2.128/25 and 192.0.2.128/29, the standard longest-match rule for routing is in effect. However, overlapping private addresses SHOULD be considered an error situation. Any aggregation for routes in private address space SHOULD be conducted only at the HA.
2つのプレフィックスが重なった場合、例えば、192.0.2.128/25と192.0.2.128/29、ルーティングのための標準的な最長一致ルールが有効です。ただし、重複プライベートアドレスは、エラー状況を考慮すべきです。プライベートアドレス空間内のルートのための任意の集計にのみHAで行うべきです。
If route optimization between an MR and a CR is desired, either the RR procedure must have been performed (see Section 3.2), or the KRm must be pre-shared between the MR and the CR. If either condition applies, an MR MAY send a Registration Request to the CR's HoA from the desired interface.
MRとCRとの間の経路最適化が望まれる場合、RR手順のいずれか（セクション3.2を参照）が行われていなければならない、またはKRMは、MRとCRとの間で事前に共有されなければなりません。どちらかの条件が適用された場合は、MRが必要なインターフェイスからCRのHoAに登録要求を送信することができます。
The Registration Request's Source Address and Care-of Address fields are set to the address of the desired outgoing interface on the MR. The address MAY be the same as the CoA used with the HA. The Home Agent field is set to the HA of the MR. The Registration Request MUST be sent to (have a destination address of) the HoA of the CR. The Registration Request MUST include a Mobile-Correspondent Authentication Extension (defined in Section 5.3) and SHOULD include a Mobile Network Request Extension (defined in [RFC5177]). If present, the Mobile Network Request Extension MUST contain the network prefixes, as if registering in explicit mode. If timestamps are used, the CR MUST check the Identification field for validity. The Authenticator field is hashed with the KRm.
登録要求の送信元アドレスと気付アドレスフィールドは、MR上の所望の発信インターフェイスのアドレスに設定されています。アドレスは、HAで使用するCoAのと同じであってもよいです。ホームエージェントフィールドは、MRのHAに設定されています。登録要求は、CRのHoAを（の宛先アドレスを持つ）に送信されなければなりません。登録要求には（セクション5.3で定義される）モバイル特派認証拡張を含まなければなりませんし、モバイルネットワーク要求拡張（[RFC5177]で定義される）を含むべきです。存在する場合は、モバイルネットワークの要求拡張が明示モードで登録するかのように、ネットワークプレフィックスを含まなければなりません。タイムスタンプが使用されている場合は、CRは、有効性の識別フィールドをチェックしなければなりません。認証フィールドはKRMでハッシュされます。
The CR replies to the request with a Registration Reply. The Registration Reply MUST include a Mobile-Correspondent Authentication Extension (defined in Section 5.3) and, if a Mobile Network Request Extension was present in the request, a Mobile Network Acknowledgement Extension.
CRは登録応答で要求に応答します。登録応答は、モバイルネットワークの要求拡張が要求、モバイルネットワーク謝辞拡張中に存在した場合、（セクション5.3で定義される）モバイル特派認証拡張を含むとしなければなりません。
The encapsulation can be set as desired, except in the case where the Route Optimization Cache Entry has NAT entries for the CR, or the MR itself is known to be behind a NAT or firewall. If either condition applies, the Registration Request MUST specify UDP encapsulation. It is RECOMMENDED that UDP encapsulation always be used to facilitate detection of path failures via a keepalive mechanism.
所望に応じてカプセル化がルート最適化キャッシュエントリは、CR用のNATエントリを有する、またはMR自体がNATまたはファイアウォールの背後にあることが知られている場合を除いて、設定することができます。どちらかの条件が適用された場合は、登録要求は、UDPカプセル化を指定しなければなりません。 UDPカプセル化は常にキープアライブメカニズムを介してパス障害の検出を容易にするために使用することをお勧めします。
The CR first checks the Registration Request's authentication against Kcr and nonce indexes negotiated during the RR procedure. This ensures that the Registration Request is coming from a valid MR. If the check fails, an appropriate Registration Reply code is sent (see Section 10). If the failure is due to the nonce index expiring, the MR sets RRSTATE for the CR to INACTIVE. The RR procedure MAY then be initiated again.
CRは、最初のRR手順の間に交渉Kcrをとナンス指標に対する登録要求の認証をチェックします。これは、登録要求が正当なMRから来ていることを保証します。チェックが失敗した場合は、適切な登録応答コードが送信されます（セクション10を参照）。障害が期限切れナンス指数によるものである場合、CRが非アクティブにするために、MRはRRSTATEを設定します。 RR手順が再び開始することができます。
If the check passes, the CR MUST then check its Route Optimization Cache to determine whether the MR exists and is associated with the prefixes included in the request (i.e., whether prefixes are present and the 'HA' flag is true for each prefix). Note that the viewpoint is always local; the CR compares CR-HoA entries against the MR's HoA -- from the CR's perspective, the MR is also a "correspondent router".
検査に合格した場合、CRがそのルート最適化キャッシュは、MRが存在し、要求に含まれるプレフィックスに関連付けられているかどうかを決定するためにチェックしなければならない（すなわち、プレフィックスが存在し、「HA」フラグは各プレフィックスに対して真であるかどうか）。視点は常にローカルであることに注意してください。 CRは、MRのHoAに対するCR-のHoAエントリを比較 - CRの観点から、MRも「コレスポンデントルータ」です。
If the check against the cache fails, the CR SHOULD send a re-Registration Request to the HA with the 'S' (solicitation) bit set, thus obtaining the latest information on network prefixes managed by the incoming MR. If, even after this update, the prefixes still don't match, the reply's Mobile Network Acknowledgement code MUST be set to "MOBNET_UNAUTHORIZED". The registration MAY also be rejected completely. This verification is done to protect against MRs claiming to represent arbitrary networks; however, since the HA is assumed to provide trusted information, it can authorize the MR's claim. If the environment itself is considered trusted, the CR can, as a policy, accept registrations without this check; however, this is NOT RECOMMENDED as a general practice.
キャッシュに対するチェックが失敗した場合、CRは、このように入ってくるMRが管理するネットワークプレフィックスの最新情報を取得、ビットセット「S」（勧誘）とHAへの再登録リクエストを送るべきです。でも、この更新した後、プレフィックスがまだ一致していない、場合は、回答者のモバイルネットワーク謝辞コードは「MOBNET_UNAUTHORIZED」に設定しなければなりません。登録も完全に拒否されることがあります。この検証は、任意のネットワークを表現するために主張しているのMRから保護するために行われます。 HAは、信頼できる情報を提供することを想定しているのでしかし、それはMRの主張を承認することができます。環境自体が信頼とみなされた場合、CRは、ポリシーとして、このチェックせずに登録を受け入れることができます。しかし、これは一般的なプラクティスとして推奨されていません。
If the prefixes match, the CR MAY accept the registration. If the CR chooses to accept, the CR MUST check to determine if a tunnel to the MR already exists. If the tunnel does NOT exist or has wrong endpoints (CoAs), a new tunnel MUST be established and the Route Optimization Cache updated. The reply MUST include a list of eligible CoAs (see Section 5.4) with which the MR may establish a tunnel. The reply MUST also include the Mobile-Correspondent Authentication Extension (see Section 5.3).
接頭辞が一致した場合、CRは、登録を受け入れることができます。 CRが受け入れることを選択した場合、CRは、MRへのトンネルがすでに存在するかどうかを判断するためにチェックしなければなりません。トンネルが存在しないか、間違ったエンドポイント（アシルCoA）を持っていない場合は、新しいトンネルを確立し、ルート最適化のキャッシュを更新する必要があります。応答が対象のCoAのリストを含まなければなりませんMRがトンネルを確立することができるれる（セクション5.4参照）。応答はまた、モバイル特派認証拡張（セクション5.3を参照）を含まなければなりません。
Upon receiving the Registration Reply, the MR MUST check to determine if a tunnel to the CR already exists. If the tunnel does NOT exist or has wrong endpoints (CoAs), a new tunnel MUST be established and the Route Optimization Cache updated. This is covered in detail in Section 3.3.4.
登録応答を受信すると、MRは、CRへのトンネルがすでに存在するかどうかを判断するためにチェックしなければなりません。トンネルが存在しないか、間違ったエンドポイント（アシルCoA）を持っていない場合は、新しいトンネルを確立し、ルート最適化のキャッシュを更新する必要があります。これは、セクション3.3.4で詳細に覆われています。
The CR's routing table MUST be updated to indicate that the MR's networks are reachable via the direct tunnel to the MR.
CRのルーティングテーブルは、MRのネットワークは、MRにダイレクトトンネルを介して到達可能であることを示すように更新されなければなりません。
After the tunnel is established, the MR MAY update its routing tables to reach all of the CR's Prefixes via the tunnel, although it is RECOMMENDED that time be given for the CR to perform its own, explicit registration. This is primarily a policy decision, depending on the network environment. See Section 6.5.
トンネルが確立された後、CRが独自の明示的な登録を実行するためにその時間を挙げることが推奨されるが、MRは、トンネルを介して、CRのプレフィックスのすべてに到達するためにそのルーティングテーブルを更新することができます。これは、ネットワーク環境に応じて、主に政策決定です。 6.5節を参照してください。
Due to the fact that the route optimization procedures may occur concurrently at both MRs, each working as each other's CR, there may be a situation where two routers are attempting to establish separate tunnels between them at the same time. If a router with a smaller HoA (meaning a normal 32-bit integer comparison treating IPv4 addresses as 32-bit unsigned integers) receives a Registration
ルート最適化手順は、両方のMRに同時に起こり得るという事実のために、それぞれが互いのCRとして働く2つのルータが同時にそれらの間の別個のトンネルを確立しようとしている状況があり得ます。小さいのHoA（32ビットの符号なし整数としてIPv4アドレスを処理する通常の32ビット整数の比較を意味する）を持つルータが登録を受信した場合
Request (in the CR role) while its own Registration Request (sent in the MR role) is pending, the attempt should be accepted with reply code "concurrent registration" (Value 2). If receiving such an indication, the recipient SHOULD consider the registration a success but only act on it once the peer has completed its own registration.
（MRの役割に送られた）独自の登録要求が保留されている間（CRロールの）要求は、試みは応答コード「同時登録」（値2）で受け入れられるべきです。そのような指示を受けた場合、受信者は、登録成功検討すべきであるが、ピアが自身の登録を完了した後にのみ、それに基づいて行動します。
Inter-MR tunnel establishment follows establishing standard reverse tunnels to the HA. The Registration Request to the CR includes information on the desired encapsulation. It is RECOMMENDED that UDP encapsulation be used. In the cases of Generic Router Encapsulation (GRE) [RFC2784], IP over IP [RFC2003], or minimal encapsulation [RFC2004], no special considerations regarding reachability are necessary. The tunnel has no stateful information; the packets are simply encapsulated within the GRE, IP, or minimal header.
インターMRトンネル確立は、HAに標準的な逆トンネルを確立以下。 CRに登録要求は、所望のカプセル化に関する情報を含みます。 UDPカプセル化を使用することをお勧めします。 IP [RFC2003]、または最小限のカプセル化[RFC2004]を超える汎用ルータカプセル化（GRE）[RFC2784]、IPの場合には、到達可能性に関する特別な考慮事項は必要ありません。トンネルにはステートフルな情報を有していません。パケットは単にGRE、IP、または最小限のヘッダ内にカプセル化されています。
The tunnel origination point for the CR is its CoA, not the HoA where the Registration Requests were sent. This is different from the creation of the reverse tunnel to the HA, which reuses the channel from registration signaling.
CR用トンネルの起点は、そのCoAを、ない登録要求が送信されたHoAです。これは、登録シグナリングからチャネルを再利用HAにリバーストンネルの作成と異なっています。
Special considerations rise from using UDP encapsulation, especially in cases where one of the MRs is located behind a NAT or firewall. A deviation from RFC 3519 [RFC3519] is that keepalives should be sent from both ends of the tunnel to detect path failures after the initial keepalive has been sent -- this allows both the MR and CR to detect path failures.
特別な考慮事項は、特にMRの1がNATまたはファイアウォールの背後に配置されている場合には、UDPカプセル化を使用してから上昇します。これはMRとCRの両方が、パス障害を検出することを可能にする - RFC 3519 [RFC3519]からの偏差は、キープアライブは、初期のキープアライブが送信された後のパスの障害を検出するために、トンネルの両端から送信されるべきであるということです。
The initial UDP keepalive SHOULD be sent by the MR. Only after the first keepalive is successfully completed SHOULD the tunnel be considered eligible for traffic. If a reply to the initial keepalive is not received, the MR may opt to attempt sending the keepalive to other CoAs provided by the Registration Reply to check whether they provide better connectivity; or, if all of these fail, the MR may perform a re-registration via an alternative interface, or deregister completely. See Section 6.1. Once the initial keepalive packet has reached the CR and a reply has been sent, the CR MAY start sending its own keepalives.
最初のUDPキープアライブは、MRで送ってください。最初のキープアライブが正常に完了した後でのみ、トンネルトラフィックの対象と見なされるべきです。最初のキープアライブへの応答が受信されない場合、MRは、彼らがより良い接続性を提供するかどうかを確認するために登録応答によって提供される他のCoAにキープアライブを送信しようとすることを選ぶこと。あるいは、これらのすべてが失敗した場合、MRは、別のインタフェースを介して再登録を実行し、または完全に登録解除することができます。 6.1節を参照してください。最初のキープアライブパケットがCRに達しているとの回答が送信されると、CRは独自のキープアライブの送信を開始することができます。
The original specification for UDP encapsulation suggests a keepalive interval default of 110 seconds. However, to provide fast response time and switching to alternate paths, it is RECOMMENDED, if power and other constraints allow, that considerably shorter periods be used, adapting to the perceived latency as needed. However, the maximum amount of keepalives SHOULD at no point exceed
UDPカプセル化のための元の仕様は、110秒のキープアライブ間隔のデフォルトを示唆しています。しかし、高速な応答時間を提供し、電力および他の制約が許す場合に代替パスに切り替え、必要に応じて知覚される待ち時間に適応し、そのかなり短い期間が使用され、推奨されています。しかし、キープアライブの最大量はない点に超えなければなりません
MAX_UPDATE_RATE times per second. The purpose of the keepalive is not to keep NAT or firewall mappings in place but to serve as a mechanism to provide fast response in case of path failures.
毎秒MAX_UPDATE_RATE回。キープアライブの目的は、所定の位置にNATやファイアウォールのマッピングを維持するが、パス障害の場合の迅速な応答を提供するためのメカニズムとして機能することはありません。
If both the MR and the CR are behind separate NATs, route optimization cannot be performed between them. Possible ways to set up mutual tunneling when both routers are behind NATs are outside the scope of this document. However, some of these issues are addressed in Section 6.1.
MRとCRの両方が別々のNATの背後にある場合、ルート最適化は、それらの間に行うことができません。両方のルータがNATの背後にあるとき、相互トンネリングを設定することも可能な方法は、この文書の範囲外です。しかし、これらの問題のいくつかは、セクション6.1で扱われています。
The designations "MR" and "CR" only apply to the initial tunnel establishment phase. Once a tunnel is established between two routers, either of them can opt to either tear down the tunnel or perform a handover. Signaling messages have to be authenticated with a valid KRm.
名称「MR」と「CR」とのみ初期トンネル確立フェーズに適用されます。トンネルは二つのルータの間で確立されると、それらのいずれかをすることを選ぶのいずれかのトンネルを切断又はハンドオーバを実行することができます。シグナリングメッセージは、有効なKRMで認証する必要があります。
All packets received by the MR are forwarded using normal routing rules according to the routing table. There are no special considerations when constructing the packets; the tunnel interface's own processes will encapsulate any packet automatically.
MRによって受信されたすべてのパケットは、ルーティングテーブルに従って通常のルーティングルールを使用して転送されます。パケットを構築する特別な考慮事項はありません。トンネルインターフェイスの独自のプロセスは、自動的にすべてのパケットをカプセル化します。
Handovers and connection breakdowns can be categorized as either ungraceful or graceful, also known as "break-before-make" (bbm) and "make-before-break" (mbb) situations.
ハンドオーバと接続故障無様や優雅いずれかに分類することができ、また、「ブレーク・ビフォア・メーク」として知られている（BBM）と「作る・ビフォア・ブレイク」（MBB）の状況。
As with establishment, the "mobile router" discussed here is the router wishing to change connectivity state, with the "correspondent router" being the peer.
設立と同じように、ここで説明する「モバイルルータは、」ピアが「コレスポンデントルータ」で、接続状態を変更したいルータです。
When an MR wishes to join its home link, it SHOULD, in addition to sending the Registration Request to the HA with lifetime set to zero, also send such a request to all known CRs, to their HoAs. The CR(s), upon accepting this request and sending the reply, will check whether the Route Optimization Cache contains any prefixes associated with the requesting MR. These entries should be removed and the routing table updated accordingly (traffic for the prefixes will be forwarded via the HA again). The tunnel MUST then be destroyed. A short grace period SHOULD be used to allow possible in-transit packets to be received correctly.
MRは、そのホームリンクへの参加を希望する場合、それは、ゼロに設定寿命とHAに登録要求を送信することに加えて、彼らののHoAに、すべての既知のCRに、このような要求を送信すべきです。 CR（S）は、この要求を受け入れ、応答を送信する際に、ルート最適化キャッシュは、要求MRに関連する任意のプレフィクスが含まれているかどうかチェックします。これらのエントリは削除されるべきであり、それに応じて更新されたルーティングテーブル（プレフィックスのトラフィックが再びHAを介して転送されます）。トンネルはその後破棄されなければなりません。短い猶予期間が可能で、トランジットパケットが正しく受信できるようにするために使用されるべきです。
In the case of a handover, the CR simply needs to update the tunnel's destination to the MR's new CoA. The MR SHOULD keep accepting packets from both old and new CoAs for a short grace period, typically on the order of ten seconds. In the case of UDP encapsulation, it is RECOMMENDED that the same port numbers be used for both registration signaling and tunneled traffic, if possible. The initial keepalive message sent by the MR will verify that direct connectivity exists between the MR and CR -- if the keepalive fails, the MR SHOULD attempt alternate paths.
ハンドオーバの場合、CRは、単にMRの新たなCoAにトンネルの宛先を更新する必要があります。 MRは、通常、10秒程度の短い猶予期間の間、新旧両方のCoAからのパケットを受け入れておく必要があります。 UDPカプセル化の場合には、可能であれば同じポート番号は、両方の登録シグナリングのために使用してトラフィックをトンネリングすることが推奨されます。 MRにより送信された最初のキープアライブメッセージは、直接接続がMRとCRとの間に存在することを確認します - キープアライブが失敗した場合、MRは、代替パスを試みるべきです。
If the MR was unable to send the re-Registration Request before handover, it MUST send it immediately after handover has been completed and a tunnel with the HA is established. Since the changing of CoA(s) invalidates the KRm, it is RECOMMENDED that partial return routability be conducted by sending a CoTI message via the new CoA and obtaining a new care-of keygen token. In all cases, necessary tokens also have to be acquired if the existing tokens have expired.
MRは、ハンドオーバ前に再登録要求を送信できませんでした場合は、ハンドオーバが完了したとHAとのトンネルが確立された後、それはすぐにそれを送らなければなりません。 CoAを（S）の変更は、KRMを無効化するので、部分的なリターン・ルータビリティは、新たなCoAを介して、CoTIメッセージを送信し、新しい気付キー生成トークンを取得することによって行われることが推奨されます。すべての場合において、必要なトークンはまた、既存のトークンが期限切れになった場合に取得する必要があります。
If a reply is not received for a Registration Request to a CR, any routes to the network prefixes managed by the CR MUST be removed from the routing table, thus causing the user traffic to be forwarded via the HA.
応答がCRに登録要求のために受信されない場合、CRが管理するネットワークプレフィックスへのルートは、このようにユーザトラフィックがHAを経由して転送させる、ルーティングテーブルから除去されなければなりません。
The information the HA maintains on mobile network prefixes and the MRs' Route Optimization Caches does not need to be explicitly synchronized. This is based on the assumption that at least some of the traffic between nodes inside mobile networks is always bidirectional. If using on-demand route optimization, this also implies that when a node in a mobile network talks to a node in another mobile network, if the initial packet does not trigger route optimization, the reply packet will.
情報HAは、モバイルネットワークプレフィックスに維持し、MRのルート最適化キャッシュは明示的に同期する必要はありません。これは、モバイルネットワーク内のノード間のトラフィックの少なくとも一部は、常に双方向であるという仮定に基づいています。オンデマンドの経路最適化を使用している場合、これはまた、その際に、最初のパケットは、ルート最適化を誘発しない場合、別のモバイルネットワーク内のノードへのモバイルネットワーク協議内のノードは、応答パケットがする。意味します
Consider a situation with three mobile networks, A, B, and C, handled by three mobile routers, MR A, MR B, and MR C, respectively. If they register with an HA in this order, the situation goes as follows:
3つのモバイルルータ、MR A、MR B、それぞれMR Cによって処理3つのモバイルネットワークで、A、B、およびCを有する状況を考えます。彼らがこの順でHAに登録する場合は、次のような状況が行きます：
MR A registers and receives no information on other networks from the HA, as no other MR has registered yet.
MR Aレジスタおよび他のMRがまだ登録していないように、HAから他のネットワークについての情報を受信しません。
MR B registers and receives information on mobile network A being reachable via MR A.
MR BレジスタとMR Aを介してモバイルネットワーク上の情報である到達を受信します
MR C registers and receives information on both of the other mobile networks.
MR Cレジスタ及び他のモバイルネットワークの両方に関する情報を受信します。
If a node in mobile network C is about to send traffic to mobile network A, the route optimization is straightforward; MR C already has network A in its Route Optimization Cache. Thus, packet transmission triggers route optimization toward MR A. When MR C registers with MR A (after the RR procedure is completed), MR A does not have information on mobile network C; thus, it will perform a re-registration with the HA on demand. This allows MR A to verify that MR C is indeed managing network C.
モバイルネットワークC内のノードは、モバイルネットワークAにトラフィックを送信しようとしている場合は、ルート最適化は簡単です。 MR Cは、すでにそのルート最適化、キャッシュ内のネットワークAを持っています。これにより、パケット伝送はMR Cは、MR A（RR手順が完了した後）に登録する場合、MR Aは、モバイルネットワークC上の情報を持っていないMRのA.向けてルート最適化をトリガします。したがって、それはオンデマンドでHAとの再登録を行います。これは、MR AはMR Cが実際にネットワークC.を管理していることを確認することができます
If a node in mobile network B sends traffic to mobile network C, MR B has no information on network C. No route optimization is triggered. However, when the node in network C replies and the reply reaches MR C, route optimization happens as above. Further examples of signaling are in Section 8.
モバイルネットワークB内のノードがモバイルネットワークCにトラフィックを送信する場合、MR Bは、Noルート最適化がトリガされていないネットワークCに情報を有していません。ネットワークC内のノードが応答し、応答がMR Cに達したときしかし、経路最適化は、上記のように起こります。シグナリングの更なる例は、セクション8にあります。
Even in the very rare case of completely unidirectional traffic from an entire network, re-registrations with the HA caused by timeouts will eventually cause convergence. However, this should be treated as a special case.
でも、ネットワーク全体から完全に単方向のトラフィックの非常にまれなケースでは、タイムアウトによって引き起こさHAによる再登録が最終的に収束の原因となります。しかし、これは特殊なケースとして扱われるべきです。
Note that all MRs are connected to the same HA. For possibilities concerning multiple HAs, see Section 6.4.
すべてのMRが同一のHAに接続されていることに注意してください。複数を持っている可能性については、項6.4を参照してください。
This section defines the two compression formats used in Route Optimization Prefix Advertisement Extensions.
このセクションでは、ルート最適化プレフィックス広告の拡張機能で使用される2つの圧縮フォーマットを定義します。
Prefix compression is based on the idea that prefixes usually share common properties. The scheme is simple delta compression. In the prefix information advertisement (Section 5.5), the 'D' bit indicates whether receiving a "master" or a "delta" prefix. This, combined with the Prefix Length information, allows for compression and decompression of prefix information.
プレフィックス圧縮は通常、共通の特性を共有する接頭辞という考えに基づいています。スキームは、単純なデルタ圧縮です。プレフィックス情報広告（5.5節）において、「D」ビットが「マスター」または「デルタ」接頭辞を受信するかどうかを示します。プレフィックス長情報と組み合わされ、これは、プレフィックス情報の圧縮および圧縮解除を可能にします。
If D = 0, what follows in the "Prefix" field are bits 1..n of the new master prefix, where n is PLen. This is rounded up to the nearest full octet. Thus, prefix lengths of /4 and /8 take 1 octet, /12 and /16 take 2 octets, /20 and /24 take 3 octets, and longer prefix lengths take a full 4 octets.
D = 0の場合、「プレフィックス」フィールドに以下の何ビットが、nがPLEN新しいマスタープレフィックスの1..nのです。これは、最も近いフルオクテットに切り上げられます。したがって、/ 4、および/ 8テイク1つのオクテットのプレフィックス長は、/ 12/16は2つのオクテット/ 20/24の3つのオクテットを取り、より長いプレフィックス長がフル4つのオクテットを取るを取ります。
If D = 1, what follows in the "Prefix" field are bits m..PLen of the prefix, where m is the first changed bit of the previous master prefix, with padding from the master prefix filling the field to a full octet. The maximum value of PLen - m is 8 (that is, the delta MUST fit into one octet). If this is not possible, a new master prefix has to be declared. If the prefixes are equal -- for example, in the case where the same prefix appears in multiple realms -- then one octet is still encoded, consisting completely of padding from the master prefix.
D = 1の場合、どのような「プレフィックス」フィールドに以下はm..PLen mが完全オクテットのフィールドを充填マスタープレフィックスからパディングと、前マスタプレフィックスの最初の変化ビットでプレフィックスのビットです。 PLENの最大値 - mで8（つまり、デルタは1つのオクテットに適合しなければなりません）。これが不可能な場合は、新しいマスター接頭辞を宣言する必要があります。プレフィックスが等しい場合 - 例えば、同じプレフィックスが複数の領域に表示される場合に、 - 次いで、1つのオクテットは、依然として完全にマスタープレフィックスからパディングからなる、符号化されます。
Determining the order of prefix transmission should be based on saving maximum space during transmission.
プレフィックス送信順序を決定することは、送信時の最大スペースを節約に基づくべきです。
An example of compression and transmitted data, where network prefixes 192.0.2.0/28, 192.0.2.64/26, and 192.0.2.128/25 are transmitted, is illustrated in Figure 1. Because of the padding to full octets, redundant information is also sent. The bit patterns being transmitted are as follows:
圧縮の例とは、ネットワークが192.0.2.0/28、192.0.2.64/26、及び192.0.2.128/25を送信、そのため完全なオクテットのパディングの図1に示されているされているプレフィックスデータを送信し、冗長な情報でもあります送信されました。次のように伝送されるビットパターンです。
=+= shows the prefix mask
--- shows the master prefix for delta coded prefixes
192.0.2.0/28, D = 0
0 1 2 3
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|0|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+
^ ^
+---------------------------- encoded ------------------------------+
^ ^
+-pad-+
192.0.2.64/26, D = 1
0 1 2 3
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 2
+-------------------------------------------------------------+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|0|1|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+
^ ^
+--- encoded ---+
^ ^
+-- padding --+
192.0.2.128/25, D = 1
0 1 2 3
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 2
+-------------------------------------------------------------+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|1|0|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+-+
^ ^
+--- encoded ---+
^ ^
+- padding -+
Figure 1: Prefix Compression Example
図1：プレフィックス圧縮の例
The first prefix, 192.0.2.0/28, is considered a master prefix and is transmitted in full. The PLen of 28 bits determines that all four octets must be transmitted. If the prefix would have been, e.g., 192.0.2.0/24, three octets would have sufficed, since 24 bits fit into 3 octets.
最初の接頭辞、192.0.2.0/28は、マスタ・プレフィックスと考えられ、完全に送信されます。 28ビットのPLENは、すべての4つのオクテットが送信されなければならないことを決定します。接頭辞があったであろう場合は24ビットは3つのオクテットにフィットするので、例えば、192.0.2.0/24、3オクテットは、足りているだろう。
For the following prefixes, D = 1. Thus, they are deltas of the previous prefix, where D was zero.
次のプレフィックスのために、D = 1は、したがって、それらはDがゼロであった前の接頭辞のデルタです。
192.0.2.64/26 includes bits 19-26 (full octet). Bits 19-25 are copied from the master prefix, but bit 26 is changed to 1. The final notation in binary is "1001", or 0x09.
192.0.2.64/26はビット19-26（フルオクテット）を含みます。ビット19-25は、マスタプレフィックスからコピーされたが、26は二進の最後の表記は「1001」、または0x09のある1に変更されるビットです。
192.0.2.128/25 includes bits 18-25 (full octet). Bits 18-24 are copied from the master prefix, but bit 25 is changed to 1. The final notation in binary is "101", or 0x05.
192.0.2.128/25はビット18-25（フルオクテット）を含みます。ビット18-24は、マスタプレフィックスからコピーされたが、25は二進の最後の表記は、「101」、または0x05のある1に変更されるビットです。
The final encoding thus becomes
最終的な符号化は、このようになります
+----------------+--------+-+---------------------+
| Prefix | PLen |D| Transmitted Prefix |
+----------------+--------+-+---------------------+
| 192.0.2.0/28 | 28 |0| 0xc0 0x00 0x02 0x00 |
| 192.0.2.64/26 | 26 |1| 0x09 |
| 192.0.2.128/25 | 25 |1| 0x05 |
+----------------+--------+-+---------------------+
It should be noted that in this case the order of prefix transmission would not affect compression efficiency. If prefix 192.0.2.128/25 would have been considered the master prefix and the others as deltas instead, the resulting encoding still fits into one octet for the subsequent prefixes. There would be no need to declare a new master prefix.
この場合には、接頭辞伝送の順序は圧縮効率に影響を与えないことに留意すべきです。代わりに、デルタとして接頭192.0.2.128/25がマスタープレフィックスと他人と見なされていた場合は、結果のエンコードはまだ、その後のプレフィックスの1つのオクテットに収まります。新しいマスタープレフィックスを宣言する必要はありません。
In order to reduce the size of messages, the system introduces a realm compression scheme, which reduces the size of realms in a message. The compression scheme is a simple dynamically updated dictionary-based algorithm, which is designed to compress text strings of arbitrary length. In this scheme, an entire realm, a single label, or a list of labels may be replaced with an index to a previous occurrence of the same string stored in the dictionary. The realm compression defined in this specification was inspired by the RFC 1035 [RFC1035] DNS domain name label compression scheme. Our algorithm is, however, improved to gain more compression.
メッセージのサイズを低減するために、システムは、メッセージ内のレルムのサイズを縮小レルム圧縮方式を導入します。圧縮方式は、任意の長さのテキスト文字列を圧縮するように設計されたシンプルな動的に更新辞書ベースのアルゴリズムです。この方式では、全体の領域、単一のラベル、又はラベルのリストは、辞書に格納されている同じ文字列の前の発生のインデックスに置き換えてもよいです。この仕様で定義されたレルムの圧縮は、RFC 1035 [RFC1035] DNSドメイン名ラベルの圧縮方式に触発されました。当社のアルゴリズムは、しかし、より多くの圧縮を得るために改善されています。
When compressing realms, the dictionary is first reset and does not contain a single string. The realms are processed one by one, so the algorithm does not expect to see them all or the whole message at once. The state of the compressor is the current content of the dictionary. The realms are compressed label by label or as a list of labels. The dictionary can hold a maximum of 128 strings; after that, a rollover MUST occur, and existing contents will be overwritten. Thus, when adding the 129th string into the dictionary, the first entry of the dictionary MUST be overwritten, and the index of the new string will become 0.
レルムを圧縮すると、辞書が最初にリセットされ、単一の文字列が含まれていません。レルムは1つずつ処理され、そのアルゴリズムは、一度に全部または全部のメッセージを見ることを期待していません。圧縮機の状態は、辞書の現在の内容です。レルムがラベルまたはラベルのリストとしてラベルを圧縮しています。辞書には、128個の文字列の最大値を保持することができます。その後、ロールオーバーが発生しなければならない、と既存の内容は上書きされます。辞書に129番目の文字列を追加するときにこのように、辞書の最初のエントリが上書きされなければならない、と新しい文字列のインデックスは0になります。
The encoding of an index to the dictionary or an uncompressed run of octets representing a single label has purposely been made simple, and the whole encoding works on an octet granularity. The encoding of an uncompressed label takes the form of one octet as follows:
辞書や単一ラベルを表すオクテットの非圧縮実行するために、インデックスのエンコードは、意図的にシンプルなされたものであり、全体のエンコードはオクテット粒度で動作します。次のように圧縮されていないラベルのエンコーディングは、1つのオクテットの形式をとります。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
|0| LENGTH | 'length' octets long string.. |
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
This encoding allows label lengths from 1 to 127 octets. A label length of zero (0) is not allowed. The "label length" tag octet is then followed by up to 127 octets of the actual encoded label string.
この符号化は、1〜127オクテットからラベル長を可能にします。ゼロ（0）のラベルの長さが許可されていません。 「ラベル長」タグオクテットは、実際の符号化されたラベル列の最大127個のオクテットが続きます。
The index to the dictionary (the "label index" tag octet) takes the form of one octet as follows:
次のように辞書（「ラベルインデックス」タグオクテット）へのインデックスは、1つのオクテットの形式をとります。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| INDEX |
+-+-+-+-+-+-+-+-+
The above encodings do not allow generating an output octet value of zero (0). The encapsulating Mobile IPv4 extension makes use of this property and uses the value of zero (0) to mark the end of the compressed realm or to indicate an empty realm. It is also possible to encode the complete realm using only "label length" tags. In this case, no compression takes place. This allows the sender to skip compression -- for example, to reduce computation requirements when generating messages. However, the receiver MUST always be prepared to receive compressed realms.
上記符号化は、ゼロ（0）の出力オクテット値を生成することができません。カプセル化モバイルIPv4拡張は、この性質を利用して圧縮領域の終わりをマークするか、空の領域を示すためにゼロ（0）の値を使用します。それだけで「ラベル長」タグを使用して完全な領域を符号化することも可能です。この場合、圧縮は行われません。これは、送信者が圧縮をスキップすることができます - たとえば、メッセージを生成する際の計算要件を軽減します。しかし、受信機は、常に圧縮されたレルムを受け取るために準備しなければなりません。
When compressing the input realm, the dictionary is searched for a matching string. If no match could be found, the last label is removed from the right-hand side of the used input realm. The search is repeated until the whole input realm has been processed. If no match was found at all, then the first label of the original input realm is encoded using the "label length" tag, and the label is inserted into the dictionary. The previously described search is repeated with the remaining part of the input realm, if any. If nothing remains, the realm encoding is complete.
入力領域を圧縮すると、辞書は一致文字列を検索します。一致が見つからなかった場合は、最後のラベルを使用し、入力領域の右側から削除されます。入力全体レルムが処理されるまで検索が繰り返されます。一致が全く見つからなかった場合、元の入力領域の最初のラベルは、「ラベル長」タグを使用して符号化され、ラベルが辞書内に挿入されます。前述の検索があれば、入力領域の残りの部分で繰り返されます。何も残っていない場合は、レルムエンコードは完了です。
When a matching string is found in the dictionary, the matching part of the input realm is encoded using the "label index" tag. The matching part of the input realm is removed, and the search is repeated with the remaining part of the input realm, if any. If nothing remains, the octet value of zero (0) is inserted to mark the end of the encoded realm.
一致する文字列が辞書に発見された場合、入力領域の整合部分は、「標識指数」タグを使用して符号化されます。入力領域のマッチング部分を除去して、もしあれば検索は、入力領域の残りの部分で繰り返されます。何も残っていない場合は、ゼロ（0）のオクテット値は、符号化された領域の終わりをマークするために挿入されています。
The search algorithm also maintains the "longest non-matching string" for each input realm. Each time the search in the dictionary fails and a new label gets encoded using the "label length" tag and inserted into the dictionary, the "longest non-matching string" is concatenated by this label, including the separating "." (dot, i.e., hexadecimal 0x2e). When a match is found in the dictionary, the "longest non-matching string" is reset (i.e., emptied). Once the whole input realm has been processed and encoded, all possible suffixes longer than one label are taken from the string and inserted into the dictionary.
検索アルゴリズムは、各入力レルムの「最長一致しない文字列」を維持しています。辞書内の検索が失敗し、新しいラベルは、「ラベル長」タグを使用してエンコードし、辞書に挿入されますたびに、「最長一致しない文字列は、」分離を含め、このラベルによって連結されます「」 （ドット、すなわち、進0x2e）。一致が辞書に発見された場合、「最長一致しない文字列が」（すなわち、空に）リセットされます。入力全体レルムが処理され、エンコードされた後、1つのラベルよりも長いすべての可能な接尾辞は、文字列から採取した辞書に挿入されています。
This section shows an example of how to encode a set of realms using the specified realm compression algorithm. For example, a message might need to compress the realms "foo.example.com", "bar.foo.example.com", "buz.foo.example.org", "example.com", and "bar.example.com.org". The following example shows the processing of input realms on the left-hand side and the contents of the dictionary on the right-hand side. The example uses hexadecimal representation of numbers.
このセクションでは、指定されたレルムの圧縮アルゴリズムを使用してレルムのセットをエンコードする方法の例を示しています。例えば、メッセージは、レルム「foo.example.com」を、「bar.foo.example.com」、「buz.foo.example.org」、「example.com」、および「bar.exampleを圧縮する必要がある場合があります.com.org」。次の例では、入力された左側のレルムと右側の辞書の内容の処理を示しています。例では、数字の16進表現を使用します。
COMPRESSOR: DICTIONARY:
COMPRESSOR：DICTIONARY：
1) Input "foo.example.com" Search("foo.example.com") Search("foo.example") Search("foo") Encode(0x03,'f','o','o') 0x00 "foo" +-> "longest non-matching string" = "foo" Search("example.com") Search("example") Encode(0x07,'e','x','a','m','p','l','e') 0x01 "example" +-> "longest non-matching string" = "foo.example" Search("com") Encode(0x03,'c','o','m') 0x02 "com" +-> "longest non-matching string" = "foo.example.com" 0x03 "foo.example.com" 0x04 "example.com" Encode(0x00)
1）入力 "foo.example.com" 検索（ "foo.example.com"）検索（ "foo.example"）検索（ "FOO"）をコード（0x03の、 'F'、 'O'、O ''） 0x00の "FOO" + - > "最長一致しない文字列" = "foo" という検索（ "example.com"）検索（ "例えば"）をコード（0x07の、 'E'、 'X'、 ''、 'M ' 'P'、 'L'、 'E'）が0x01 "例" + - > "最長一致しない文字列" = "foo.example" 検索（ "COM"）をコード（0x03の、 'C'、' O 」、 'M'）0×02 "COM" + - > "最長一致しない文字列" = "foo.example.com" 0×03 "foo.example.com" 0x04の "example.com" エンコード（0×00）
2) Input "bar.foo.example.com" Search("bar.foo.example.com") Search("bar.foo.example") Search("bar.foo") Search("bar") Encode(0x03,'b','a','r') 0x05 "bar" +-> "longest non-matching string" = "bar" Search("foo.example.com") -> match to 0x03 Encode(0x83) +-> "longest non-matching string" = NUL Encode(0x00)
2）入力 "bar.foo.example.com" 検索（ "bar.foo.example.com"）検索（ "bar.foo.example"）検索（ "bar.foo"）検索（ "バー"）エンコード（ 0x03の、 'B'、 ''、R ''）0x05の "バー" + - > "最長一致しない文字列" = "バー" 検索（ "foo.example.com"） - > 0x03のエンコード（0x83のにマッチ）+ - > "最長一致しない文字列" = NULエンコード（$ 00）
3) Input "buz.foo.example.org" Search("buz.foo.example.org") Search("buz.foo.example") Search("buz.foo") Search("buz") Encode(0x03,'b','u','z') 0x06 "buz" +-> "longest non-matching string" = "buz" Search("foo.example.org") Search("foo.example") Search("foo") -> match to 0x00 Encode(0x80) +-> "longest non-matching string" = NUL Search("example.org") Search("example") -> match to 0x01 Encode(0x81) +-> "longest non-matching string" = NUL Search("org") Encode(0x03,'o','r','g') 0x07 "org" +-> "longest non-matching string" = "org" Encode(0x00)
3）入力 "buz.foo.example.org" 検索（ "buz.foo.example.org"）検索（ "buz.foo.example"）検索（ "buz.foo"）検索（ "つぶやく"）エンコード（ 0x03の、 'B'、 'U'、 'Z'）0x06で "つぶやく" + - > "最長一致しない文字列" = "つぶやく" 検索（ "foo.example.org"）検索（ "foo.example"）検索（ "FOO"） - > 0x00にエンコード（0x80の）に一致+ - > "最長一致しない文字列" = NUL検索（ "example.org"）検索（ "例えば"） - >試合に0x01のエンコード（0x81と） + - > "最長一致しない文字列" = NUL検索（ "ORG"）をコード（0x03の、 'O'、 'R'、 'G'）0x07の "ORG" + - > "最長一致しない文字列" = " ORG」エンコード（$ 00）
4) Input "example.com" Search("example.com") -> match to 0x04 Encode(0x84) Encode(0x00)
4）入力 "example.com" を検索する（ "example.com"） - >試合に0x04をエンコード（0x84の）エンコード（$ 00）
5) Input "bar.example.com.org" Search("bar.example.com.org") Search("bar.example.com") Search("bar.example") Search("bar") -> match to 0x05 Encode(0x85) Search("example.com.org") Search("example.com") -> match to 0x04 Encode(0x84) Search("org") -> match to 0x07 Encode(0x87) Encode(0x00)
5）入力 "bar.example.com.org" 検索（ "bar.example.com.org"）検索（ "bar.example.com"）検索（ "bar.example"）を検索する（ "バー"） - > 0x05のエンコード（0x85）検索（ "example.com.org"）検索（ "example.com"）に一致 - > 0x04をエンコード（0x84の）検索（ "ORG"）に一致 - >試合に0x07のエンコード（0x87の）エンコード（$ 00）
As can be seen from the example, due to the greedy approach of encoding matches, the search algorithm and the dictionary update function are not the most optimal. However, we do not claim that the algorithm would be the most efficient. It functions efficiently enough for most inputs. In this example, the original input realm data was 79 octets, and the compressed output, excluding the end mark, is 35 octets.
原因コードマッチの貪欲なアプローチに、例から分かるように、探索アルゴリズムと辞書更新機能は、最も最適ではありません。しかし、我々は、アルゴリズムが最も効率的であることを主張しません。これは、ほとんどの入力に対して効率的に十分に機能します。この例では、元の入力領域データが79個のオクテットであり、圧縮された出力は、エンドマークを除く、35オクテットです。
This section describes the construction of all new information elements.
このセクションでは、すべての新しい情報要素の構築を記載します。
This skippable extension MAY be sent by an MR to an HA in the Registration Request message.
このスキップ可能な拡張機能は、登録要求メッセージでHAにMRによって送信されるかもしれません。
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 | Subtype |A|R|S|O| Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional Mobile Router HoA ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 153 (skippable); if the HA does not support route optimization advertisements, it can ignore this request and simply not include any information in the reply. "short" extension format.
153（スキップ可能）を入力します。 HAは、ルート最適化広告をサポートしていない場合、それはこの要求を無視し、単に回答に任意の情報を含めることはできません。 「短い」の拡張形式。
Subtype 1
サブタイプ1
Reserved Set to zero; MUST be ignored on reception.
ゼロに設定された予約。レセプションで無視しなければなりません。
A Advertise my networks. If the 'A' bit is set, the HA is allowed to advertise the networks managed by this MR to other MRs. This also indicates that the MR is capable of receiving route optimization Registration Requests. In effect, this allows the MR to work in the CR role.
私のネットワークをアドバタイズ。 「」ビットが設定されている場合は、HAは、他のMRに、このMRによって管理されるネットワークをアドバタイズすることが許可されています。これはまた、MRは、経路最適化登録要求を受信することが可能であることを示しています。実際には、これは、MRは、CRの役割で作業することができます。
R Request mobile network information. If the 'R' bit is set, the HA MAY respond with information about mobile networks in the same domain.
Rは、モバイルネットワークの情報を求めます。 「R」ビットがセットされている場合、HAは、同じドメイン内のモバイルネットワークに関する情報で応答することができます。
S Solicit prefixes managed by a specific MR. The MR is specified in the Optional Mobile Router HoA field.
特定のMRによって管理されるS要請接頭辞。 MRは、オプションのモバイルルータのHoAフィールドに指定されています。
O Explicitly specify that the requesting router is only able to initiate outgoing connections and not accept any incoming connections, due to a NAT device, stateful firewall, or similar issue on any interface. This is reflected by the HA in the reply and distributed in Prefix Advertisements to other MRs.
O明示的に要求して、ルータが原因任意のインターフェイス上のNATデバイス、ステートフルファイアウォール、または同様の問題に、すべての着信接続を受け付ける発信接続を開始しないことができるだけであることを指定します。これは、応答にHAによって反射され、他のMRのプレフィックス広告に分布しています。
Optional Mobile Router HoA
オプションのモバイルルータのHoA
Solicited mobile router's home address. This field is only
included if the 'S' flag is set.
This non-skippable extension MUST be sent by an HA to an MR in the Registration Reply message, if the MR indicated support for route optimization in the registration message and the HA supports route optimization.
MRは、登録メッセージにルート最適化のためのサポートを示され、HAは、ルート最適化をサポートしている場合、この非スキップ可能な拡張は、登録応答メッセージでMRにHAによって送らなければなりません。
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 | Subtype |O|N|S| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 49 (non-skippable); "short" extension format.
49（非スキップ可能）を入力し、 「短い」の拡張形式。
Subtype 1
サブタイプ1
O The 'O' flag in the Mobile Router Route Optimization Capability Extension was set during registration.
Oモバイルルータルート最適化の機能拡張で「O」フラグは登録時に設定しました。
N NAT was detected by the HA. This informs the MR that it is located behind a NAT. The detection procedure is specified in RFC 3519 [RFC3519] and is based on the discrepancy between the registration packet's source address and indicated CoA. The MR can use this information to make decisions about route optimization strategy.
N NATは、HAによって検出されました。これは、それがNATの背後に配置されていることをMRに通知します。検出手順は、RFC 3519 [RFC3519]で指定され、登録パケットの送信元アドレスとの間の相違に基づいており、CoAを示しました。 MRは、ルート最適化戦略に関する意思決定を行うために、この情報を使用することができます。
S Responding to a solicitation. If the 'S' bit was present in the MR's Route Optimization Capability Extension (Section 5.1), this bit is set; otherwise, it is unset.
勧誘への対応S。 「S」ビットはMRのルート最適化の機能拡張（5.1節）に存在した場合、このビットが設定されています。それ以外の場合は、設定されていません。
The Reply code indicates whether route optimization has been accepted. Values of 0..15 indicate assent, and values 16..63 indicate that route optimization is not done.
返信コードは、ルート最適化が受け入れられたかどうかを示します。 0..15の値が同意を示し、16..63は、ルート最適化が行われていないことを示す値。
0 Will do route optimization.
0は、ルート最適化を行います。
16 Route optimization declined; reason unspecified.
16ルートの最適化は減少しました。指定されていない理由。
The Mobile-Correspondent Authentication Extension is included in Registration Requests sent from the MR to the CR. The existence of this extension indicates that the message is not destined to an HA, but another MR. The format is similar to the other authentication extensions defined in [RFC5944], with Security Parameter Indexes (SPIs) replaced by nonce indexes.
モバイル特派認証拡張は、CRにMRから送信された登録要求に含まれています。この拡張機能の存在は、メッセージがHA宛てていないことを示すが、別のMR。フォーマットは、ノンスインデックスに置き換えセキュリティパラメータインデックス（SPIの）と、[RFC5944]で定義された他の認証拡張機能に類似しています。
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 | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Home Nonce Index field tells the CR which nonce value to use when producing the home keygen token. The Care-of Nonce Index field is ignored in requests to remove a binding. Otherwise, it tells the CR which nonce value to use when producing the care-of keygen token. If using a pre-shared key (KRm), the indexes may be set to zero and are ignored on reception.
ホームナンスインデックスフィールドは、ホーム鍵生成トークンを生成するときに一回だけの値は、使用するCRを伝えます。気付けナンス指数フィールドは、バインディングを削除する要求は無視されます。それ以外の場合は、気付キー生成トークンを生成するときにノンス値を使用するCRを伝えます。事前共有鍵（KRM）を使用した場合、インデックスはゼロに設定されてもよいし、受信時には無視されます。
Type 49 (non-skippable); "short" extension format.
49（非スキップ可能）を入力し、 「短い」の拡張形式。
Subtype 2
サブタイプ2
Reserved Set to zero; MUST be ignored on reception.
ゼロに設定された予約。レセプションで無視しなければなりません。
Home Nonce Index
ホームナンス指数
Home Nonce Index in use. If using a pre-shared KRm, set to
zero and ignored on reception.
Care-of Nonce Index
気付けナンス指数
Care-of Nonce Index in use. If using a pre-shared KRm, set
to zero and ignored on reception.
Authenticator
オーセンティケータ
Authenticator field, by default constructed with
First (128, HMAC_SHA1 (KRm, Protected Data)).
The protected data, just like in other cases where the Authenticator field is used, consists of
認証フィールドが使用されているだけで、他の場合のように保護されたデータは、から成り
o the UDP payload (i.e., the Registration Request or Registration Reply data),
UDPペイロード（すなわち、登録要求又は登録応答データ）O、
o all prior extensions in their entirety, and
それらの全体が以前のすべての機能拡張、O、および
o the Type, Length, Home Nonce Index, and Care-of Nonce Index of this extension.
O型、長さ、ホームナンス指数、およびこの拡張のナンス指数気付。
The Care-of Address Extension is added to a Registration Reply sent by the CR to inform the MR of the upcoming tunnel endpoint.
気付アドレス拡張は、今後のトンネルエンドポイントのMRを知らせるためにCRにより送信された登録応答に追加されます。
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 | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1..n times the following information structure
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 49 (non-skippable); "short" extension format.
49（非スキップ可能）を入力し、 「短い」の拡張形式。
Length Total length of the packet. When processing the information structures, if Length octets have been reached, this is an indication that the final information structure was reached as well.
パケットの長さの合計の長さ。情報構造を処理するときに長さオクテットに到達した場合、これは、最終的な情報構造が同様に達成されたことを示しています。
Subtype 3
サブタイプ3
Care-of Address
気付アドレス
Care-of address(es) that may be used for a tunnel with the
MR, in order of priority. Multiple CoAs MAY be listed to
facilitate faster NAT traversal processing.
This non-skippable extension MAY be sent by an HA to an MR in the Registration Reply message. This extension is only included when explicitly requested by the MR in the Registration Request message, setting the 'R' flag of the Mobile Router Route Optimization Capability Extension. Implicit prioritization of prefixes is caused by the order of extensions.
この非スキップ可能な拡張は、登録応答メッセージでMRにHAによって送信されるかもしれません。明示的にモバイルルータルート最適化機能拡張の「R」フラグを設定、登録要求メッセージ中のMRによって要求されたときに、この拡張機能にのみ含まれています。接頭辞の暗黙の優先順位付けは、拡張子の順番によって引き起こされます。
The extension contains a sequence of information structures. An information structure may consist of either an MR HoA or a network prefix. Any network prefixes following an MR HoA are owned by that MR. An MR HoA MUST be first in the sequence, since one cannot have prefixes without an MR.
拡張子は、情報構造の配列を含みます。情報構造は、MRのHoAまたはネットワークプレフィックスのいずれかからなることができます。 MRのHoAを、次のいずれかのネットワークプレフィックスは、そのMRによって所有されています。 1は、MRなしプレフィックスを持つことができないので、MR HoAが、シーケンスの最初でなければなりません。
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 | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1..n times the following information structure
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|M| PLen/Info | Optional Mobile Router HoA (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Optional Prefix (1, 2, 3, or 4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Realm (1..n characters) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 50 (non-skippable); "long" extension format.
入力50（スキップ不可）。 「長い」の拡張形式。
Subtype 1
サブタイプ1
Length Total length of the packet. When processing the information structures, if Length octets have been reached, this is an indication that the final information structure was reached as well.
パケットの長さの合計の長さ。情報構造を処理するときに長さオクテットに到達した場合、これは、最終的な情報構造が同様に達成されたことを示しています。
D Delta. If D = 1, the prefix is a delta from the last Prefix, where D = 0. MUST be zero on the first information structure containing a Prefix; MAY be zero or one on subsequent information structures. If D = 1, the Prefix field is one octet in length. See Section 4.1 for details.
Dデルタ。 D = 1の場合、接頭辞は、D = 0は、プレフィックスを含む第一の情報構造にゼロでなければならない最後のプレフィックスからのデルタです。ゼロまたはそれ以降の情報構造上のものであってもよいです。 D = 1の場合、プレフィックスフィールドは長さが1つのオクテットです。詳細については、4.1節を参照してください。
M Mobile Router HoA bit. If M = 1, the next field is Mobile Router HoA, and Prefix and Realm are omitted. If M = 0, the next field is Prefix followed by Realm, and Mobile Router HoA is omitted. For the first information structure, M MUST be set to 1. If M = 1, the 'D' bit is set to zero and ignored upon reception.
MモバイルルータのHoAビット。 M = 1の場合、次のフィールドは、モバイルルータのHoAであり、接頭辞とレルムが省略されています。 M = 0の場合、次のフィールドは、プレフィックスレルム続いて、モバイルルータのHoAを省略しています。 M = 1は、「D」ビットがゼロに設定され、受信時には無視されている場合、第一の情報構造のために、Mは1に設定されなければなりません。
PLen/Info
キャプチャ/情報
This field is interpreted differently, depending on whether
the 'M' bit is set or not. If M = 0, the field is
considered to be the PLen field, and the contents indicate
the length of the advertised prefix. The 6 bits allow for
values from 0 to 63, of which 33-63 are illegal. If M = 1,
the field is considered to be the Info field. Permissible
values are 0 to indicate no specific information, or 1 to
indicate "outbound connections only". This indicates that
the target MR can only initiate, not receive, connections
on any of its interfaces (apart from the reverse tunnel to
the HA). This is set if the MR has explicitly requested it
via the 'O' flag in the Mobile Router Route Optimization
Capability Extension (Section 5.1).
Mobile Router HoA
モバイルルータのHoA
The mobile router's home address. All prefixes in the
following information structures where M = 0 are maintained
by this MR. This field is present only when M = 1.
Prefix The IPv4 prefix advertised. If D = 0, the field length is PLen bits, rounded up to the nearest full octet. Least-significant bits starting off PLen (and that are zeros) are omitted. If D = 1, the field length is one octet. This field is present only when M = 0.
プレフィックスザ・IPv4のプレフィックスがアドバタイズ。 D = 0の場合、フィールド長はPLENビットであり、最も近いフルオクテットに切り上げ。最下位ビットはPLENをオフ開始（及びゼロであること）省略されています。 D = 1の場合、フィールドの長さが1つのオクテットです。 M = 0の場合にのみ、このフィールドが存在しています。
Realm The Realm that is associated with the advertised Mobile Router HoA and prefix. If empty, MUST be set to '\0'. For realm encoding and an optional compression scheme, refer to Section 4.2. This field is present only when M = 0.
レルム宣伝モバイルルータのHoAと接頭辞に関連付けられているレルム。空の場合は、「\ 0」に設定しなければなりません。領域符号化および任意の圧縮方式については、セクション4.2を参照してください。 M = 0の場合にのみ、このフィールドが存在しています。
This message is sent from the MR to the CR when performing the RR procedure. The source and destination IP addresses are set to the MR's HoA and the CR's HoA, respectively. The UDP source port MAY be randomly chosen. The UDP destination port is 434.
RR手順を実行するとき、このメッセージは、CRにMRから送信されます。送信元および宛先IPアドレスは、それぞれ、MRのHoAとCRのHoAに設定されています。 UDPソースポートがランダムに選択することができます。 UDP宛先ポートは434です。
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 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Home Init Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 24
タイプ24
Reserved Set to zero; MUST be ignored on reception.
ゼロに設定された予約。レセプションで無視しなければなりません。
Home Init Cookie
ホームのInitクッキー
64-bit field that contains a random value, the Home Init
Cookie.
This message is sent from the MR to the CR when performing the RR procedure. The source and destination IP addresses are set to the MR's CoA and the CR's HoA, respectively. The UDP source port MAY be randomly chosen. The UDP destination port is 434.
RR手順を実行するとき、このメッセージは、CRにMRから送信されます。送信元および宛先IPアドレスは、それぞれ、MRのCoAとCRのHoAに設定されています。 UDPソースポートがランダムに選択することができます。 UDP宛先ポートは434です。
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 | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Care-of Init Cookie |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 25
タイプ25
Reserved Set to zero; MUST be ignored on reception.
ゼロに設定された予約。レセプションで無視しなければなりません。
Care-of Init Cookie
気付開始クッキー
64-bit field that contains a random value, the Care-of Init
Cookie.
This message is sent from the CR to the MR when performing the RR procedure as a reply to the Home Test Init message. The source and destination IP addresses, as well as UDP ports, are the reverse of those in the Home Test Init message for which this message is constructed. As such, the UDP source port is always 434.
ホーム試験開始メッセージに対する応答としてRR手順を実行するとき、このメッセージは、MRにCRから送られてきます。ソースおよび宛先IPアドレス、並びにUDPポートは、このメッセージが構築されたホーム試験開始メッセージにおけるものとは逆です。そのため、UDPソースポートは常に434です。
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 | Reserved | Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 26
タイプ26
Reserved Set to zero; MUST be ignored on reception.
ゼロに設定された予約。レセプションで無視しなければなりません。
Nonce Index
ノンスインデックス
This field will be echoed back by the MR to the CR in a
subsequent Registration Request's authentication extension.
Home Init Cookie
ホームのInitクッキー
64-bit field that contains a random value, the Home Init
Cookie.
Home Keygen Token
ホーム生成トークン
This field contains the 64-bit home keygen token used in
the RR procedure. Generated from cookie + nonce.
This message is sent from the CR to the MR when performing the RR procedure as a reply to the Care-of Test Init message. The source and destination IP addresses, as well as UDP ports, are the reverse of those in the Care-of Test Init message for which this message is constructed. As such, the UDP source port is always 434.
試験開始気付メッセージに対する応答としてRR手順を実行するとき、このメッセージは、MRにCRから送られてきます。ソースおよび宛先IPアドレス、並びにUDPポートは、このメッセージが構築されたテスト気付のInitメッセージにおけるものとは逆です。そのため、UDPソースポートは常に434です。
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 | Reserved | Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 27
タイプ27
Reserved Set to zero; MUST be ignored on reception.
ゼロに設定された予約。レセプションで無視しなければなりません。
Care-of Nonce Index
気付けナンス指数
This field will be echoed back by the MR to the CR in a
subsequent Registration Request's authentication extension.
Care-of Init Cookie
気付開始クッキー
64-bit field that contains a random value, the Care-of Init
Cookie.
Care-of Keygen Token
気付生成トークン
This field contains the 64-bit care-of keygen token used in
the RR procedure. Generated from cookie + nonce.
Mechanisms described in Mobile IP NAT traversal [RFC3519] allow the HA to work with MRs situated behind a NAT device or a stateful firewall. Furthermore, the HA may also detect whether a NAT device is located between the mobile node and the HA. The MR may also explicitly state that it is behind a NAT or firewall on all interfaces, and this information is passed on to the other MRs with the Info field in the Route Optimization Prefix Advertisement Extension (Section 5.5). The HA may also detect NAT and inform the registering MR via the 'N' flag in the Route Optimization Reply Extension (Section 5.2). In the case where one or both of the routers is known to be behind a NAT or is similarly impaired (not able to accept incoming connections), the tunnel establishment procedure needs to take this into account.
モバイルIP NATトラバーサル[RFC3519]で説明したメカニズムは、HAは、NATデバイスまたはステートフルファイアウォールの背後に位置のMRと連携することができます。さらに、HAはまた、NATデバイスがモバイルノードとHAとの間に配置されているかどうかを検出することができます。 MRはまた、明示的にそれはすべてのインターフェイス上のNATやファイアウォールの背後であり、この情報は、ルート最適化プレフィックス広告拡張（5.5節）でのInfoフィールドを持つ他のMRに渡されることを述べることができます。 HAはまた、NATを検出し、ルート最適化に「N」フラグを経て登録MRを通知することができる拡張（5.2節）を返信します。ルータの一方または両方がNATの背後にあることが知られているか、同様に（着信接続を受け入れることができない）が損なわれている場合には、トンネル確立手順は、これが考慮に入れる必要があります。
In the case where the MR is behind a NAT (or firewall) and the CR is not, the MR will, when the tunnel has been established, send keepalive messages (ICMP echo requests) through the tunnel. Until a reply has been received, the tunnel SHOULD NOT be considered active. Once a reply has been received, NAT mapping is in place, and traffic can be sent.
MRは、NAT（またはファイアウォール）の背後にあり、CRがない場合には、MRは、トンネルが確立されている場合、トンネルを介してキープアライブメッセージ（ICMPエコー要求）を送信します。応答が受信されるまで、トンネルはアクティブとみなされるべきではありません。応答が受信されると、NATマッピングが整備されている、およびトラフィックが送信されます。
The source address may change due to NAT in CoTI and Registration Request messages. This does not affect the process -- the hash values are calculated by the translated address, and the Registration Request will also appear from the same translated address.
送信元アドレスが原因のCoTIでNATと登録要求メッセージに変更されることがあります。ハッシュ値が変換されたアドレスによって計算され、登録要求は、同じ変換後のアドレスから表示されます - これは、プロセスに影響を与えません。
Unlike communication with the HA, in the case of route optimization, the path used for signaling is not used for tunneled packets, as signaling always uses HoAs, and the MR <-> CR tunnel is from CoA to CoA. It is assumed that even though port numbers may change, NAT processing rarely allocates more than one external IP address to a single internal address; thus, the IP address seen in the Registration Request and tunnel packets remains the same. However, the UDP source port number may be different in the Registration Request and incoming tunnel packets, due to port translation. This must not cause an error situation -- the CR MUST be able to accept tunneling packets from a different UDP source port than what was used in the Registration Request.
シグナリングは、常にのHoAを使用するようにHAとの通信とは異なり、経路最適化の場合には、シグナリングのために使用されるパスは、トンネリングされたパケットのために使用されず、MR < - > CRトンネルは、アシルCoAへのCoAです。ポート番号が変更される可能性にもかかわらず、NAT処理はほとんど単一の内部アドレスに複数の外部IPアドレスを割り当てないものとします。このように、登録要求とトンネルパケットで見られるIPアドレスは同じまま。しかし、UDP送信元ポート番号は、登録要求と、着信トンネルパケットにポート変換に起因し異なっていてもよいです。 CRは、登録要求に使用されたものとは異なるUDPソースポートからのトンネリングパケットを受け入れることができなければならない - これは、エラー状況を引き起こしてはなりません。
Since MRs may have multiple interfaces connecting to several different networks, it might be possible that specific MRs may only be able to perform route optimization using specific CoA pairs, obtained from specific networks -- for example, in a case where two MRs have an interface behind the same NAT. A similar case may be applicable to nested NATs. In such cases, the MR MAY attempt to detect eligible CoA pairs by performing a registration and attempting to establish a tunnel (sending keepalives) with each CoA listed in the Registration Reply's Care-of Address Extension. The eligible pairs should be recorded in the Route Optimization Cache. If a tunnel cannot be established with any CoAs, the MR MAY attempt to repeat the procedure with alternative interfaces. The above information on network topology can also be configured on the MRs either statically or via some external feedback mechanism.
2のMRインターフェイスを持っている場合には、例えば - のMRは、いくつかの異なるネットワークに接続する複数のインタフェースを有することができるので、特定のMRは、特定のネットワークから得られた特定のCoA対を使用してルート最適化を実行することができることが可能であるかもしれません同じNATの背後にあります。同様の場合は、ネストされたNATのに適用することができます。このような場合には、MRは、登録を行うと、登録応答の気付アドレスの拡張にリストされた各アシルCoAに（キープアライブを送信）トンネルを確立しようとすることにより、対象とCoAのペアを検出しようとすることができます。資格ペアがルート最適化のキャッシュに記録されなければなりません。トンネルは、任意のCoAとの間で確立することができない場合、MRは、別のインターフェイスを使用して手順を繰り返ししようと試みることができます。ネットワークトポロジに関する上記の情報はまた、MRの静的または何らかの外部フィードバック機構を介して上に構成することができます。
If both the MR and the CR are behind two separate NATs, some sort of proxy or hole-punching technique may be applicable. This is out of scope for this document.
MRとCRの両方が2つの別個のNATの背後にある場合は、プロキシまたは穿孔技術のいくつかの並べ替えを適用することができます。これはこの文書の範囲外です。
If both the MR and the CR move at the same time, this causes no issues from the signaling perspective, as all requests are always sent from a CoA to HoAs. Thus, the recipient will always receive the request and can send the reply. This applies even in break-before-make situations where both the MR and the CR get disconnected at the same time -- once the connectivity is restored, one endpoint of the signaling messages is always the HoA of the respective router, and it is up to the HA to provide reachability.
MRと同時にCR移動の両方の場合は、すべての要求は常にアシルCoAからのHoAに送信されているように、これは、シグナリングの観点からは問題を引き起こしません。したがって、受信者は常に要求を受信し、応答を送信することができます。接続が復元されると、シグナリングメッセージの一方のエンドポイントは、常に、各ルータのHoAであり、そしてそれがアップしている - これはさえMRとCRの両方が同時に切断されますブレーク・ビフォア・メークの状況で適用されますHAへの到達可能性を提供します。
Since foreign agents have been dropped from work related to Network Mobility for Mobile IPv4, they are not considered here.
外国人のエージェントがモバイルIPv4のためのネットワークモビリティに関連する作業から削除されているので、彼らはここでは考慮されていません。
MRs can negotiate and perform route optimization without the assistance of an HA -- if they can discover each other's existence and thus know where to send registration messages. This document only addresses a logically single HA that distributes network prefix information to the MRs. Problems arise from possible trust relationships; in this document, the HA serves as a way to provide verification that a specific network is managed by a specific router.
MRは交渉とHAの支援なし経路最適化を行うことができます - 彼らは互いの存在を発見するため、どこの登録メッセージを送信するために知ることができます。この文書では、唯一のMRへのネットワークプレフィックス情報を配信し、論理的に単一のHAに対応しています。問題は、可能な信頼関係に起因します。この文書では、HAは、特定のネットワークは、特定のルータによって管理されていることを検証を提供する方法として機能します。
If route optimization is desired between nodes attached to separate HAs, there are several possibilities. Note that standard high-availability redundancy protocols, such as the Virtual Router Redundancy Protocol (VRRP), can be utilized; however, in such a case, the HA is still a single logical entity, even if it consists of more than a single node.
ルート最適化を分離するために接続されたノードとの間に所望される場合、いくつかの可能性がありました。このような仮想ルータ冗長プロトコル（VRRP）などの標準的な高可用性冗長プロトコルは、利用することができることに留意されたいです。しかしながら、このような場合には、HAは、それが単一のノード以上で構成されても、依然として単一の論理エンティティです。
Several possibilities exist for achieving route optimization between MRs attached to separate HAs, such as a new discovery/probing protocol or routing protocol between HAs or DNS SRV records, or a common Authentication, Authorization, and Accounting (AAA) architecture. There is already a framework for HA to retrieve information from AAA, so it can be considered the most viable possibility. See Section 6.6 for information on a possible way to generalize the method.
MRは、そのような新しい発見/プローブプロトコル又はルーティングプロトコル間有するか、またはDNS SRVレコード、または共通の認証、許可、アカウンティング（AAA）アーキテクチャとして、HAS分離するために取り付けられた間、いくつかの可能性が経路最適化を達成するために存在します。そこAAAから情報を取得するために、HAのための枠組みはすでにあるので、最も実行可能な可能性を考えることができます。この方法を一般化する可能な方法の詳細については、セクション6.6を参照してください。
Any discovery/probing protocols are out of scope for this document.
どれ発見/プロービング・プロトコルは、このドキュメントの範囲外です。
The procedure as specified is asymmetric; that is, if bidirectional route optimization is desired while maintaining consistency, the route optimization (RR check and registration) has to be performed in both directions, but this is not strictly necessary. This is primarily a policy decision, depending on how often the mobile prefixes are reconfigured.
指定されたような手順は非対称です。一貫性を維持しながら双方向ルート最適化が望まれる場合、すなわち、経路最適化（RRチェックと登録）が両方向で行われなければならないが、これは厳密には必要ではありません。これは、モバイルプレフィックスが再構成される頻度に応じて、主に政策決定です。
Consider the case where two networks, A and B, are handled by MRs A and B, respectively. If the routers are set up in such a fashion that route optimization is triggered when the router is forwarding a packet destined to a network prefix in the Route Optimization Cache, the following occurs if a node in network A starts sending ICMP echo requests (ping packets) to a node in network B.
2つのネットワークA及びBは、それぞれのMR AとB、によって処理される場合を考えます。ルーターは、ネットワークA内のノードは、ICMPエコー要求（pingパケットの送信を開始した場合、以下が発生した場合、ルータは経路最適化キャッシュ内のネットワークプレフィックス宛のパケットを転送しているとき、経路最適化がトリガされるような形で設定されている場合）ネットワークB内のノードに
MR A sees the incoming ICMP echo request packet from the local network destined to network B. Since network B exists in MR A's Route Optimization Cache, the route optimization process is triggered. The original packet is forwarded via the reverse tunnel toward the HA as normal.
MR AがネットワークBはMR Aのルート最適化キャッシュに存在するのでB.をネットワークに宛てローカルネットワークからの着信ICMPエコー要求パケットを見て、ルート最適化プロセスがトリガされます。元のパケットは、通常のようにHAに向かって逆方向トンネルを介して転送されます。
MR A completes the RR procedure and registration with MR B, which thus becomes a CR for MR A. A tunnel is created between the routers. MR B updates its routing tables so that network A is reachable via the MR A <-> MR B tunnel.
MR Aは、このようにトンネルがルータの間に作成されたMR A.ためCRなるMR BとRR手順及び登録が完了する。 < - > MR BトンネルそのネットワークAは、MR Aを介して到達可能であるので、MR Bは、そのルーティングテーブルを更新します。
The traffic pattern is now such that packets from network B to network A are sent over the direct tunnel, but the packets from A to B are transmitted via the HA and reverse tunnels. The echo reply that the node in network B sends toward network A triggers the route optimization at MR B in similar fashion. As such, MR B now performs its own registration toward MR A. Upon completion, MR B notices that a tunnel to MR A already exists, and updates its routing table so that network A is now reachable via the (existing) MR A <-> MR B tunnel. From this point onward, traffic is bidirectional.
トラフィックパターンは、現在のネットワークBからのパケットは、Aをネットワークにするようなものであるダイレクトトンネルを介して送信されるが、からBへのパケットはHAを経由して送信され、トンネルを逆れます。ネットワークB内のノードは、ネットワークAに向けて送信するエコー応答は、同様の方法でMR Bで経路最適化をトリガします。このように、MR Bが今完了するMR A.向けて、自身の登録を行い、MR BはMR Aへのトンネルが既に存在し、そのネットワークAは、（既存の）MR A <介して今到達可能であるように、そのルーティングテーブルを更新することに気付きます - > MR Bトンネル。この時点から以降、トラフィックが双方向です。
In this scenario, if MR A does NOT wait for a separate route optimization process (RR check and registration) from MR B, but instead simply updates its routing table to reach network B via the tunnel, problems may arise if MR B has started to manage another network, B', before the information has been propagated to MR A. The end result is that MR B starts to receive packets from network A to network B' via the HA and to network B via the direct tunnel. If reverse path checking or a similar mechanism is in use on MR B, some of the packets from network A could be black-holed.
MR Aは、MR Bから別の経路最適化処理（RRチェックおよび登録）を待ち、その代わりに単にトンネルを介してネットワークBに到達するためにそのルーティングテーブルを更新しない場合MR Bはに開始された場合、このシナリオでは、問題が生じる可能性がHAを介して、ダイレクトトンネルを介してBをネットワークに「情報は最終的な結果は、MR BはネットワークBへのネットワークAからのパケットの受信を開始することであるMR A.に伝播される前に、」他のネットワーク、Bを管理します。逆パスチェックまたは類似のメカニズムがMR Bで使用されている場合、ネットワークAからのパケットの一部は、ブラックホールであってもよいです。
Whether to perform this mutual registration or not thus depends on the situation, and whether MRs are going to start managing additional network prefixes during operation.
したがって、この相互の登録を行うか否かは、状況に依存し、MRは運転中に追加のネットワークプレフィックスの管理を開始しようとしているかどうか。
The design considerations include several mechanisms that might not be strictly necessary if route optimization were only desired between individual customer sites in a managed network. The registration procedure (with the optional return routability part), which allows CRs to learn an MR's CoAs, is not strictly necessary; the CoAs could have been provided by the HA directly.
設計上の考慮事項は、ルート最適化が唯一の管理するネットワーク内の個々の顧客サイトの間で希望された場合には厳密には必要ではないかもしれないいくつかのメカニズムが含まれます。 CRSはMRのCoAを学ぶことができ、（オプションのリターン・ルータビリティ一部で）登録手続きは、厳密には必要ありません。 CoAを直接HAによって提供されている可能性があります。
However, this approach allows the method to be extended to a more generic route optimization. The primary driver for having an HA to work as a centralized information distributer is to provide MRs with not only the knowledge of the other routers, but with information on which networks are managed by which routers.
しかし、このアプローチは方法がより一般的なルート最適化に拡張することを可能にします。集中情報分配器として動作するようにHAを有するための主要なドライバは、他のルータの知識だけでなく持つが、ネットワークがどのルータによって管理されている情報とのMRを提供することです。
The HA provides the information on all feasible nodes with which it is possible to establish route optimization. If representing a whole mobile network is not necessary -- in effect, the typical mobile node <-> correspondent node situation -- the mechanisms in this document work just as well; the only problem is discovering whether the target correspondent node can provide route optimization capability. This can be performed by not including any prefixes in the information extension -- just the HoA of the MR.
HAは、経路最適化を確立することが可能であるとのすべての実行可能なノードの情報を提供します。全体のモバイルネットワークを表現する必要がない場合 - 実際には、典型的な移動ノード< - >相手ノード状況 - ちょうど同様に、この文書の作業中機構。唯一の問題は、ターゲット・コレスポンデントノードは、ルート最適化機能を提供できるかどうかを発見されました。 MRのちょうどHoAを - これは、情報の拡張子のいずれかの接頭辞を含めないで行うことができます。
In addition, with route optimization for a single node, checks for whether an MR is allowed to represent specific networks are unnecessary, since there are none.
いずれも存在しないので、また、単一ノードのルート最適化と、MRは、特定のネットワークを表すために許可されているかどうかをチェックが不要です。
Correspondent node/router discovery protocols (whether they are based on probing or a centralized directory beyond the single HA) are outside the scope of this document.
コレスポンデントノード/ルータ検出プロトコル（これらは、単一のHAを越えて中央のディレクトリをプロービングするかに基づいているかどうか）は、この文書の範囲外です。
This design simply provides the possibility of creating optimal paths between MRs; it doesn't dictate what the user traffic using these paths should be. One possible approach in helping facilitate load balancing and utilizing all available paths is presented in [MIPv4FLOW], which effectively allows for multiple CoAs for a single HoA. In addition, per-tunnel load balancing is possible by using separate CoAs for separate tunnels.
この設計は、単にMRの間の最適なパスを作成する可能性を提供します。それは、これらのパスを使用して、ユーザトラフィックがどうあるべきかを指示しません。ロード・バランシングを容易に支援し、すべての使用可能なパスを利用する1つの可能なアプローチは、効果的に単一のHoAのために複数のCoAを可能にする、[MIPv4FLOW]に提示されています。また、単位のトンネルのロードバランシングは、別個のトンネルの別個のCoAを使用することにより可能です。
Home agent-assisted route optimization scalability issues stem from the general Mobile IPv4 architecture, which is based on tunnels. Creating, maintaining, and destroying tunnel interfaces can cause load on the MRs. However, the MRs can always fall back to normal, reverse-tunneled routing if resource constraints are apparent.
ホームエージェント支援ルート最適化スケーラビリティの問題はトンネルに基づいており、一般的なモバイルIPv4アーキテクチャ、由来します。作成、維持、およびトンネルインターフェースを破壊することのMRの負荷を引き起こす可能性があります。リソースの制約が明らかである場合は、MRは常にノーマル、リバーストンネリングルーティングにフォールバックすることができます。
If there are a large number of optimization-capable prefixes, maintaining state for all of these may be an issue also, due to limits on routing table sizes.
最適化可能なプレフィクスの数が多い場合には、これらの全ての状態を維持することは、テーブルのサイズをルーティング上の限界に起因する問題もあってもよいです。
Registration responses from the HA to the MR may provide information on a large number of network prefixes. If thousands of networks are involved, the Registration Reply messages are bound to grow very large. The prefix and realm compression mechanisms defined in Section 4 mitigate this problem to an extent. There will, however, be some practical upper limit, after which some other delivery mechanism for the prefix information will be needed.
HAからMRへの登録応答がネットワークプレフィックスの多数の情報を提供することができます。ネットワークの数千人が関与している場合は、登録応答メッセージは非常に大きくなるためにバインドされています。セクション4で定義されたプレフィックスとレルム圧縮機構は、程度に、この問題を軽減します。しかし、プレフィックス情報のためのいくつかの他の送達メカニズムが必要とされるの後、いくつかの実用的な上限があります。
The following example assumes that there are three mobile routers -- MR A, MR B, and MR C -- each managing network prefixes A, B, and C. At the beginning, no networks are registered with the HA. Any AAA processing at the HA is omitted from the diagram.
MR A、MR B、及びMR C - - 次の例では、3つのモバイルルータが存在することを前提とし、各管理ネットワークプレフィックスA、B、およびCは、開始時に、全くネットワークがHAに登録されていません。 HAにおける任意のAAA処理は図から省略されています。
+--------+ +--------+ +--------+ +--------------+
| [MR A] | | [MR B] | | [MR C] | | [Home Agent] |
+--------+ +--------+ +--------+ +--------------+
| | | |
x------------------------------->| Registration Request
| | | | includes Mobile Router
| | | | Route Optimization
| | | | Capability Extension
| | | |
|<-------------------------------x Registration response;
| | | | no known networks from HA
| | | | in response
| | | |
| x-------------------->| Registration Request similar
| | | | to the one sent by MR A
| | | |
| |<--------------------x Registration Reply includes
| | | | network A in Route Optimization
| | | | Prefix Advertisement Extension
| | | |
| | x--------->| Registration Request similar
| | | | to the one sent by MR A
| | | |
| | |<---------x Registration Reply includes
| | | | networks A and B in Route
| | | | Optimization Prefix
| | | | Advertisement Extension.
| | | | Network B is sent in
| | | | compressed form.
| | | |
The following example has the same network setup as that in Section 8.1 -- three MRs, each corresponding to their respective network. Node A is in network A, and Node C is in network C.
3つのMR、それぞれのネットワークに対応する - 次の例では、8.1節と同様のネットワーク構成を有しています。ノードAはネットワークAであり、ノードCはネットワークCであります
At the beginning, none of the MRs know each other's KRms. If the KRms were pre-shared or provisioned with some other method, the Return Routability messages could be omitted. Signaling as described in Section 8.1 has occurred; thus, MR A is not aware of the other networks, and MR C is aware of networks A and B.
初めに、MRのどれも互いのKRmsを知りません。 KRmsは、事前共有または他のいくつかの方法でプロビジョニングされた場合は、往復経路メッセージは省略することができます。 8.1節で説明したようにシグナリングが発生しました。従って、MR Aは、他のネットワークを認識しないが、MR Cは、ネットワークAおよびBを知っています
======= Traffic inside Mobile IP tunnel to/from HA
=-=-=-= Traffic inside Mobile IP tunnel between MRs
------- Traffic outside Mobile IP tunnel
+----------+ +--------+ +------+ +--------+ +----------+
| [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
+----------+ +--------+ +------+ +--------+ +----------+
| | | | |
x------------O==========O=========O------>| Mobile Router A is
| | | | | unaware of network C;
| | | | | thus, nothing happens
| | | | |
|<-----------O==========O=========O-------x Mobile Router C
| | | | | notices packet to
| | | | | network A - begins
| | | | | route optimization
| | | | |
| | | | | Return Routability (if
| | | | | no pre-shared KRms)
| | | | |
| |<=========O---------x | CoTI
| |<=========O=========x | HoTI
| | | | |
| x==========O-------->| | CoT
| x==========O========>| | HoT
| | | | |
| | | | | KRm between MR A <-> C
| | | | | established
| | | | |
| |<=========O---------x | Registration Request
| | | | |
| x--------->| | | Registration Request
| | | | | to HA due to MR A
| | | | | being unaware of
| | | | | network C.
| | | | | Solicit bit set.
| | | | |
| |<---------x | | Registration Reply
| | | | | contains info on
| | | | | network A
| | | | |
| x==========O-------->| | Registration Reply
| | | | | includes MR A's CoA in
| | | | | Care-of Address
| | | | | Extension
| | | | |
| |<= = = = =O= = = ==>| | Optional mutual
| | | | | registration from
| | | | | MR A to MR C
| | | | | (same procedure as above,
| | | | | multiple packets);
| | | | | possible keepalive checks
| | | | |
|<-----------O=-=-=-==-=-=-=-==-=-O-------x Packet from Node C -> A
| | | | | routed to direct tunnel
| | | | | at MR C, based on
| | | | | MR C now knowing MR A's
| | | | | CoA and tunnel being up
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Packet from Node A -> C
| | | | | routed to direct tunnel
| | | | | at MR A, based on MR A
| | | | | now knowing MR C's CoA
| | | | | and tunnel being up
In this signaling example, MR C changes its CoA while route optimization between MR A and MR C is operating and data is being transferred. Cases where the handover is graceful ("make before break") and ungraceful ("break before make") both occur in similar fashion, except that in the graceful version no packets are lost. This diagram considers the case where MR C gets immediate notification of lost connectivity, e.g., due to a link status indication. MR A would eventually notice the breakdown, due to keepalive messages failing.
このシグナリングの例では、MR A及びMR Cとの間の経路最適化の動作中にMR Cは、そのCoAを変更し、データが転送されています。ハンドオーバが優雅な（「ブレークする前に行う」）と無様であるケース（「メイク前に破る」）は、パケットが失われない優雅なバージョンのものを除いて、同様の方法で起こるの両方。この図は、MR Cは、例えば、リンクステータス指示による失われた接続の即時の通知を取得する場合を考えます。 MR Aは最終的に失敗したメッセージをキープアライブによる内訳を、気付くだろう。
======= Traffic inside Mobile IP tunnel to/from HA
=-=-=-= Traffic inside Mobile IP tunnel between MRs
------- Traffic outside Mobile IP tunnel
+----------+ +--------+ +------+ +--------+ +----------+
| [Node A] | | [MR A] | | [HA] | | [MR C] | | [Node C] |
+----------+ +--------+ +------+ +--------+ +----------+
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Nodes A and C are
|<-----------O=-=-=-==-=-=-=-==-=-O-------x exchanging traffic
| | | | |
| | xxxxxxxxxxx | Break occurs: MR C
| | | | | loses connectivity to
| | | | | current attachment point
| | | | |
x------------O=-=-=-==-=-=-=->x | | Traffic from A -> C
| | | | | lost, and
| | | x<=-=-O-------x vice versa
| | | | |
| | |<--------x | MR C finds a new
| | | | | point of attachment,
| | | | | registers with the HA,
| | | | | clears routing tables
| | | | |
| | x-------->| | Registration Reply
| | | | |
x------------O=-=-=-==-=-=-=->x | | Traffic from A -> C lost
| | | | | (reverts to routing via
| | | | | HA if enough keepalives
| | | | | fail)
| | | | |
|<-----------O==========O=========O-------| Traffic from C -> A
| | | | | sent via HA
| | | | |
| O<=========O---------x | CoTI message
| | | | | (partial RR check)
| | | | |
| x==========O-------->| | CoT message
| | | | |
| |<=========O---------x | Registration Request
| | | | | reusing newly calculated
| | | | | KRm
| | | | |
| x==========O-------->| | Registration Reply
| | | | |
| O<=-=-=-=-=-=-=-=-=-=x | First keepalive check if
| | | | | using UDP encapsulation;
| | | | | also creates holes in
| x=-=-=-=-=-=-=-=-=-=>| | firewalls
| | | | |
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Traffic from A -> C
| | | | | forwarded directly again
| | | | |
|<-----------O=-=-=-==-=-=-=-==-=-O-------x Traffic from C -> A
| | | | | switches back to direct
| | | | | tunnel
| | | | |
MAX_NONCE_LIFETIME 240 seconds
MAX_TOKEN_LIFETIME 210 seconds
MAX_UPDATE_RATE 5 times
IANA has assigned rules for the existing registries "Mobile IP Message Types" and "Extensions to Mobile IP Registration Messages", specified in RFC 5944 [RFC5944]. New Mobile IP message types and extension code allocations have been made for the messages and extensions listed in Section 5.
IANAはRFC 5944 [RFC5944]で指定され、既存のレジストリ「モバイルIPメッセージタイプ」と「モバイルIP登録メッセージへの拡張機能」のルールを割り当てました。新しいモバイルIPメッセージタイプと拡張コードの割り当ては、第5章に記載されているメッセージと拡張のために作られてきました。
The route optimization authentication processing requires four new message type numbers. The new Mobile IP Message types are listed below, in Table 1.
ルート最適化の認証処理が4つの新しいメッセージタイプ番号が必要です。新しいモバイルIPメッセージの種類を表1に、下記に記載されています。
+-------+---------------------------+
| Value | Name |
+-------+---------------------------+
| 24 | Home Test Init message |
| 25 | Care-of Test Init message |
| 26 | Home Test message |
| 27 | Care-of Test message |
+-------+---------------------------+
Table 1: New Values and Names for Mobile IP Message Types
表1：モバイルIPメッセージタイプの新しい値と名前
Three new registration message extension types are required and listed in Table 2. The first type, 153, is skippable and has been allocated from range 128-255. The other two, 49 and 50, are non-skippable and have been allocated from range 0-127, with 49 being of the "short" format and 50 being of the "long" format. None of the messages are permitted for notification messages.
三つの新しい登録メッセージの拡張タイプが必要と表2の最初のタイプ、153に記載されている、スキップ可能であり、範囲128〜255から割り当てられています。他の二つの、49及び50は、非スキップ可能であり、「短い」形式と「長い」形式の50の存在の49された状態で、範囲0〜127から割り当てられています。メッセージはいずれも、通知メッセージのために許可されません。
+--------------+---------------------------------------------+
| Value | Name |
+--------------+---------------------------------------------+
| 153, 128-255 | Mobile Router Route Optimization Indication |
| 49, 0-127 | Route Optimization Extensions |
| 50, 0-127 | Route Optimization Data |
+--------------+---------------------------------------------+
Table 2: New Values and Names for Extensions in Mobile IP Registration Messages
表2：モバイルIP登録メッセージで拡張機能の新しい値と名前
In addition, the registry "Code Values for Mobile IP Registration Reply Messages" has been modified. A new success code, 2, should be allocated as follows:
また、レジストリの「モバイルIP登録応答メッセージのコード値は」変更されました。次のように新しい成功コード、2は、割り当てられる必要があります。
2 Concurrent registration (pre-accept)
2同時登録（事前承諾）
In addition, a new allocation range has been created as "Error Codes from the Correspondent Node", subject to the policy of Expert Review [RFC5226]. The range is 201-210. Three new Registration Reply codes have been allocated from this range. They are specified in Table 3, below:
また、新たに割り当て範囲は、専門家レビューの方針に従う「通信員ノードからのエラーコード」、[RFC5226]として作成されています。範囲は201-210です。三の新しい登録応答コードは、この範囲から割り当てられています。彼らは、以下の表3に指定されています。
+-------+-----------------------------+
| Value | Name |
+-------+-----------------------------+
| 201 | Expired Home nonce Index |
| 202 | Expired Care-of nonce Index |
| 203 | Expired nonces |
+-------+-----------------------------+
Table 3: New Code Values and Names for Mobile IP Registration Reply Messages
表3：モバイルIP登録応答メッセージのための新しいコード値と名前
Three new number spaces were required for the subtypes of the extensions in Table 2. A new registry, named "Route Optimization Types and Subtypes", has been created with an allocation policy of RFC Required [RFC5226]. The registration entries include Type, Subtype, and Name. Type and Subtype have a range of 0-255. Types are references to registration message extension types. Subtypes are allocated initially as in Table 4, below:
三つの新しい数のスペースを表2に拡張のサブタイプのために必要とされた「ルート最適化型およびサブタイプ」という名前の新しいレジストリは、RFC必要な[RFC5226]の割り当てポリシーを使用して作成されています。登録エントリは、タイプ、サブタイプ、および名前が含まれます。タイプとサブタイプは、0〜255の範囲を持っています。種類は、登録メッセージ拡張型への参照です。サブタイプは下記の表4のように最初に割り当てられています。
+------+---------+--------------------------------------------------+
| Type | Subtype | Name |
+------+---------+--------------------------------------------------+
| 153 | 0 | Reserved |
| 153 | 1 | Mobile Router Route Optimization Capability |
| | | Extension |
| 49 | 0 | Reserved |
| 49 | 1 | Route Optimization Reply |
| 49 | 2 | Mobile-Correspondent Authentication Extension |
| 49 | 3 | Care-of Address Extension |
| 50 | 0 | Reserved |
| 50 | 1 | Route Optimization Prefix Advertisement |
| | | Extension |
+------+---------+--------------------------------------------------+
Table 4: Initial Values and Names for Registry Route Optimization Types and Subtypes
表4：レジストリルート最適化型およびサブタイプの初期値と名前
There are two primary security issues: One issue relates to the RR check, which establishes that a specific CoA is, indeed, managed by a specific HoA. The other issue is trust relationships and an arbitrary router claiming to represent an arbitrary network.
二つの主要なセキュリティ問題があります：1つの問題は、特定のCoAは、確かに、特定のHoAによって管理されていることを確立RRチェック、に関するものです。他の問題は、信頼関係や任意のネットワークを表現するために主張している任意のルータです。
The end-user traffic can be protected using normal IPsec mechanisms.
エンドユーザのトラフィックは、通常のIPsecメカニズムを用いて保護することができます。
The RR check's security has been vetted with Mobile IPv6. There are no major differences, apart from two issues: connectivity check and replay attack protection. The connectivity check is conducted with a separate ICMP message exchange. Replay attack protection is achieved with Mobile IPv4 timestamps in the Registration Request's Identification field, in contrast to the sequence numbers used in Mobile IPv6.
RRチェックのセキュリティは、モバイルIPv6で吟味されています。接続性チェックとリプレイ攻撃からの保護：なし大きな違いは別に二つの問題から、ありません。接続性チェックが別ICMPメッセージ交換を用いて行われます。リプレイ攻撃からの保護は、モバイルIPv6で使用されるシーケンス番号とは対照的に、登録要求の識別フィールドに、モバイルIPv4のタイムスタンプを用いて達成されます。
The RR procedure does not establish any kind of state information on the CR; this mitigates denial-of-service attacks. State information is only maintained after a Registration Request has been accepted.
RR手順は、CRの状態情報の任意の種類を確立しません。これは、サービス拒否攻撃を緩和します。登録要求が受け入れられた後の状態情報のみが維持されています。
The network of trust relationships in home agent-assisted route optimization solves possible trust issues: An arbitrary CR can trust an arbitrary MR that it is indeed the proper route to reach an arbitrary mobile network.
ホームエージェント支援ルート最適化における信頼関係のネットワークは、可能な信頼の問題を解決します：任意のCRは、確かに任意のモバイルネットワークに到達するための適切なルートであることを、任意のMRを信頼することができます。
It is assumed that all MRs have a trust relationship with the HA. Thus, they trust information provided by the HA.
すべてのMRがHAとの信頼関係を持っていることを想定しています。このように、彼らは、HAによって提供される情報を信頼しています。
The HA provides information matching HoAs and network prefixes. Each MR trusts this information.
HAは、情報マッチングのHoAとネットワークプレフィックスを提供します。各MRは、この情報を信頼します。
MRs may perform the RR procedure between each other. This creates a trusted association between the MR's HoA and CoA. The MR also claims to represent a specific network. This information is not trustworthy as such.
MRは、互いの間のRR手順を実行することができます。これは、MRのHoAとCoAとの間に信頼できる関連付けを作成します。 MRは、特定のネットワークを表すために主張しています。この情報は、次のような信頼できないです。
The claim can be verified by checking the HoA <-> network prefix information received, either earlier, or due to an on-demand request, from the HA. If they match, the MR's claim is authentic. If the network is considered trusted, a policy decision can be made to skip this check. Exact definitions on situations where such decisions can be made are out of scope for this document. The RECOMMENDED general practice is to perform the check.
< - >クレームはHoAをチェックすることによって確認することができ、受信したネットワークプレフィックス情報を、どちらか先に、又はによるHAからのオンデマンド要求に。それらが一致する場合は、MRの主張は本物です。ネットワークが信頼できると見なされた場合、政策決定には、このチェックをスキップさせることができます。そのような決定を行うことができるような状況の正確な定義はこの文書の範囲外です。推奨一般的には、チェックを実行することです。
Thanks to Alexandru Petrescu for constructive comments and support. Thanks to Jyrki Soini and Kari Laihonen for initial reviews. This work was supported by TEKES as part of the Future Internet program of TIVIT (Finnish Strategic Centre for Science, Technology and Innovation in the field of ICT).
建設的なコメントやサポートのためのアレクサンドル・ペトレスクに感謝します。最初のレビューのためのユルキSoiniとカリLaihonenに感謝します。この作品は、TIVIT（ICT分野における科学、技術革新のためのフィンランド戦略センター）の今後のインターネットプログラムの一環としてTEKESによってサポートされていました。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
、RFC 3519、2003年4月、 "ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル" [RFC3519] Levkowetz、H.とS. Vaarala、。
[RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, "Network Mobility (NEMO) Extensions for Mobile IPv4", RFC 5177, April 2008.
[RFC5177]レオン、K.、Dommety、G.、ナラヤナン、V.、およびA.ペトレスク、 "モバイルIPv4のためのネットワークモビリティ（NEMO）の拡張"、RFC 5177、2008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]パーキンス、C.、エド。、 "IPv4のIPモビリティのサポート、改訂"、RFC 5944、2010年11月。
[MIP-RO] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress, September 2001.
[MIP-RO]パーキンス、C.およびD.ジョンソン、 "モバイルIPにおける経路最適化"、進歩、2001年9月の作品。
[MIPv4FLOW] Gundavelli, S., Ed., Leung, K., Tsirtsis, G., Soliman, H., and A. Petrescu, "Flow Binding Support for Mobile IPv4", Work in Progress, February 2012.
【MIPv4FLOW] Gundavelli、S.編、レオン、K.、Tsirtsis、G.、ソリマン、H.、およびA.ペトレスク、 "モバイルIPv4のフローバインディングサポート"、進歩、2012年2月に働いています。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003.
[RFC3543]ガラス、S.とM.チャンドラ、 "モバイルIPv4における登録失効"、RFC 3543、2003年8月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク3、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]パーキンス、C.、エド。、ジョンソン、D.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 6275、2011年7月。
Authors' Addresses
著者のアドレス
Antti Makela Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto FINLAND
コミュニケーションとネットワーキングのアンティマケラアールト大学学部（Comnet）P。 13000 FIN-00076アアルトFINLAND箱
EMail: antti.t.makela@iki.fi
メールアドレス：antti.t.makela@iki.fi
Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND
Jouni Korhonen、ノキアシーメンスネットワークスLinnoitustie 6 FI-02600エスポーフィンランド
EMail: jouni.nospam@gmail.com
メールアドレス：jouni.nospam@gmail.com