[要約] RFC 6521は、モバイルIPv4ネットワーク間のホームエージェント支援ルート最適化に関する規格です。このRFCの目的は、モバイルネットワークのパフォーマンスを向上させるために、ホームエージェントがルート最適化をサポートする方法を提供することです。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]にルート最適化の方法はありませんでした。モバイルIPv6 [RFC6275]とは異なり、ルートの最適化が最初から含まれており、モバイルIPv4を使用して、ルート最適化は一般化された範囲では対処されていません。
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.
ミスター氏は依然として実用的なシナリオです。このドキュメントで指定されている方法は、MRS間のルート最適化のみであることに注意してください。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サイトからサイトへのVPNSで接続されます。サービスレベル契約（SLA）を使用すると、顧客は非常に信頼性が高く、サポートされたイントラネット接続を取得できます。ただし、「消費者グレード」ブロードバンドインターネットアクセスのコストと比較して、SLA-Guearandeedバージョンは非常に高価であると見なすことができます。ただし、これらの消費者グレードオプションは、ミッションクリティカルなアプリケーションに対する信頼できるアプローチではありません。
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、特にMRSは、消費者グレードのインターネットアクセスを介して実装された場合でも、接続の信頼性を向上させるために使用できます。顧客は、実際のアクセステクノロジーに参加していない仮想サービスプロバイダーのクライアントになります。サービスプロバイダーには、顧客に配布するバックエンドシステムとIPアドレスプールがあります。アクセスは複数の独立した、おそらく消費者グレードのISPによって提供され、特定のISPからのサービスが失敗した場合、モバイルIPはシームレスなハンドオーバーを提供します。このソリューションの欠点は、星のトポロジを作成することです。すべてのモバイル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.
ルートの最適化はこの問題に対処し、サイトAとB間のトラフィックがISP Bのネットワークを介して直接流れるように、またはISPピアリングポイント（メトロポリタンエリアイーサネット（MAE）など、Mae-Westなどのリンク障害の場合に、）。バックエンドは重い負荷にかかっていません。
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.
このドキュメントの仕様は、バックエンドの負荷を最小限に抑えるという主要な設計目標とともに、実験的であることを意図しています。追加の設計目標には、すべてのMRSが同じホームエージェントに家に帰ることを要求しないなど、より一般化された範囲への拡張性が含まれます。実際の操作への適用性、シグナリングスケーラビリティ、このドキュメントで特別に対処されていない他のモバイル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.
前述のユースケースは、元のアプリケーションです。この仕様を標準のトラックに移動すると、十分な展開エクスペリエンスが収集された後に考慮される必要があります。前述の問題に加えて、実際の経験に基づいて洗練を必要とする可能性のある追加要素は、ピアMRSが管理するネットワーク上の情報の提供です。Mr <-> Mr Authenticationを指揮。接続性の崩壊やその他の侵入前のトポロジーの変化に対する反応、および回復方法。キープライブタイマー間隔;シグナリング拡張機能の形式。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]は、自宅から離れている間にモバイルノードに転送されたデータグラムのモバイルノードに向かうトンネルの終了点として定義します。このプロトコルは、2つの異なるタイプの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はピアMRであり、1つ以上のネットワーク全体を表す可能性があります。
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.
ホストネットワークプレフィックスは、1つのホストで構成される192.0.2.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]は、モビリティ結合を、HOAとCOAの関連として定義し、その関連付けに残っている寿命を定義しています。
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]は、おそらく飛行機、船、電車、電車で一緒に移動する1つ以上のネットワーク全体のモビリティを担当するルーターであるモバイルノードとしてモバイルルーターを定義します。自動車、自転車、またはカヤック。
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.
ルート最適化キャッシュは、ルート最適化のための可能な目的地を含むMRSによって維持されるデータ構造として定義されます。キャッシュには、潜在的なCRとそれに関連するモバイルネットワークに関する情報（HOAS）が含まれています。
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.
Return Routabilityは、MRのHOAをCRのCOAに程度信頼してCOAに結合する手順として定義されます。
| (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.
この仕様のいくつかの式は、シンボル「|」を使用します|のように、bytewise concatenationを示すためB.この連結では、データムAのオクテットAのすべてが結果に最初に表示され、その後にデータムBのすべてのオクテットが表示されることが必要です。
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.
このセクションでは、[RFC5177]で定義されているベースNEMOV4操作と比較したHAおよびMRの変化した機能について説明します。基本的な前提はまだ同じです。MRSは、HAに登録する場合、HAに管理しているモバイルネットワークのプレフィックス（明示的なモード）を通知するか、HAはすでにプレフィックスの割り当てを知っています。ただし、プレフィックス<-> MRマッピング情報の代わりに、HAと単一のMRにのみ残っている情報をマッピングする代わりに、この情報は他のMRSにも配布されます。
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.
ホームエージェント支援ルート最適化は、主に、単一の組織または管理ドメインの複数のサイト間のトラフィックパターンの最適化を支援することを目的としています。ただし、すべてのMRSが同じ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が他のMRS Untleatitedからメッセージを受信できることを要求します。つまり、最初にリクエストを開始することなく。この動作は、未承諾メッセージを受け入れる - は、登録取消手順[RFC3543]に似ています。メカニズムの多くは、登録時に広告ルートの最適化サポートが登録リクエストを受け取り、他のMRSからのルー上のメッセージを返す機能を意味するという事実を含め、メカニズムの多くが同じです。
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は、明示的に登録されているか既に構成されているかに関係なく、管理されたネットワークプレフィックスに関する情報の再分配を許可する場合があります。これらは、モバイルルータールート最適化機能拡張で示されています。セクション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は、特定のMRSの背後にあるネットワークプレフィックスが到達可能な情報に関する情報をすでに維持しています。この機能の唯一の変更は、この情報をリクエストに応じて他のMRSに配布できることです。このリクエストは、ルート最適化機能拡張機能（セクション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 [RFC3519]の手順を使用してHAとMRの間でNATが検出されたかどうかをMRに通知します。
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).
返信メッセージには、1つのルート最適化プレフィックス広告拡張機能が含まれている場合があります。これは、再配布の資格がある場合は、既存のモバイルネットワークプレフィックスとそれらを管理するMRのMRに通知することもあります。ネットワークは、最初にリストされたルート最適化の最も望ましいターゲットとして、ポリシーによってプレフィックスを決定し、優先順位に含める必要があります。拡張機能は、セクション5.5に示されているように構築されます。拡張機能は、HOAで識別される各MRが対応するプレフィックス（ES）とそれぞれの領域でリストされているリストで構成されています。
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.
各ネットワークプレフィックスは、通常は「組織.example.com」という形式で、レルム[RFC4282]に関連付けられます。顧客独自の組織のルーターに加えて、プレフィックスリストには、他のMRS、たとえば、インターネット接続のインターネットゲートウェイまたは可能なエクストラネットに属する追加のプレフィックスを指すデフォルトのプレフィックス（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.
ネットワークのプレフィックスがMRに単一のHAに接続することに割り当てられる典型的なシナリオでは、通常、接頭辞は連続するか、少なくとも互いに非常に近いものです。これらの特性により、オプションのプレフィックス圧縮メカニズムが提供されます。別のオプションの圧縮スキームは、領域が同じ高レベルのドメインを共有することが多い領域情報に使用されています。これらの圧縮メカニズムについては、セクション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 HOASをホストプラフィックスとしてローカルルート最適化キャッシュに挿入するものとします。存在する場合、追加のプレフィックス情報もルート最適化キャッシュに挿入するものとします。
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.
ルートの最適化をサポートすると、ルート最適化キャッシュが維持されます。
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.
ルート最適化キャッシュには、潜在的なCRHOA、各HOAに関連するネットワーク、NATに関連する到達可能性に関する情報、およびRR手順に関連する情報間のマッピングが含まれています。キャッシュは、ルート最適化のプレフィックス広告拡張機能とCRSからの登録メッセージの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と新しいCOAがリストされている場合があります。
CR-HoA
cr-hoa
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).
特派員ルーターのケアアドレス（ES）。知られていない場合は空になる可能性があります。潜在的なトンネルの宛先アドレス（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カプセル化に必要なKeepAliveメッセージを送信します。
NAT states
Nat States
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
ブール科のテーブル。NATの認識を必要とすることが知られている潜在的なMR-CoasとCr-Coasのすべてのペアのエントリが含まれています。テーブルは、静的または操作中に受け取った情報に基づいて入力されています。Trueの設定は、このCOAのペアを使用して、MRがCRに向かってUDPトンネルを確立できることを示しています。受信した広告は、値がすべきであることを示すことができます
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.
それぞれのCRのすべてのCOAのすべてについて偽に設定します。この表の設定は、トンネルの確立方向に影響します。登録返信に住所のケア拡張に含まれるCOASを決定する際のセクション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.
各CR-HOA-MR-COAペアのルーティング可能性状態を返します。状態は非アクティブであり、進行中、活動的です。状態が非アクティブである場合、RRプロシージャは、ルート最適化されたトラフィックを転送する前に完了する必要があります。状態が進行中またはアクティブな場合、CRへのトンネルが確立されている限り、このCRに関する情報をルート最適化キャッシュから削除してはなりません。
KRms
KRMS
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.
各CR-HOAの登録管理キー-MR-Coaペア。このフィールドは、静的に構成されている場合にのみ使用されます。KRMがRR手順を使用して計算された場合、NoncesとRouterキーに基づいてその場で計算されます。静的に構成されている場合、rrStateは永続的にアクティブに設定されます。
Care-of nonce indices
Care-of NonCEインデックス
If the KRm was established with the RR procedure, contains the care-of nonce index for each MR-CoA - CR-HoA pair.
KRMがRR手順で確立された場合、各MR-COA-CR-HOAペアのCare-of NonCEインデックスが含まれています。
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.
KRMがRR手順で確立された場合、各MR-COA-CR-HOAペアのケアオブキーゲントークンが含まれています。
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 NonCeインデックスが含まれています。
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が含まれます。常に少なくとも1つのエントリが含まれています。CR-HOAホストネットワークプレフィックスは192.0.2.1/32です。
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).
RR手順の目的は、信頼できる方法でCOA <-> HOAバインディングを確立することです。モバイルIPv6のRR手順は[RFC6275]で説明されています。同じ原則がモバイルIPv4バージョンに適用されます。2つのメッセージがCRのHOAに送信されます。1つはMRのHOAを使用し、もう1つはMRのCOAから直接、2つの応答が同じルートを通過します。登録管理キーは、これらのメッセージに掲載されたトークン情報から派生しています。この登録管理キー（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はMRSで静的に構成するか、目的の外部セキュアキープロビジョニングメカニズムを使用して構成できます。KRMが他のメカニズムを介してMRSに知られている場合、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.
RR手順は、ホームテストINIT（HOTI）、ケアオブテストINIT（COTI）、ホームテスト（HOT）、およびケアオブテスト（COT）の4つのモバイルIPメッセージで構成されています。セクション5.6から5.9に示すように構築されています。MRが登録リクエストにモバイルルータールート最適化機能拡張機能を含めた場合、返品可能性メッセージを受け入れることができなければなりません。メッセージは、モバイルIPシグナリングパケットとして配信されます。HotiメッセージとCOTIメッセージの宛先アドレスはCRのHOAに設定されており、ソースはそれぞれMRのHOAとCOAです。
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手順は、MRがHotiメッセージとCOTIメッセージを送信することから始まります。それぞれが（異なる）64ビットランダム値（Cookie）を含みます。Cookieは、特定のシグナリング交換を一緒に結合するために使用されます。
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は、応答としてそれぞれHOTおよびCOTメッセージを作成することにより、HOTIおよびCOTIメッセージに応答します。ホットメッセージには、Home Int Cookie、現在のHome Nonce Index、およびHome Keygenトークンが含まれています。COTメッセージには、Care-of Init Cookie、Current Care of Nonce Index、およびCare-of Keygenトークンが含まれています。
The home keygen token is constructed as follows:
ホームキーゲントークンは次のように構築されています。
Home keygen token = First (64, HMAC_SHA1 (Kcr, (home address | nonce | 0)))
Home keygen token = first（64、hmac_sha1（kcr、（home address | nonce | 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)))
Kear-of keygen token = first（64、hmac_sha1（kcr、（Care-of Address | nonce | 1））））
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のルート最適化キャッシュのRRSTATEフィールドが非アクティブである場合、RR手順を開始する必要があります。状態が非アクティブである場合、RR手順が開始されると、状態は進行中に設定されなければなりません。ハンドオーバーが発生した場合、MRはCOTIメッセージを送信して、新しいKeygenトークンのケアを取得する必要があります。ホームキーゲントークンはまだ有効かもしれません。登録への返信がトークンの1つまたは両方が期限切れになっていることを示している場合、RRSTATEは非アクティブに設定する必要があります。その後、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手順が完了すると、Route Optimization CacheのRRSTATEフィールドがアクティブに設定され、登録リクエストを送信できます。MRはKRMを確立します。デフォルトでは、これは次のようにSHA1ハッシュアルゴリズムを使用して行われます。
KRm = SHA1 (home keygen token | care-of keygen token)
krm = sha1（home keygenトークン| keygenトークンのケア）
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（home keygen token）
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として機能している状況で、ピアMRSを認証するために使用されます。これは、モバイル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つ以上のインデックス付きNoncesも維持しています。Noncesは、良好な乱数ジェネレーター[RFC4086]で定期的に生成する必要があります。MRは、すべてのMRSと同じノンセを使用する場合があります。ノンセスは任意の長さであり、推奨される長さは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.
ルーターキーとNonCeの更新ガイドラインは、モバイルIPv6のガイドラインと似ています。夫人は、現在のNonCEと、寿命がまだ期限切れになっていない有効な以前の非セットの小さなセットの両方を維持しています。 NonCEは、RR応答の構築に最初に使用された後、少なくともMAX_TOKEN_LIFETIME秒（セクション9を参照）の間有効なままでなければなりません。ただし、CRは、最初の使用後にMAX_NONCE_LIFETIMEを超えて非速度を受け入れてはなりません（セクション9を参照）。これらの2つの定数の違いは30秒であるため、上記の寿命を実施する便利な方法は、30秒ごとに新しいNonCEを生成することです。その後、ノードは、最後の8（max_nonce_lifetime / 30）noncesに基づいているkeygenトークンを引き続き受け入れることができます。これにより、キーゲントークンは、最初の30秒の期間の開始または終了時にトークンが送信されたかどうかに応じて、モバイルノードに送信されてからMAX_NONCE_LIFETIME秒からMAX_TOKEN_LIFETIMEに容認されます。特派員ノードは、オンデマンドで新しいNoncesを生成しようとする場合、または古いNoncesが使用されている場合のみであることに注意してください。これは、特派員ノードが初めてNoncesが初めて使用されたかを追跡し、すべての返品可能性リクエストで新しいNoncesを生成しない限り、可能です。
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が更新されるのと同時に更新を実行する必要があります。このようにして、NonCEインデックスを使用して、KCRとNonCesの両方を参照できます。
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.
IPv4に関する2つの問題があり、モバイルIPv6ルートの最適化と比較すると異なります。まず第一に、モバイルIPv4は常にトンネルを使用しているため、MRとCRのCOASの間にトンネルが確立されている必要があります。CRは、登録リクエストに含まれているため、MRのCOAを学習します。MRは、登録返信で、新しい拡張機能「Care-of Address」を介してCRのCOAを学習します。2番目の問題はセキュリティに関する考慮事項です。登録要求では、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が異なるCRS（および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間のルート最適化はいつでも確立できます。ただし、より良い一般的な慣行は、オンデマンドでのみルート最適化を実施することです。ルートの最適化は、ローカルマネージドネットワークから発信されるパケットを送信する場合（およびネットワークがルートの最適化可能として登録されている場合）、宛先アドレスがルート最適化キャッシュのネットワークプレフィックス内に収まる場合にのみ開始することをお勧めします。少数のMRSでは、このようなオンデマンドの動作は必要ない場合があり、フルメッシュルートの最適化が常に導入される可能性があります。
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つまたは複数のインターフェイス、1つ以上のインターフェース（ISPが提供するものなど）への1つまたは複数のインターフェイス（S）、および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.
ルーティングテーブルには、通常、確立されたルート最適化トンネルインターフェイスに関連付けられたCRSによって管理されるネットワークプレフィックスを含める必要があります。デフォルトのルートは、プレフィックス情報によってオーバーライドされていない場合、HAへの逆トンネルを指す場合があります。ルーティングテーブルには、トンネルの実装で必要な場合、追加のルートが含まれる場合があります。
The routes for the HoAs of any CRs SHOULD also be pointing toward their respective tunnels that are using the optimized path.
CRSのHOASのルートは、最適化されたパスを使用しているそれぞれのトンネルを指している必要があります。
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は識別フィールドに有効性を確認する必要があります。Authenticatorフィールドは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カプセル化を指定する必要があります。Keepaliveメカニズムを介してパス障害の検出を容易にするために、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およびNonCEインデックスに対する登録要求の認証をチェックします。これにより、登録要求が有効なMRからのものであることが保証されます。チェックが失敗した場合、適切な登録返信コードが送信されます（セクション10を参照）。障害がNONCE INDEXの有効期限が切れるための場合、MRはCRの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
チェックが通過した場合、CRはルート最適化キャッシュをチェックして、MRが存在するかどうかを判断する必要があります。
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".
そして、「ha」フラグは、各プレフィックスに当てはまります）。視点は常にローカルであることに注意してください。CRは、CR-HOAエントリをMRの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は「S」（Solicitation）ビットセットでHAに再登録要求を送信する必要があります。これにより、着信MRが管理するネットワークプレフィックスに関する最新情報が取得されます。この更新の後でも、プレフィックスがまだ一致しない場合、Replyのモバイルネットワーク確認コードを「bobnet_unauthorized」に設定する必要があります。登録も完全に拒否される場合があります。この検証は、任意のネットワークを表すと主張する夫人から保護するために行われます。ただし、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へのトンネルがすでに存在するかどうかを判断するためにチェックする必要があります。トンネルが存在しない、または間違ったエンドポイント（COAS）がある場合、新しいトンネルを確立する必要があり、ルート最適化キャッシュが更新されます。返信には、MRがトンネルを設立する資格のあるCOA（セクション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へのトンネルがすでに存在するかどうかを判断するためにチェックする必要があります。トンネルが存在しない、または間違ったエンドポイント（COAS）がある場合、新しいトンネルを確立する必要があり、ルート最適化キャッシュが更新されます。これについては、セクション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.
MRのネットワークがMRへの直接トンネルを介して到達可能であることを示すために、CRのルーティングテーブルを更新する必要があります。
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.
トンネルが確立された後、MRはルーティングテーブルを更新してトンネルを介してすべてのCRのプレフィックスに到達することができますが、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
ルート最適化手順は、それぞれが互いのCRとして機能する両方のMRで同時に発生する可能性があるため、2つのルーターがそれらの間に同時に個別のトンネルを確立しようとする状況がある可能性があります。小さいHOAを備えたルーター（IPv4アドレスを32ビットの符号なし整数として扱う通常の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.
リクエスト（CRロールで）独自の登録要求（MRロールで送信）は保留中ですが、回答コード「同時登録」（値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カプセル化を使用することをお勧めします。ジェネリックルーターカプセル化（GRE）[RFC2784]、IPオーバーIP [RFC2003]、または最小限のカプセル化[RFC2004]の場合、到達可能性に関する特別な考慮事項は必要ありません。トンネルにはステートフル情報がありません。パケットは、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のトンネルのオリジネーションポイントは、登録要求が送信されたHOAではなく、COAです。これは、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.
特にUDPカプセル化の使用から、特にMRSの1人がNATまたはファイアウォールの後ろに位置する場合に特別な考慮事項が高まっています。RFC 3519 [RFC3519]からの逸脱は、最初のキープライブが送信された後、パス障害を検出するためにトンネルの両端からキープライブを送信する必要があることです。これにより、MRとCRの両方がパス障害を検出できます。
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 KeepaliveはMRによって送信される必要があります。トンネルがトラフィックの資格があると見なされた場合にのみ、最初のKeepAliveが正常に完了した後にのみ。最初のKeepaliveへの返信が受信されない場合、MRは、登録返信によって提供された他のCOAにKeepAliveを送信して、より良い接続を提供するかどうかを確認することを選択することを選択します。または、これらすべてが失敗した場合、MRは代替インターフェイスを介して再登録を実行するか、完全に登録することができます。セクション6.1を参照してください。最初のKeepaliveパケットが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時間あたりの時間。KeepAliveの目的は、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」は、初期トンネル確立フェーズにのみ適用されます。トンネルが2つのルーターの間に確立されると、どちらかがトンネルを取り壊すか、ハンドオーバーを実行することを選択できます。信号メッセージを有効な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）および「Make-Be-Be-Be-Bree-Break」（MBB）の状況としても知られていない、不GracefulまたはGracefulに分類できます。
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.
氏がホームリンクに参加したい場合、登録リクエストをゼロに設定して登録要求をHAに送信することに加えて、そのようなリクエストをすべての既知のCRSにHOASに送信する必要があります。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
ハンドオーバーの場合、CRは単にトンネルの目的地をMRの新しいCOAに更新する必要があります。MRは、通常10秒程度に、短い猶予期間、古いCOAと新しいCOAの両方からパケットを受け入れ続ける必要があります。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.
カプセル化は、可能であれば、登録信号とトンネルトラフィックの両方に同じポート番号を使用することをお勧めします。MRが送信した最初のキープライブメッセージは、MRとCRの間に直接的な接続性が存在することを確認します - Keepaliveが失敗した場合、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の変更はKRMを無効にするため、新しいCOAを介してCOTIメッセージを送信し、新しいKeygenトークンの新しいケアを取得することにより、部分的な戻りルーティング可能性を実施することをお勧めします。すべての場合において、既存のトークンが期限切れになった場合、必要なトークンも取得する必要があります。
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がモバイルネットワークのプレフィックスに維持している情報とMRSのルート最適化キャッシュは、明示的に同期する必要はありません。これは、モバイルネットワーク内のノード間の少なくとも一部のトラフィックが常に双方向であるという仮定に基づいています。オンデマンドルートの最適化を使用している場合、これは、モバイルネットワーク内のノードが別のモバイルネットワークのノードに話しかけると、初期パケットがルートの最適化をトリガーしない場合、返信パケットが表示されることも意味します。
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つのモバイルネットワーク、A、B、およびCの状況を考慮して、MR A、MR B、MR 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.
B氏は、A氏を介してAに到達できるモバイルネットワークAに関する情報を登録および受け取ります
MR C registers and receives information on both of the other mobile networks.
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
モバイルネットワークCのノードがモバイルネットワークAにトラフィックを送信しようとしている場合、ルートの最適化は簡単です。C氏はすでにルート最適化キャッシュにネットワークAを持っています。したがって、パケット伝送は、C氏のときにAに向かってルートの最適化をトリガーします
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.
A氏（RR手順が完了した後）に登録すると、A氏はモバイルネットワークCに関する情報を持っていません。したがって、HAオンデマンドで再登録を実行します。これにより、A氏は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に送信した場合、B氏はネットワーク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.
すべてのMRSが同じ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がプレイされる新しいマスタープレフィックスのビット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.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ビットのプレンは、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は1に変更されます。バイナリの最終表記は「1001」、または0x09です。
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は1に変更されます。バイナリの最終表記は「101」、または0x05です。
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）のラベルの長さは許可されていません。次に、「ラベルの長さ」タグOctetの後に、実際のエンコードされたラベル文字列の最大127オクテットが続きます。
The index to the dictionary (the "label index" tag octet) takes the form of one octet as follows:
辞書のインデックス（「ラベルインデックス」タグOctet）は、次のように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.
検索アルゴリズムは、各入力領域の「最も長い非一致文字列」も維持します。辞書の検索が失敗し、「ラベルの長さ」タグを使用して新しいラベルがエンコードされ、辞書に挿入されるたびに、「最も長い非一致する文字列」は、分離を含むこのラベルによって連結されます。（ドット、つまり、16進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」、「emple.com」、および「bar.example」を圧縮する必要があるかもしれません。.com.org "。次の例は、左側の入力レルムの処理と右側の辞書の内容を示しています。この例では、数字の16進表現を使用しています。
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)
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)
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)
4) Input "example.com" Search("example.com") -> match to 0x04 Encode(0x84) Encode(0x00)
4) 入力「Example.com」検索（ "Example.com"） - > 0x04 Encode（0x84）Encode（0x00）に一致する
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)
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.
このスキップ可能な拡張機能は、登録要求メッセージで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 |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.
私のネットワークを宣伝します。「A」ビットが設定されている場合、HAはこのMRによって管理されたネットワークを他のMRSに宣伝することが許可されています。これは、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によって管理されるSOLICTプレフィックス。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に反映され、他のMRSにプレフィックス広告で配布されます。
Optional Mobile Router HoA
オプションのモバイルルーターHOA
Solicited mobile router's home address. This field is only included if the 'S' flag is set.
モバイルルーターのホームアドレスを求めました。このフィールドは、「S」フラグが設定されている場合にのみ含まれています。
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.
モバイル対応認証拡張機能は、MRからCRに送信された登録要求に含まれています。この拡張機能の存在は、メッセージがHAに運命づけられていないことを示しています。この形式は、[RFC5944]で定義されている他の認証拡張機能と類似しており、セキュリティパラメーターインデックス（SPI）がNonCEインデックスに置き換えられます。
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.
Home Nonce Indexフィールドは、Home Keygenトークンを作成するときに使用するNonCe値をCRに伝えます。Care-of NonCEインデックスフィールドは、バインディングを削除するリクエストでは無視されます。それ以外の場合は、CRに、Care-of Keygenトークンを生成する際に使用するNonCe値を指示します。事前共有キー（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
Home Nonce Index in use. If using a pre-shared KRm, set to zero and ignored on reception.
使用中のホームノンセインデックス。事前に共有KRMを使用している場合、ゼロに設定し、レセプションで無視されます。
Care-of Nonce Index
Care-of NonCEインデックス
Care-of Nonce Index in use. If using a pre-shared KRm, set to zero and ignored on reception.
使用中のCare-of NonCEインデックス。事前に共有KRMを使用している場合、ゼロに設定し、レセプションで無視されます。
Authenticator
認証者
Authenticator field, by default constructed with First (128, HMAC_SHA1 (KRm, Protected Data)).
Authenticatorフィールド、デフォルトでは最初の（128、hmac_sha1（KRM、保護されたデータ））で構築されました。
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),
o UDPペイロード（つまり、登録要求または登録返信データ）、
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 この拡張機能のタイプ、長さ、Home Nonce Index、およびCare-of Nonceインデックス。
The Care-of Address Extension is added to a Registration Reply sent by the CR to inform the MR of the upcoming tunnel endpoint.
CRがCRから送信した登録返信にCARE-of Address拡張機能が追加され、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 | 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.
優先順位の順に、MRとのトンネルに使用できる住所のケア（ES）。より高速なNATトラバーサル処理を容易にするために、複数のCOAをリストすることができます。
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.
このスキップ不可能な拡張機能は、登録返信メッセージでHAによってMRに送信される場合があります。この拡張機能は、登録要求メッセージでMRによって明示的に要求された場合にのみ含まれ、モバイルルータールート最適化機能拡張機能の「R」フラグを設定します。プレフィックスの暗黙の優先順位付けは、拡張順序によって引き起こされます。
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またはネットワークプレフィックスのいずれかで構成されている場合があります。HOA氏に続くネットワークプレフィックスは、そのMRが所有しています。HOA氏は最初にシーケンスでなければなりません。なぜなら、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 | 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はプレフィックスを含む最初の情報構造でゼロでなければなりません。ゼロまたは後続の情報構造で1つになる場合があります。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に設定する必要があります。M= 1の場合、「D」ビットがゼロに設定され、受信時に無視されます。
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).
このフィールドは、「M」ビットが設定されているかどうかに応じて、異なる方法で解釈されます。M = 0の場合、フィールドはPLENフィールドと見なされ、内容は宣伝されたプレフィックスの長さを示します。6ビットは0から63の値を可能にし、そのうち33-63は違法です。m = 1の場合、フィールドは情報フィールドと見なされます。許容値は0であるため、特定の情報を示さないか、「アウトバウンド接続のみ」を示す1です。これは、ターゲットMRがその界面のいずれかの接続を受け取ることができず、受信しないことを示しています（HAへの逆トンネルを除く）。これは、MRがモバイルルータールート最適化機能拡張機能（セクション5.1）の「O」フラグを介して明示的に要求した場合に設定されます。
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.
モバイルルーターのホームアドレス。このMRによってm = 0が維持されている次の情報構造のすべてのプレフィックス。このフィールドは、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（およびそれはゼロ）から始まる最も重要でないビットは省略されています。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手順を実行するときにMRからCRに送信されます。ソースおよび宛先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
ホームスティッククッキー
64-bit field that contains a random value, the Home Init Cookie.
ランダムな値を含む64ビットフィールド、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手順を実行するときにMRからCRに送信されます。ソースおよび宛先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
Care-of in sit cookie
64-bit field that contains a random value, the Care-of Init Cookie.
ランダムな値、Care-of Init Cookieを含む64ビットフィールド。
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.
このメッセージは、ホームテストINITメッセージへの返信としてRR手順を実行するときに、CRからMRに送信されます。ソースおよび宛先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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 26
タイプ26
Reserved Set to zero; MUST be ignored on reception.
ゼロに予約されたセット。レセプションで無視する必要があります。
Nonce Index
NonCeインデックス
This field will be echoed back by the MR to the CR in a subsequent Registration Request's authentication extension.
このフィールドは、その後の登録リクエストの認証拡張機能で、MRによってCRに反映されます。
Home Init Cookie
ホームスティッククッキー
64-bit field that contains a random value, the Home Init Cookie.
ランダムな値を含む64ビットフィールド、Home init cookie。
Home Keygen Token
ホームキーゲントークン
This field contains the 64-bit home keygen token used in the RR procedure. Generated from cookie + nonce.
このフィールドには、RR手順で使用される64ビットホームKeygenトークンが含まれています。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手順を実行するときにCRからMRに送信されます。テストinitのケアイニシ様メッセージへの返信として。ソースおよび宛先IPアドレス、およびUDPポートは、このメッセージが構築されているテストCare init 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
Care-of NonCEインデックス
This field will be echoed back by the MR to the CR in a subsequent Registration Request's authentication extension.
このフィールドは、その後の登録リクエストの認証拡張機能で、MRによってCRに反映されます。
Care-of Init Cookie
Care-of in sit cookie
64-bit field that contains a random value, the Care-of Init Cookie.
ランダムな値、Care-of Init Cookieを含む64ビットフィールド。
Care-of Keygen Token
ケアオブキーゲントークン
This field contains the 64-bit care-of keygen token used in the RR procedure. Generated from cookie + nonce.
このフィールドには、RR手順で使用されている64ビットのCare-of Keygenトークンが含まれています。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デバイスまたはステートフルファイアウォールの後ろに位置するMRSと連携できます。さらに、HAは、NATデバイスがモバイルノードとHAの間にあるかどうかを検出する場合もあります。MRはまた、すべてのインターフェイスのNATまたはファイアウォールの背後にあることを明示的に述べている可能性があり、この情報は、ルート最適化アドバタイズメントエクステンション（セクション5.5）の情報フィールドで他のMRSに渡されます。HAはまた、NATを検出し、ルート最適化応答の「N」フラグを介して登録MRに通知する場合があります（セクション5.2）。1つまたは両方のルーターが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.
HAとの通信とは異なり、ルート最適化の場合、シグナリングに使用されるパスはトンネルパケットには使用されません。シグナリングは常にHOAを使用し、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
MRSはいくつかの異なるネットワークに接続する複数のインターフェイスを持っている可能性があるため、特定のネットワークから取得した特定のCOAペアを使用して、特定のMRSの最適化のみを実行できる可能性があります。たとえば、2人のMRSがインターフェイスを持っている場合。同じナットの後ろ。同様のケースがあるかもしれません
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.
ネストされたNATに適用できます。そのような場合、MRは、登録を実行し、各COAが登録回答のケアの拡張にリストされている各COAでトンネル（Keepalivesの送信）を確立しようとすることにより、適格なCOAペアを検出しようとすることができます。適格なペアは、ルート最適化キャッシュに記録する必要があります。COASでトンネルを確立できない場合、MRは代替インターフェイスで手順を繰り返しようとします。ネットワークトポロジに関する上記の情報は、静的または外部フィードバックメカニズムを介してMRSで構成することもできます。
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からHOASに送信されるため、これはシグナルの観点から問題を引き起こしません。したがって、受信者は常にリクエストを受け取り、返信を送信できます。これは、MRとCRの両方が同時に切断される侵入前の状況でも適用されます - 接続性が復元されると、シグナリングメッセージの1つのエンドポイントは常にそれぞれのルーターのHOAであり、それはアップしています到達可能性を提供するために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.
夫人は、HAの支援なしにルートの最適化を交渉して実行できます。お互いの存在を発見し、登録メッセージを送信する場所を知っている場合。このドキュメントは、ネットワークプレフィックス情報をMRSに配布する論理的に単一の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.
Routeの最適化が別々のノードに添付されている間に必要な場合、いくつかの可能性があります。仮想ルーター冗長プロトコル（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.
HASまたはDNS SRVレコードの間の新しい発見/プロービングプロトコルまたはルーティングプロトコル、または共通の認証、承認、および会計（AAA）アーキテクチャなど、別々のHASに接続されたMRの間のルート最適化を達成するためのいくつかの可能性があります。HAがAAAから情報を取得するためのフレームワークがすでにあるため、最も実行可能な可能性と見なすことができます。メソッドを一般化する可能性のある方法については、セクション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がそれぞれMRS AとBによって処理される場合を検討してください。ルーターがルート最適化キャッシュのネットワークプレフィックスに運命づけられたパケットを転送しているときにルート最適化がトリガーされるような方法でルーターが設定されている場合、ネットワークのノードが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.
A氏は、ネットワークBに向けられたローカルネットワークからの着信ICMPエコーリクエストパケットを見ています。ネットワークBはAのルート最適化キャッシュに存在するため、ルート最適化プロセスがトリガーされます。元のパケットは、通常どおり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.
A氏はRR手順とB氏との登録を完了します。これは、M氏のCRになります。ルーターの間にトンネルが作成されます。M氏はルーティングテーブルを更新し、ネットワーク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へのパケットが直接トンネルを介して送信されるようになりましたが、AからBまでのパケットはHAと逆トンネルを介して送信されます。エコーは、ネットワークBのノードがネットワークAに送信すると、同様の方法でMR Bでのルート最適化をトリガーすると答えます。そのため、B氏は現在、AがAに向かって独自の登録を実行します。B氏は、A氏へのトンネルがすでに存在することに気付き、ルーティングテーブルを更新して、ネットワークAが（既存の）氏を介して到達可能になるようになりました。> M氏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.
このシナリオでは、A氏がB氏からの別のルート最適化プロセス（RRチェックと登録）を待っていない場合、代わりにトンネルを介してルーティングテーブルを更新してネットワークBに到達するだけで、B氏が開始した場合に問題が発生する可能性があります。情報がAに伝播される前に、別のネットワークb 'を管理する最終結果は、M氏が直接トンネルを介してネットワークAからネットワークB'およびネットワークBにネットワーク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.
したがって、この相互登録を実行するかどうかは、状況に依存し、MRSが操作中に追加のネットワークプレフィックスの管理を開始するかどうかに依存します。
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のCOASを学習できるようにする登録手順（オプションの返品ルー上のパーツ）は、厳密に必要ではありません。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を使用するための主要なドライバーは、MRSに他のルーターの知識だけでなく、どのルーターによって管理されているかについての情報をMRSに提供することです。
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.
この設計は、MRS間に最適なパスを作成する可能性を単に提供します。これらのパスを使用してユーザートラフィックがどうあるべきかを決定することはありません。ロードバランスを促進し、利用可能なすべてのパスを利用するのに役立つ1つの可能なアプローチは、[MIPV4Flow]で提示されます。これにより、単一のHOAの複数のCOAが効果的に可能になります。さらに、個別のトンネルに個別の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アーキテクチャに由来しています。トンネル界面を作成、維持、破壊すると、MRSに負荷が発生する可能性があります。ただし、MRSは、リソースの制約が明らかな場合は、常に通常の逆タンネルルーティングに戻ることができます。
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.
次の例では、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.
次の例は、セクション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.
当初、夫人はお互いのKRMを知りません。KRMが他の方法で事前に共有またはプロビジョニングされている場合、返品ルー上のメッセージは省略できます。セクション8.1で説明されているようにシグナリングが発生しました。したがって、A氏は他のネットワークを認識しておらず、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.
このシグナル伝達の例では、M氏はCOAを変更し、A氏とM氏の間のルートの最適化が動作し、データが転送されています。ハンドオーバーが優雅である場合（「休憩前」）、そして不grace（「ブレイク前に」）の両方が同様の方法で発生しますが、優雅なバージョンではパケットが失われないことを除いて。この図は、C氏がリンクのステータス表示により、接続の失われた通知を即座に通知する場合を検討します。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
max_nonce_lifetime 240秒max_token_lifetime 210秒max_update_rate 5回
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登録メッセージへの拡張」にルールを割り当てました。セクション5にリストされているメッセージと拡張機能に対して、新しいモバイルIPメッセージタイプと拡張コードの割り当てが行われました。
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.
3つの新しい登録メッセージ拡張タイプが必要で、表2にリストされています。最初のタイプ153はスキップ可能で、範囲128-255から割り当てられています。他の2つの49と50はスキップできず、範囲0〜127から割り当てられており、49は「短い」形式で、50は「長い」形式です。通知メッセージに対してメッセージは許可されていません。
+--------------+---------------------------------------------+
| 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同時登録（事前accept）
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つの新しい登録返信コードが割り当てられました。以下の表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の割り当てポリシーで作成された3つの新しい数値スペースが必要でした[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.
2つの主要なセキュリティの問題があります。1つの問題はRRチェックに関連しており、特定のCOAが実際に特定のHOAによって管理されることを確立します。もう1つの問題は、任意のネットワークを表すと主張する信頼関係と任意のルーターです。
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 Checkのセキュリティは、モバイルIPv6で吟味されています。接続チェックとリプレイ攻撃保護の2つの問題を除いて、大きな違いはありません。接続チェックは、個別の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.
ホームエージェントアシストルートの最適化における信頼関係のネットワークは、可能な信頼の問題を解決します。arbitrary意的なCRは、arbitrary意的なMRを信頼することができます。
It is assumed that all MRs have a trust relationship with the HA. Thus, they trust information provided by the HA.
すべてのMRSがHAと信頼関係を持っていると想定されています。したがって、彼らはHAから提供された情報を信頼しています。
The HA provides information matching HoAs and network prefixes. Each MR trusts this information.
HAは、HOAとネットワークのプレフィックスに一致する情報を提供します。各氏はこの情報を信頼しています。
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.
夫人は、互いの間で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.
クレームは、HAからのHOA <-->ネットワークプレフィックス情報を確認するか、需要の要求のために受信したネットワークプレフィックス情報を確認することで検証できます。彼らが一致する場合、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).
建設的なコメントとサポートをしてくれたAlexandru Petrescuに感謝します。最初のレビューをしてくれたJyrki SoiniとKari Laihonenに感謝します。この作業は、Tivitの将来のインターネットプログラム（ICTの分野における科学、技術、革新のためのフィンランド戦略センター）の一部としてTekesによってサポートされていました。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004] Perkins、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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.
[RFC3519] Levkowetz、H。およびS. Vaarala、「ネットワークアドレス変換（NAT）デバイスのモバイルIPトラバーサル」、RFC 3519、2003年4月。
[RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, "Network Mobility (NEMO) Extensions for Mobile IPv4", RFC 5177, April 2008.
[RFC5177] Leung、K.、Dommety、G.、Narayanan、V.、およびA. Petrescu、「Mobile 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] Perkins、C.、ed。、「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] Perkins、C。およびD. Johnson、「モバイル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.、Ed。、Leung、K.、Tsirtsis、G.、Soliman、H.、およびA. Petrescu、「モバイル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] Glass、S。およびM. Chandra、「モバイル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] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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] Perkins、C.、ed。、Johnson、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
Antti Makela Aalto University Communications and Networking（COMNET）P.O。Box 13000 Fin-00076 Aalto Finland
EMail: antti.t.makela@iki.fi
Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND
Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo Finland
EMail: jouni.nospam@gmail.com