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
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6521.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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
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中仍有路由优化的特定应用。本文件提出了一种优化移动路由器（MRs）后面网络之间路由的方法，如网络移动性（NEMO）[RFC5177]所定义。尽管NAT和IPv4地址的悬而未决的短缺使得端到端路由优化的广泛部署不可行，但使用
MR to MR is still a practical scenario. Note that the method specified in this document is only for route optimization between MRs; any network prefix not advertised by an MR would still be routed via the home agent, although an MR could advertise very large address spaces, e.g., by acting as an Internet gateway.
MR-to-MR仍然是一种实际情况。请注意，本文件中规定的方法仅适用于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.
从服务提供商的角度来看，企业客户网络的公共拓扑由一到多个站点（通常是总部和各个分支机构）组成。这些站点通常通过各种第2层技术（ATM或帧中继永久虚拟电路（PVC））、MPLS VPN或第3层站点到站点VPN进行连接。通过服务级别协议（SLA），客户可以获得非常可靠且得到良好支持的内部网连接。然而，与“消费者级”宽带互联网接入的成本相比，SLA保证版本可以认为是非常昂贵的。然而，对于任务关键型应用程序来说，这些消费者级选项并不是一种可靠的方法。
Mobile IP, especially MRs, can be used to improve reliability of connectivity even when implemented over consumer-grade Internet access. The customer becomes a client for a virtual service provider, which does not take part in the actual access technology. The service provider has a backend system and an IP address pool that it distributes to customers. Access is provided by multiple, independent, possibly consumer-grade ISPs, with Mobile IP providing seamless handovers if service from a specific ISP fails. The drawback of this solution is that it creates a star topology; all Mobile IP tunnels end up at the service provider-hosted home agent, causing a heavy load at the backend. Route optimization between mobile networks addresses this issue, by taking the network load off of the home agent and the backend.
移动IP，尤其是MRs，可以用于提高连接的可靠性，即使是在消费者级互联网接入上实现。客户成为虚拟服务提供商的客户，而虚拟服务提供商不参与实际的访问技术。服务提供商有一个后端系统和一个IP地址池，可以分发给客户。接入由多个独立的、可能是消费者级的ISP提供，如果特定ISP的服务失败，移动IP提供无缝切换。这种解决方案的缺点是它创建了星形拓扑；所有移动IP隧道最终都位于服务提供商托管的home agent上，导致后端负载沉重。移动网络之间的路由优化通过减轻归属代理和后端的网络负载来解决这个问题。
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 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.
在本例中，组织网络由两个站点组成，出于冗余原因通过两个ISP连接。移动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.
本文档中的规范是实验性的，其主要设计目标是将后端的负载保持在最低限度。其他设计目标包括扩展到更广泛的范围，例如不要求所有mr都驻留在同一归属代理上。主要寻求的经验涉及对现实世界操作的适用性，以及特定于协议的问题，如信令可伸缩性、与其他移动IP扩展的互通，以及最终用户应用程序在路由优化路径上的行为。
The aforementioned use case is the original application. Moving this specification to Standards Track should be considered after enough deployment experience has been gathered. Besides the aforementioned issues, additional elements that might require refinement based on real-world experiences are delivery of information on networks managed by peer MRs; conducting MR <-> MR authentication; reaction to, and recovery methods for, connectivity breakdowns and other break-before-make topology changes; keepalive timer intervals; formats of signaling extensions; behavior in NAT/firewalled environments; and the prefix and realm compression algorithms.
上述用例是原始应用程序。在收集了足够的部署经验之后，应考虑将此规范转移到标准轨道。除上述问题外，可能需要根据实际经验进行改进的其他因素包括在对等MRs管理的网络上传递信息；进行MR<->MR认证；在进行拓扑更改之前，对连接中断和其他中断的反应和恢复方法；保持定时器间隔；信令扩展的格式；NAT/防火墙环境中的行为；以及前缀和领域压缩算法。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Care-of Address (CoA)
转交地址（CoA）
RFC 5944 [RFC5944] defines a care-of address as the termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it is away from home. The protocol can use two different types of CoA: a "foreign agent care-of address", which is an address of a foreign agent with which the mobile node is registered, and a "co-located care-of address", which is an externally obtained local address that the mobile node has associated with one of its own network interfaces. However, in the case of Network Mobility, foreign agents are not used, so no foreign CoAs are used either.
RFC 5944[RFC5944]将转交地址定义为朝向移动节点的隧道的终止点，用于在移动节点离家时转发到移动节点的数据报。该协议可以使用两种不同类型的CoA：“外部代理转交地址”，它是移动节点注册的外部代理的地址，以及“共同定位转交地址”，它是移动节点与自己的网络接口之一关联的外部获得的本地地址。然而，在网络移动性的情况下，不使用外部代理，因此也不使用外部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，其也可以表示一个或多个整个网络。
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地址。无论节点连接到Internet的位置如何，它都保持不变。
Home Agent (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.
主机网络前缀是掩码为/32的网络前缀，例如192.0.2.254/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]将移动路由器定义为移动节点，移动节点可以是负责一个或多个整体网络移动的路由器，这些网络可能在飞机、轮船、火车、汽车、自行车或皮划艇上一起移动。
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维护的数据结构，其中包含路由优化的可能目的地。缓存包含关于潜在CRs及其相关移动网络的信息（HOA）。
Return Routability (RR)
返回路由性（RR）
Return routability is defined as a procedure to bind an MR's HoA to a CoA on a CR with a degree of trust.
返回路由性定义为一种程序，以一定程度的信任将MR的HoA绑定到CR上的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.
本规范中的一些公式使用符号“|”表示字节连接，如在A | B中。这种连接要求数据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.
本规范中的一些公式使用函数形式“First（size，input）”来表示“input”数据的截断，以便只保留第一个“size”位。
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上的前缀<->MR映射信息不同，该信息现在也将分发给其他MR。
Home agent-assisted route optimization is primarily intended for helping to optimize traffic patterns between multiple sites in a single organization or administrative domain; however, extranets can also be reached with optimized routes, as long as all MRs connect to the same HA. The procedure aims to maintain backward compatibility; with legacy nodes or routers, full connectivity is always preserved, even though optimal routing cannot be guaranteed.
Home agent辅助路由优化主要用于帮助优化单个组织或管理域中多个站点之间的流量模式；但是，只要所有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能够接收来自其他未经请求的MR的消息——也就是说，无需首先发起请求。这种行为——接受未经请求的消息——类似于注册撤销过程[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可以请求关于路由优化网络前缀的信息。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的网络前缀信息的重新分配仅在注册信令期间发生。医管局不会提供任何“路由更新”，除非在由交接、注册超时和特定请求触发的重新注册期间。如果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.
当医管局收到注册申请时，会进行标准的认证和授权程序。
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节），以表明已理解路由优化能力扩展。此外，扩展还通知MR是否使用RFC 3519[RFC3519]中的过程在HA和MR之间检测到NAT，该过程基于请求者的指示CoA和分组的源地址之间的差异。
The reply message MAY also include one Route Optimization Prefix Advertisement Extension, which informs the MR of existing mobile network prefixes and the MRs that manage them, if eligible for redistribution. The networks SHOULD be included in order of priority, with the prefixes determined, by policy, as most desirable targets for route optimization listed first. The extension is constructed as shown in Section 5.5. The extension consists of a list where each MR, identified by its HoA, is listed with corresponding prefix(es) and their respective realm(s).
回复消息还可包括一个路由优化前缀广告扩展，其通知MR现有移动网络前缀和管理它们的MR（如果符合重新分配的条件）。网络应按优先顺序包括，前缀由策略确定，作为路由优化的最理想目标首先列出。扩建部分的构造如第5.5节所示。扩展包括一个列表，其中每个MR（由其HoA标识）都列出了相应的前缀及其各自的领域。
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.
每个网络前缀都可以与域[RFC4282]相关联，通常以“organization.example.com”的形式。除了客户自己组织中的路由器之外，前缀列表还可以包括其他mr，例如，指向用于因特网连接的因特网网关的默认前缀（0.0.0.0/0）或属于可能的外联网的附加前缀。领域信息可用于对MR作出决策，例如仅在特定领域内进行优化。此外，唯一领域信息可用于区分相同或不同组织同时使用的重叠地址空间，并相应地调整转发策略。
In a typical scenario, where network prefixes are allocated to MRs connecting to a single HA, the prefixes are usually either continuous or at least very close to each other. Due to these characteristics, an optional prefix compression mechanism is provided. Another optional compression scheme is in use for realm information, where realms often share the same higher-level domains. These compression mechanisms are further explained in Section 4.
在典型场景中，网络前缀分配给连接到单个HA的MRs，前缀通常是连续的，或者至少彼此非常接近。由于这些特性，提供了可选的前缀压缩机制。另一个可选的压缩方案用于领域信息，其中领域通常共享相同的高级域。第4节将进一步解释这些压缩机制。
Upon receiving a Registration Reply with a Route Optimization Prefix Advertisement Extension, the MR SHALL insert the MR HoAs included in the extension as host-prefixes to the local Route Optimization Cache if they do not already exist. If present, any additional prefix information SHALL also be inserted into the Route Optimization Cache.
在收到带有路由优化前缀广告扩展的注册回复后，MR应将扩展中包含的MR HOA作为主机前缀插入本地路由优化缓存（如果它们不存在）。如果存在，任何附加前缀信息也应插入路由优化缓存。
The MR MAY discard entries from a desired starting point onward, due to memory or other policy-related constraints. The intention of listing the prefixes in order of priority is to provide implicit guidance for this decision. If the capacity of the device allows, the MR SHOULD use information on all advertised prefixes.
由于内存或其他与策略相关的限制，MR可能会从所需的起点开始丢弃条目。按优先顺序列出前缀的目的是为这一决定提供隐含的指导。如果设备容量允许，MR应使用所有广告前缀的信息。
MRs supporting route optimization will maintain a Route Optimization Cache.
支持路由优化的MRs将维护路由优化缓存。
The Route Optimization Cache contains mappings between potential CR HoAs, network(s) associated with each HoA, information on reachability related to NAT and other divisions, and information related to the RR procedure. The cache is populated based on information received from the HA in Route Optimization Prefix Advertisement Extensions and in registration messages from CRs. Portions of the cache may also be configured statically.
路由优化缓存包含潜在CR HoA之间的映射、与每个HoA关联的网络、与NAT和其他分区相关的可达性信息以及与RR过程相关的信息。缓存基于从HA接收到的路由优化前缀广告扩展和来自CRs的注册消息中的信息填充。缓存的部分也可以静态配置。
The Route Optimization Cache contains the following information for all known CRs. Note that some fields may contain multiple entries. For example, during handovers, there may be both old and new CoAs listed.
路由优化缓存包含所有已知CR的以下信息。请注意，某些字段可能包含多个条目。例如，在切换期间，可能会同时列出旧的和新的CoA。
CR-HoA
华润
Correspondent router's home address. Primary key identifying each CR.
通讯路由器的家庭地址。标识每个CR的主键。
CR-CoA(s)
华润商用飞机有限公司(s)
Correspondent router's care-of address(es). May be empty if none known. Potential tunnel's destination address(es).
对应路由器的转交地址。如果未知，则可能为空。潜在隧道的目标地址。
MR-CoA
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
纳特州
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 CoA和CR CoA对的条目。该表可以静态填充，也可以基于操作期间接收到的信息填充。设置为true表示MR可以使用这对coa建立朝向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，设置为false。此表中的设置会影响隧道的建立方向；在决定在注册回复中的转交地址扩展中包括哪些CoA时，请参见第3.3.4节和注册程序。条目的存在要求使用UDP封装。
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对的可路由性状态。状态为非活动、进行中和活动。如果状态为INACTIVE，则必须在转发路由优化流量之前完成RR过程。如果状态为“进行中”或“活动”，则只要建立到CR的隧道，就不能从路由优化缓存中删除有关此CR的信息。
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过程计算的，则根据nonce和路由器密钥就地计算。如果静态配置，RRSTATE将永久设置为活动。
Care-of nonce indices
关心临时指数
If the KRm was established with the RR procedure, contains the care-of nonce index for each MR-CoA - CR-HoA pair.
如果KRm是通过RR程序建立的，则包含每个MR CoA-CR HoA对的nonce护理指数。
Care-of keygen token
保管keygen代币
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 keygen token
主密钥生成令牌
If the KRm was established with the RR procedure, contains the home keygen token for each CR-HoA.
如果使用RR程序建立KRm，则包含每个CR HoA的home keygen令牌。
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。始终至少包含一个条目：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
前缀_有效
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。除了RR过程之外，由CR本身组成的主机网络前缀不需要验证。至于其他字头,则会向医管局索取资料,以作确认。具有未确认所有权的前缀的流量不应通过隧道路由。
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绑定。[RFC6275]中描述了移动IPv6的RR过程。同样的原则也适用于移动IPv4版本：向CR的HoA发送两条消息——一条通过HA使用MR的HoA，另一条直接从MR的CoA发送，两条响应通过相同的路由。注册管理密钥来自这些消息上携带的令牌信息。然后可以使用此注册管理密钥（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过程是移动IP提供的一种方法，用于以相对轻量级的方式建立KRm。如果需要，可以在MRs上静态配置KRM，或者使用所需的外部安全密钥提供机制。如果MRs通过其他机制知道KRM，则可以跳过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的反向隧道接收这些消息；因此，在向HA注册期间，任何关于CR连接的问题都会得到解决。
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过程由四条移动IP消息组成：Home Test Init（HoTI）、Care of Test Init（CoTI）、Home Test（HoT）和Care of Test（CoT）。其构造如第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 init cookie、当前home nonce索引和home keygen令牌。CoT消息包含一个care of init cookie、当前care of nonce索引和care of keygen令牌。
The home keygen token is constructed as follows:
home keygen令牌的构造如下所示：
Home keygen token = First (64, HMAC_SHA1 (Kcr, (home address | nonce | 0)))
家庭密钥生成令牌=第一个（64，HMAC|U SHA1（Kcr，（家庭地址| nonce | 0）））
The care-of keygen token is constructed as follows:
密钥保管令牌的构造如下：
Care-of keygen token = First (64, HMAC_SHA1 (Kcr, (care-of address | nonce | 1)))
密钥保管令牌=第一（64，HMAC|U SHA1（Kcr，（保管地址| 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消息以获取新的密钥代保管令牌；home keygen令牌可能仍然有效。如果对注册的回复表明一个或两个令牌已过期，则必须将RRSTATE设置为INACTIVE。然后，可根据需要重新启动RR程序。
Upon completion of the RR procedure, the Route Optimization Cache's RRSTATE field is set to ACTIVE, allowing for Registration Requests to be sent. The MR will establish a KRm. By default, this will be done using the SHA1 hash algorithm, as follows:
完成RR过程后，Route Optimization Cache的RRSTATE字段设置为ACTIVE（活动），允许发送注册请求。MR将建立KRm。默认情况下，这将使用SHA1哈希算法完成，如下所示：
KRm = SHA1 (home keygen token | care-of keygen token)
KRm=SHA1（主密钥代币|密钥代币照管）
When de-registering (by setting the Registration Request's lifetime to zero), the care-of keygen token is not used. Instead, the KRm is generated as follows:
在取消注册时（通过将注册请求的生存期设置为零），不使用密钥保管令牌。相反，KRm的生成如下所示：
KRm = SHA1 (home keygen token)
KRm=SHA1（主密钥生成令牌）
As in Mobile IPv6, the CR does not maintain any state for the MR until after receiving a Registration Request.
与在移动IPv6中一样，CR在收到注册请求之前不会保持MR的任何状态。
Each MR maintains a Kcr, which MUST NOT be shared with any other entity. The Kcr is used for authenticating peer MRs in the situation where an MR is acting as a CR. This is analogous to the node key (Kcn) in Mobile IPv6. A CR uses its router key to verify that the keygen tokens sent by a peer MR in a Registration Request are the CR's own. The router key MUST be a random number, 16 octets in length, generated with a good random number generator [RFC4086].
每个MR都有一个九广铁路，不得与任何其他实体共享。在MR充当CR的情况下，Kcr用于认证对等MRs。这类似于移动IPv6中的节点密钥（Kcn）。CR使用其路由器密钥验证对等MR在注册请求中发送的keygen令牌是CR自己的。路由器密钥必须是一个随机数，长度为16个八位字节，由一个好的随机数生成器生成[RFC4086]。
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可以随时生成新密钥以避免持久密钥存储。如果需要，建议密钥与nonce一起过期；见第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还维护一个或多个索引的nonce。应使用良好的随机数生成器定期生成nonce[RFC4086]。MR可以与所有MRs使用相同的nonce。nonce可以是任何长度，推荐长度为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类似。MRs保留当前nonce和一小组有效的前一个nonce，其生存期尚未过期。在首次用于构造RR响应后，nonce应至少在MAX_TOKEN_生存时间秒（参见第9节）内保持有效。但是，CR不得接受首次使用后超过最大使用寿命秒（见第9节）的NONCE。由于这两个常量之间的差异为30秒，因此强制执行上述生命周期的一种方便方法是每30秒生成一个新的nonce。然后，节点可以继续接受基于最后8个（MAX_NONCE_life/30）NONCE的keygen令牌。这导致keygen令牌在被发送到移动节点后的MAX_TOKEN_life到MAX_NONCE_life秒是可接受的，这取决于令牌是在前30秒周期的开始还是结束时发送的。请注意，对应节点还可以尝试按需生成新的nonce，或者仅当使用了旧的nonce时。只要对应节点跟踪第一次使用nonce的时间，并且不在每个返回可路由性请求上生成新的nonce，这是可能的。
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和nonce。
This section deals with the operation of mobile and correspondent routers performing route optimization. Note that in the context of this document, all routers work as both MR and CR. The term "mobile router" applies to the router initiating the route optimization procedure, and "correspondent router" indicates the peer router.
本节介绍执行路由优化的移动和对应路由器的操作。请注意，在本文件的上下文中，所有路由器均作为MR和CR工作。术语“移动路由器”适用于启动路由优化过程的路由器，“对应路由器”表示对等路由器。
There are two issues regarding IPv4 that are different when compared to Mobile IPv6 route optimization. First of all, since Mobile IPv4 always uses tunnels, there must be a tunnel established between the MR's and the CR's CoAs. The CR learns of the MR's CoA, because it is included in the Registration Request. The MR learns the CR's CoA via a new extension, "Care-of Address", in the Registration Reply. The second issue is a security consideration: In a Registration Request, the MR claims to represent an arbitrary IPv4 network. If the CR has not yet received this information (HoA <-> network prefix), it SHOULD perform a re-registration with the HA to verify the claim.
与移动IPv6路由优化相比，IPv4有两个不同的问题。首先，由于移动IPv4始终使用隧道，因此必须在MR和CR的COA之间建立隧道。CR了解MR的CoA，因为它包含在注册请求中。MR通过注册回复中的新扩展“转交地址”了解CR的CoA。第二个问题是安全考虑：在注册请求中，MR声称代表任意IPv4网络。如果CR尚未收到此信息（HoA<->网络前缀），则应向HA重新注册以验证索赔。
An additional aspect is that the MR MAY use a different CoA for different CRs (and the HA). This is useful in situations where the network provides only partial-mesh connectivity and specific interfaces must be used to reach specific destinations. In addition, this allows for load balancing.
另一个方面是，MR可以对不同的CR（和HA）使用不同的CoA。这在网络仅提供部分网状连接且必须使用特定接口才能到达特定目的地的情况下非常有用。此外，这允许负载平衡。
Since each MR knows the eligible route-optimizable networks, the route optimization between all CRs can be established at any time; however, a better general practice is to conduct route optimization only on demand. It is RECOMMENDED that route optimization be started only when sending a packet that originates from a local managed network (and if the network is registered as route optimizable) and whose destination address falls within the network prefixes of the Route Optimization Cache. With a small number of MRs, such on-demand behavior may not be necessary, and full-mesh route optimization may be in place constantly.
由于每个MR都知道合格的路由优化网络，因此可以随时建立所有CR之间的路由优化；但是，更好的一般做法是仅根据需求进行路线优化。建议仅当发送来自本地管理网络（并且如果网络注册为可路由优化）且其目的地址位于路由优化缓存的网络前缀内的数据包时，才启动路由优化。对于少量的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具有一个或多个到本地网络的接口、一个或多个到广域网的接口（如ISP提供的接口）以及到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的HOA路线也应指向使用优化路径的各自隧道。
If two prefixes overlap each other, e.g., 192.0.2.128/25 and 192.0.2.128/29, the standard longest-match rule for routing is in effect. However, overlapping private addresses SHOULD be considered an error situation. Any aggregation for routes in private address space SHOULD be conducted only at the HA.
如果两个前缀相互重叠，例如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节），或者必须在MR和CR之间预先共享KRm。如果任一条件适用，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封装。建议始终使用UDP封装，以便通过keepalive机制检测路径故障。
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索引到期，MR将CR的RRSTATE设置为INACTIVE。然后可再次启动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”标志均为true）。请注意，视点始终是局部的；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应向HA发送一个设置了“S”（请求）位的重新注册请求，从而获得由传入MR管理的网络前缀的最新信息。如果即使在此更新之后，前缀仍然不匹配，则应答的移动网络确认码必须设置为“未经授权的移动网络”“。注册亦可被完全拒绝。进行此验证是为了防止MRs声称代表任意网络；然而，由于假设医管局提供可信的信息，它可以授权MR的索赔。如果环境本身被认为是可信的，则作为一项策略，CR可以在不进行此检查的情况下接受注册；但是，不建议将其作为一般做法。
If the prefixes match, the CR MAY accept the registration. If the CR chooses to accept, the CR MUST check to determine if a tunnel to the MR already exists. If the tunnel does NOT exist or has wrong endpoints (CoAs), a new tunnel MUST be established and the Route Optimization Cache updated. The reply MUST include a list of eligible CoAs (see Section 5.4) with which the MR may establish a tunnel. The reply MUST also include the Mobile-Correspondent Authentication Extension (see Section 5.3).
如果前缀匹配，CR可以接受注册。如果CR选择接受，CR必须检查以确定MR的隧道是否已经存在。如果隧道不存在或具有错误的端点（COA），则必须建立新的隧道并更新路由优化缓存。答复必须包括一份合格的COA列表（见第5.4节），MR可使用该列表建立隧道。回复还必须包括移动通讯员认证扩展（见第5.3节）。
Upon receiving the Registration Reply, the MR MUST check to determine if a tunnel to the CR already exists. If the tunnel does NOT exist or has wrong endpoints (CoAs), a new tunnel MUST be established and the Route Optimization Cache updated. This is covered in detail in Section 3.3.4.
收到注册回复后，MR必须检查以确定通往CR的隧道是否已经存在。如果隧道不存在或具有错误的端点（COA），则必须建立新的隧道并更新路由优化缓存。第3.3.4节详细介绍了这一点。
The CR's routing table MUST be updated to indicate that the MR's networks are reachable via the direct tunnel to the MR.
CR的路由表必须更新，以表明MR的网络可以通过直接隧道到达MR。
After the tunnel is established, the MR MAY update its routing tables to reach all of the CR's Prefixes via the tunnel, although it is RECOMMENDED that time be given for the CR to perform its own, explicit registration. This is primarily a policy decision, depending on the network environment. See Section 6.5.
在隧道建立之后，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
由于路由优化过程可能同时发生在两个mr处，每个mr作为彼此的CR工作，因此可能存在两个路由器试图同时在它们之间建立单独的隧道的情况。如果具有较小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间隧道的建立是在向医管局建立标准反向隧道之后进行的。对CR的注册请求包括关于所需封装的信息。建议使用UDP封装。在通用路由器封装（GRE）[RFC2784]、IP over 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的隧道起始点是其CoA，而不是发送注册请求的HoA。这与创建到HA的反向隧道不同，后者重用来自注册信令的信道。
Special considerations rise from using UDP encapsulation, especially in cases where one of the MRs is located behind a NAT or firewall. A deviation from RFC 3519 [RFC3519] is that keepalives should be sent from both ends of the tunnel to detect path failures after the initial keepalive has been sent -- this allows both the MR and CR to detect path failures.
使用UDP封装会引起特殊的注意事项，特别是在其中一个MRs位于NAT或防火墙后面的情况下。与RFC 3519[RFC3519]的一个偏差是，在发送初始keepalive之后，应该从隧道两端发送keepalive以检测路径故障——这允许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保持期。如果没有收到对初始保留的回复，MR可以选择尝试将保留发送到注册回复提供的其他CoA，以检查它们是否提供更好的连接；或者，如果所有这些都失败了，MR可以通过替代接口执行重新注册，或者完全取消注册。见第6.1节。一旦初始keepalive数据包到达CR并且发送了应答，CR就可以开始发送其自己的keepalive。
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.
每秒最大更新次数。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”的名称仅适用于初始隧道建设阶段。一旦在两个路由器之间建立了隧道，它们中的任何一个都可以选择拆除隧道或执行切换。信令消息必须使用有效的KRm进行身份验证。
All packets received by the MR are forwarded using normal routing rules according to the routing table. There are no special considerations when constructing the packets; the tunnel interface's own processes will encapsulate any packet automatically.
MR接收到的所有数据包根据路由表使用正常路由规则进行转发。在构造数据包时没有特殊考虑；隧道接口自己的进程将自动封装任何数据包。
Handovers and connection breakdowns can be categorized as either ungraceful or graceful, also known as "break-before-make" (bbm) and "make-before-break" (mbb) situations.
切换和连接中断可以分为不正常或正常两类，也称为“先断后接”（bbm）和“先接后断”（mbb）。
As with establishment, the "mobile router" discussed here is the router wishing to change connectivity state, with the "correspondent router" being the peer.
与建立时一样，这里讨论的“移动路由器”是希望改变连接状态的路由器，“对应路由器”是对等路由器。
When an MR wishes to join its home link, it SHOULD, in addition to sending the Registration Request to the HA with lifetime set to zero, also send such a request to all known CRs, to their HoAs. The CR(s), upon accepting this request and sending the reply, will check whether the Route Optimization Cache contains any prefixes associated with the requesting MR. These entries should be removed and the routing table updated accordingly (traffic for the prefixes will be forwarded via the HA again). The tunnel MUST then be destroyed. A short grace period SHOULD be used to allow possible in-transit packets to be received correctly.
当MR希望加入其home link时，除了将注册请求发送给HA并将生存期设置为零外，还应将该请求发送给所有已知的CR及其HOA。CR在接受此请求并发送回复后，将检查路由优化缓存是否包含与请求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的数据包。在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发送的初始keepalive消息将验证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无法在移交前发送重新注册请求，则必须在移交完成并与医管局建立隧道后立即发送。由于更改CoA会使KRm失效，因此建议通过通过新CoA发送CoTI消息并获得新的keygen care令牌来实现部分返回路由能力。在所有情况下，如果现有代币已过期，还必须获得必要的代币。
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:
考虑三个移动网络A、B和C的情况，分别由三个移动路由器A先生、B先生和C先生处理。如果他们按此顺序向医管局登记，情况如下：
MR A registers and receives no information on other networks from the HA, as no other MR has registered yet.
A先生没有登记，也没有从医管局收到关于其他网络的信息，因为还没有其他先生登记。
MR B registers and receives information on mobile network A being reachable via MR A.
mrb在移动网络A上注册并接收可通过mra访问的信息。
MR C registers and receives information on both of the other mobile networks.
mrc在其他两个移动网络上注册和接收信息。
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发送业务，则路由优化是直接的；mrc的路由优化缓存中已经有一个网络。因此，包传输触发朝向MR 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.
向MR A注册（RR过程完成后），MR A没有关于移动网络C的信息；因此，它将根据需要向医管局重新注册。这允许MR A验证MR C确实在管理网络C。
If a node in mobile network B sends traffic to mobile network C, MR B has no information on network C. No route optimization is triggered. However, when the node in network C replies and the reply reaches MR C, route optimization happens as above. Further examples of signaling are in Section 8.
如果移动网络B中的节点向移动网络C发送流量，则MR B没有关于网络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。有关多个HA的可能性，请参见第6.4节。
This section defines the two compression formats used in Route Optimization Prefix Advertisement Extensions.
本节定义路由优化前缀广告扩展中使用的两种压缩格式。
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，“Prefix”字段中接下来的是新主前缀的位1..n，其中n是PLen。这四舍五入到最接近的完整八位字节。因此，/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，“Prefix”字段中接下来的是前缀的位m..PLen，其中m是前一个主前缀的第一个更改位，从主前缀填充字段到完整的八位字节。PLen-m的最大值是8（也就是说，增量必须适合一个八位组）。如果不可能，则必须声明新的主前缀。如果前缀相等——例如，在同一前缀出现在多个领域的情况下——那么一个八位组仍然被编码，完全由主前缀的填充组成。
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:
压缩和传输数据的示例如图1所示，其中传输网络前缀192.0.2.0/28、192.0.2.64/26和192.0.2.128/25。由于填充到完整的八位字节，所以也会发送冗余信息。正在传输的位模式如下所示：
=+= shows the prefix mask
--- shows the master prefix for delta coded prefixes
192.0.2.0/28, D = 0
=+= 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|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|.|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 -+
0 1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-------------------------------------------------------------+-+-+-+-+
|1|1|0|0|0|0|0|0|.|0|0|0|0|0|0|0|0|.|0|0|0|0|0|0|1|0|.|1|0|0|0|0|0|0|0|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+-+-+-+-+-+-+-+
^ ^
+--- encoded ---+
^ ^
+- padding -+
Figure 1: Prefix Compression Example
图1：前缀压缩示例
The first prefix, 192.0.2.0/28, is considered a master prefix and is transmitted in full. The PLen of 28 bits determines that all four octets must be transmitted. If the prefix would have been, e.g., 192.0.2.0/24, three octets would have sufficed, since 24 bits fit into 3 octets.
第一个前缀192.0.2.0/28被视为主前缀，并被完整传输。28位的PLen确定必须传输所有四个八位字节。如果前缀是，例如192.0.2.0/24，则三个八位字节就足够了，因为24位适合三个八位字节。
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 |
+----------------+--------+-+---------------------+
+----------------+--------+-+---------------------+
| 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视为主前缀，而将其他前缀视为增量，则生成的编码仍然适合后续前缀的一个八位字节。不需要声明新的主前缀。
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.
为了减少消息的大小，系统引入了领域压缩方案，该方案减少了消息中领域的大小。压缩方案是一种简单的基于字典的动态更新算法，用于压缩任意长度的文本字符串。在此方案中，整个领域、单个标签或标签列表可以替换为字典中存储的相同字符串的上一次出现的索引。本规范中定义的领域压缩源于RFC1035[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.
压缩领域时，首先重置字典，它不包含单个字符串。域是一个接一个地处理的，因此算法不希望一次看到所有域或整个消息。压缩器的状态是字典的当前内容。领域被一个标签一个标签地压缩，或者作为标签列表进行压缩。字典最多可容纳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:
字典索引的编码或代表单个标签的未压缩八位字节的编码特意变得简单，并且整个编码工作在八位字节粒度上。未压缩标签的编码采用一个八位字节的形式，如下所示：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
|0| LENGTH | 'length' octets long string.. |
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
|0| LENGTH | 'length' octets long string.. |
+-+-+-+-+-+-+-+-+-+-+-+-=================-+-+-+-+
This encoding allows label lengths from 1 to 127 octets. A label length of zero (0) is not allowed. The "label length" tag octet is then followed by up to 127 octets of the actual encoded label string.
这种编码允许标签长度从1到127个八位字节。标签长度不允许为零（0）。“标签长度”标签八位位组之后是实际编码标签字符串的127个八位位组。
The index to the dictionary (the "label index" tag octet) takes the form of one octet as follows:
字典索引（“标签索引”标记八位字节）采用一个八位字节的形式，如下所示：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| INDEX |
+-+-+-+-+-+-+-+-+
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.
压缩输入域时，将在字典中搜索匹配的字符串。如果找不到匹配项，则从所用输入域的右侧删除最后一个标签。重复搜索，直到处理完整个输入域。如果根本没有找到匹配项，则使用“label length”标记对原始输入域的第一个标签进行编码，并将标签插入字典中。对输入域的其余部分（如果有）重复前面描述的搜索。如果没有剩余内容，则域编码完成。
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.
当在字典中找到匹配字符串时，使用“label index”标记对输入域的匹配部分进行编码。将删除输入域的匹配部分，并使用输入域的其余部分（如果有）重复搜索。如果没有剩余内容，则插入八位组值零（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.
搜索算法还为每个输入域维护“最长的不匹配字符串”。每次字典中的搜索失败，并且使用“label length”标记对新标签进行编码并插入字典时，“最长的非匹配字符串”由该标签连接，包括分隔符“.”（点，即十六进制0x2e）。当在字典中找到匹配项时，“最长的不匹配字符串”被重置（即清空）。一旦对整个输入域进行了处理和编码，所有可能长于一个标签的后缀都将从字符串中提取并插入字典。
This section shows an example of how to encode a set of realms using the specified realm compression algorithm. For example, a message might need to compress the realms "foo.example.com", "bar.foo.example.com", "buz.foo.example.org", "example.com", and "bar.example.com.org". The following example shows the processing of input realms on the left-hand side and the contents of the dictionary on the right-hand side. The example uses hexadecimal representation of numbers.
本节展示了如何使用指定的领域压缩算法对一组领域进行编码的示例。例如，消息可能需要压缩域“foo.example.com”、“bar.foo.example.com”、“buz.foo.example.org”、“example.com”和“bar.example.com.org”。下面的示例在左侧显示输入域的处理，在右侧显示字典的内容。该示例使用数字的十六进制表示。
COMPRESSOR: DICTIONARY:
压缩器：字典：
1) Input "foo.example.com"
Search("foo.example.com")
Search("foo.example")
Search("foo")
Encode(0x03,'f','o','o') 0x00 "foo"
+-> "longest non-matching string" = "foo"
Search("example.com")
Search("example")
Encode(0x07,'e','x','a','m','p','l','e') 0x01 "example"
+-> "longest non-matching string" = "foo.example"
Search("com")
Encode(0x03,'c','o','m') 0x02 "com"
+-> "longest non-matching string" = "foo.example.com"
0x03 "foo.example.com"
0x04 "example.com"
Encode(0x00)
1) 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)
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)
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编码（0x84）编码（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)
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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管理的网络通告给其他MR。这也表明该MR能够接收路由优化注册请求。实际上，这允许MR在CR角色中工作。
R Request mobile network information. If the 'R' bit is set, the HA MAY respond with information about mobile networks in the same domain.
R请求移动网络信息。如果设置了“R”位，则HA可以使用关于同一域中的移动网络的信息进行响应。
S Solicit prefixes managed by a specific MR. The MR is specified in the Optional Mobile Router HoA field.
S由特定MR管理的请求前缀。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设备、有状态防火墙或任何接口上的类似问题，请求路由器只能启动传出连接，而不能接受任何传入连接。医管局在答覆中反映了这一点，并在前缀广告中分发给其他夫人。
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支持路由优化，则HA必须在注册回复消息中将此不可跳过的扩展发送给MR。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Subtype |O|N|S| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 HA检测到NAT。这会通知MR它位于NAT后面。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.
It’他在回应一项请求。如果MR的路线优化能力扩展（第5.1节）中存在“S”位，则设置该位；否则，它是未设置的。
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，而是发送给另一个MR。该格式类似于[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... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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索引字段告诉CR在生成Home keygen令牌时使用哪个Nonce值。删除绑定的请求中忽略了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 in use. If using a pre-shared KRm, set to zero and ignored on reception.
正在使用的主当前索引。如果使用预共享KRm，则设置为零并在接收时忽略。
Care-of Nonce Index
临时索引的维护
Care-of Nonce Index in use. If using a pre-shared KRm, set to zero and ignored on reception.
注意使用中的临时索引。如果使用预共享KRm，则设置为零并在接收时忽略。
Authenticator
验证者
Authenticator field, by default constructed with First (128, HMAC_SHA1 (KRm, Protected Data)).
验证器字段，默认情况下由第一个字段（128，HMAC_SHA1（KRm，受保护数据））构造。
The protected data, just like in other cases where the Authenticator field is used, consists of
与使用Authenticator字段的其他情况一样，受保护的数据包括
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 此扩展的类型、长度、主Nonce索引和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发送的注册回复中，以通知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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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隧道的转交地址。可以列出多个CoA以促进更快的NAT遍历处理。
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或网络前缀组成。MR HoA后面的任何网络前缀都归该MR 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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1..n times the following information structure
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|M| PLen/Info | Optional Mobile Router HoA (4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Optional Prefix (1, 2, 3, or 4 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Realm (1..n characters) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 50 (non-skippable); "long" extension format.
类型50（不可跳过）；“长”扩展格式。
Subtype 1
亚型1
Length Total length of the packet. When processing the information structures, if Length octets have been reached, this is an indication that the final information structure was reached as well.
长度数据包的总长度。在处理信息结构时，如果已达到长度八位字节，则表示也已达到最终信息结构。
D Delta. If D = 1, the prefix is a delta from the last Prefix, where D = 0. MUST be zero on the first information structure containing a Prefix; MAY be zero or one on subsequent information structures. If D = 1, the Prefix field is one octet in length. See Section 4.1 for details.
D三角洲。如果D=1，则前缀是最后一个前缀的增量，其中D=0。包含前缀的第一个信息结构必须为零；在后续信息结构上可能为零或一。如果D=1，前缀字段的长度为一个八位字节。详见第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
移动路由器
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.
移动路由器的家庭地址。以下信息结构中M=0的所有前缀均由该MR维护。仅当M=1时，此字段才存在。
Prefix The IPv4 prefix advertised. If D = 0, the field length is PLen bits, rounded up to the nearest full octet. Least-significant bits starting off PLen (and that are zeros) are omitted. If D = 1, the field length is one octet. This field is present only when M = 0.
前缀为播发的IPv4前缀。如果D=0，则字段长度为PLen位，四舍五入至最接近的完整八位字节。从PLen开始的最低有效位（和零）被省略。如果D=1，则字段长度为一个八位字节。仅当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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
主页初始化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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
注意Init Cookie
64-bit field that contains a random value, the Care-of Init Cookie.
包含随机值的64位字段，由Init Cookie负责。
This message is sent from the CR to the MR when performing the RR procedure as a reply to the Home Test Init message. The source and destination IP addresses, as well as UDP ports, are the reverse of those in the Home Test Init message for which this message is constructed. As such, the UDP source port is always 434.
当执行RR程序时，该消息从CR发送到MR，作为对Home Test Init消息的回复。源和目标IP地址以及UDP端口与构建此消息的Home Test 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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
主页初始化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位home 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，作为对转交测试初始化消息的回复。源和目标IP地址以及UDP端口与构造此消息的Care of Test 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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 27
类型27
Reserved Set to zero; MUST be ignored on reception.
保留设置为零；接待时必须忽略。
Care-of Nonce Index
临时索引的维护
This field will be echoed back by the MR to the CR in a subsequent Registration Request's authentication extension.
该字段将由MR在后续注册请求的认证扩展中回显给CR。
Care-of Init Cookie
注意Init Cookie
64-bit field that contains a random value, the Care-of Init Cookie.
包含随机值的64位字段，由Init Cookie负责。
Care-of Keygen Token
保管Keygen代币
This field contains the 64-bit care-of keygen token used in the RR procedure. Generated from cookie + nonce.
此字段包含RR过程中使用的64位密钥保管令牌。从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节）中的Info字段传递给其他MR。HA还可以检测NAT，并通过路由优化应答扩展中的“N”标志通知注册MR（第5.2节）。在已知一个或两个路由器位于NAT后面或类似受损（无法接受传入连接）的情况下，隧道建立过程需要考虑这一点。
In the case where the MR is behind a NAT (or firewall) and the CR is not, the MR will, when the tunnel has been established, send keepalive messages (ICMP echo requests) through the tunnel. Until a reply has been received, the tunnel SHOULD NOT be considered active. Once a reply has been received, NAT mapping is in place, and traffic can be sent.
如果MR位于NAT（或防火墙）后面而CR不在，则MR将在隧道建立后通过隧道发送keepalive消息（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可能有多个接口连接到多个不同的网络，因此特定MRs可能只能使用从特定网络获得的特定CoA对执行路由优化——例如，在两个MRs在同一NAT后面有接口的情况下。类似的情况也可能发生
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可以通过执行注册并尝试建立隧道（发送keepalives）来检测合格的CoA对，其中每个CoA都列在注册回复的转交地址扩展中。合格的对应记录在路由优化缓存中。如果无法使用任何COA建立隧道，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都在两个单独的nat后面，则可以使用某种代理或穿孔技术。这超出了本文档的范围。
If both the MR and the CR move at the same time, this causes no issues from the signaling perspective, as all requests are always sent from a CoA to HoAs. Thus, the recipient will always receive the request and can send the reply. This applies even in break-before-make situations where both the MR and the CR get disconnected at the same time -- once the connectivity is restored, one endpoint of the signaling messages is always the HoA of the respective router, and it is up to the HA to provide reachability.
如果MR和CR同时移动，则从信令角度来看，这不会导致任何问题，因为所有请求总是从CoA发送到HOA。因此，收件人将始终收到请求并可以发送回复。这甚至适用于MR和CR同时断开连接的断开-一旦连接恢复，信令消息的一个端点始终是相应路由器的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.
MRs可以在没有HA协助的情况下协商和执行路由优化——如果他们能够发现彼此的存在，从而知道在哪里发送注册消息。本文档仅针对逻辑上单一的HA，该HA将网络前缀信息分发给MRs。可能的信任关系会产生问题；在本文档中，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.
如果需要在连接到单独HAs的节点之间进行路由优化，则有几种可能性。请注意，可以使用标准的高可用性冗余协议，例如虚拟路由器冗余协议（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.
在连接到单独的HA的MRs之间实现路由优化存在多种可能性，例如新的发现/探测协议或HAs或DNS SRV记录之间的路由协议，或通用身份验证、授权和计费（AAA）体系结构。已经有一个框架供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.
考虑两个网络A和B分别由MRS A和B处理的情况。如果路由器以这样的方式设置，即当路由器转发目的地为路由优化缓存中的网络前缀的分组时触发路由优化，则如果网络a中的节点开始向网络B中的节点发送ICMP回显请求（ping分组），则会发生以下情况。
MR A sees the incoming ICMP echo request packet from the local network destined to network B. Since network B exists in MR A's Route Optimization Cache, the route optimization process is triggered. The original packet is forwarded via the reverse tunnel toward the HA as normal.
MR A看到从本地网络发送到网络B的传入ICMP回显请求数据包。由于网络B存在于MR 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.
mra完成RR过程并向mrb注册，从而成为mra的CR。在路由器之间创建隧道。MR B更新其路由表，以便可以通过MR A<->MR B隧道到达网络A。
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处的路由优化。因此，MR B现在向MR A执行其自己的注册。完成后，MR B注意到到到MR A的隧道已经存在，并更新其路由表，以便现在可以通过（现有）MR A<->MR B隧道到达网络A。从这一点开始，交通是双向的。
In this scenario, if MR A does NOT wait for a separate route optimization process (RR check and registration) from MR B, but instead simply updates its routing table to reach network B via the tunnel, problems may arise if MR B has started to manage another network, B', before the information has been propagated to MR A. The end result is that MR B starts to receive packets from network A to network B' via the HA and to network B via the direct tunnel. If reverse path checking or a similar mechanism is in use on MR B, some of the packets from network A could be black-holed.
在这种情况下，如果MR A不等待来自MR B的单独路由优化过程（RR检查和注册），而是简单地更新其路由表以通过隧道到达网络B，则如果MR B已开始管理另一个网络B'，则可能会出现问题，在信息传播到MR A之前。最终结果是MR B开始通过HA从网络A接收数据包到网络B'，并通过直接隧道接收数据包到网络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的COA，这在严格意义上是不必要的；医管局本可以直接提供有关的指引。
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提供其他路由器的知识，还提供由哪些路由器管理的网络的信息。
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之间创建最佳路径的可能性；它没有规定使用这些路径的用户流量应该是什么。[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.
下面的示例假设有三个移动路由器——MR A、MR B和MR C——每个路由器管理网络前缀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.
| | | |
+--------+ +--------+ +--------+ +--------------+
| [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节相同的网络设置——三个MRs，每个MRs对应于各自的网络。节点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
======= 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.
+----------+ +--------+ +------+ +--------+ +----------+
| [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
| | | | |
| |<---------x | | Registration Reply
| | | | | contains info on
| | | | | network A
| | | | |
| x==========O-------->| | Registration Reply
| | | | | includes MR A's CoA in
| | | | | Care-of Address
| | | | | Extension
| | | | |
| |<= = = = =O= = = ==>| | Optional mutual
| | | | | registration from
| | | | | MR A to MR C
| | | | | (same procedure as above,
| | | | | multiple packets);
| | | | | possible keepalive checks
| | | | |
|<-----------O=-=-=-==-=-=-=-==-=-O-------x Packet from Node C -> A
| | | | | routed to direct tunnel
| | | | | at MR C, based on
| | | | | MR C now knowing MR A's
| | | | | CoA and tunnel being up
| | | | |
x------------O=-=-=-==-=-=-=-==-=-O------>| Packet from Node A -> C
| | | | | routed to direct tunnel
| | | | | at MR A, based on MR A
| | | | | now knowing MR C's CoA
| | | | | and tunnel being up
In this signaling example, MR C changes its CoA while route optimization between MR A and MR C is operating and data is being transferred. Cases where the handover is graceful ("make before break") and ungraceful ("break before make") both occur in similar fashion, except that in the graceful version no packets are lost. This diagram considers the case where MR C gets immediate notification of lost connectivity, e.g., due to a link status indication. MR A would eventually notice the breakdown, due to keepalive messages failing.
在这个信令示例中，MR C改变其CoA，同时MR A和MR C之间的路由优化正在运行并且数据正在传输。切换正常（“断开前接通”）和不正常（“断开前接通”）的情况都以类似的方式发生，但在正常版本中没有数据包丢失。此图考虑了MR C立即收到连接丢失通知的情况，例如，由于链路状态指示。由于keepalive消息失败，A先生最终会注意到故障。
======= Traffic inside Mobile IP tunnel to/from HA
=-=-=-= Traffic inside Mobile IP tunnel between MRs
------- Traffic outside Mobile IP tunnel
======= 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
| | | | |
+----------+ +--------+ +------+ +--------+ +----------+
| [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
| | | | |
| 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
最长当前生存期240秒最长令牌生存期210秒最长更新率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.
路由优化身份验证处理需要四个新的消息类型编号。下表1列出了新的移动IP消息类型。
+-------+---------------------------+
| Value | Name |
+-------+---------------------------+
| 24 | Home Test Init message |
| 25 | Care-of Test Init message |
| 26 | Home Test message |
| 27 | Care-of Test message |
+-------+---------------------------+
+-------+---------------------------+
| Value | Name |
+-------+---------------------------+
| 24 | Home Test Init message |
| 25 | Care-of Test Init message |
| 26 | Home Test message |
| 27 | Care-of Test message |
+-------+---------------------------+
Table 1: New Values and Names for Mobile IP Message Types
表1：移动IP消息类型的新值和名称
Three new registration message extension types are required and listed in Table 2. The first type, 153, is skippable and has been allocated from range 128-255. The other two, 49 and 50, are non-skippable and have been allocated from range 0-127, with 49 being of the "short" format and 50 being of the "long" format. None of the messages are permitted for notification messages.
表2中列出了三种新的注册消息扩展类型。第一种类型153是可跳过的，已在128-255范围内分配。另外两个，49和50，是不可跳过的，分配范围为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 |
+--------------+---------------------------------------------+
+--------------+---------------------------------------------+
| Value | Name |
+--------------+---------------------------------------------+
| 153, 128-255 | Mobile Router Route Optimization Indication |
| 49, 0-127 | Route Optimization Extensions |
| 50, 0-127 | Route Optimization Data |
+--------------+---------------------------------------------+
Table 2: New Values and Names for Extensions in Mobile IP Registration Messages
表2：移动IP注册消息中扩展的新值和名称
In addition, the registry "Code Values for Mobile IP Registration Reply Messages" has been modified. A new success code, 2, should be allocated as follows:
此外，注册表“移动IP注册回复消息的代码值”已被修改。应按如下方式分配新的成功代码2：
2 Concurrent registration (pre-accept)
2同时注册（预接受）
In addition, a new allocation range has been created as "Error Codes from the Correspondent Node", subject to the policy of Expert Review [RFC5226]. The range is 201-210. Three new Registration Reply codes have been allocated from this range. They are specified in Table 3, below:
此外，根据专家评审政策[RFC5226]，新的分配范围被创建为“对应节点的错误代码”。范围是201-210。在此范围内分配了三个新的注册回复代码。它们在下表3中规定：
+-------+-----------------------------+
| Value | Name |
+-------+-----------------------------+
| 201 | Expired Home nonce Index |
| 202 | Expired Care-of nonce Index |
| 203 | Expired nonces |
+-------+-----------------------------+
+-------+-----------------------------+
| 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 Required[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 |
+------+---------+--------------------------------------------------+
+------+---------+--------------------------------------------------+
| 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.
有两个主要的安全问题：一个问题与RR检查有关，后者确定特定的CoA确实由特定的HoA管理。另一个问题是信任关系和声称代表任意网络的任意路由器。
The end-user traffic can be protected using normal IPsec mechanisms.
可以使用正常的IPsec机制保护最终用户流量。
The RR check's security has been vetted with Mobile IPv6. There are no major differences, apart from two issues: connectivity check and replay attack protection. The connectivity check is conducted with a separate ICMP message exchange. Replay attack protection is achieved with Mobile IPv4 timestamps in the Registration Request's Identification field, in contrast to the sequence numbers used in Mobile IPv6.
RR检查的安全性已经过移动IPv6的审查。除了两个问题：连接检查和重播攻击保护之外，没有什么主要区别。连接检查通过单独的ICMP消息交换进行。与移动IPv6中使用的序列号不同，通过注册请求的标识字段中的移动IPv4时间戳实现重放攻击保护。
The RR procedure does not establish any kind of state information on the CR; this mitigates denial-of-service attacks. State information is only maintained after a Registration Request has been accepted.
RR程序不建立CR的任何类型的状态信息；这可以减轻拒绝服务攻击。只有在接受注册请求后，才会维护状态信息。
The network of trust relationships in home agent-assisted route optimization solves possible trust issues: An arbitrary CR can trust an arbitrary MR that it is indeed the proper route to reach an arbitrary mobile network.
归属代理辅助路由优化中的信任关系网络解决了可能的信任问题：任意CR可以信任任意MR，即它确实是到达任意移动网络的正确路由。
It is assumed that all MRs have a trust relationship with the HA. Thus, they trust information provided by the HA.
假设所有mr均与医管局有信托关系。因此，他们相信医管局提供的资料。
The HA provides information matching HoAs and network prefixes. Each MR trusts this information.
HA提供与HOA和网络前缀匹配的信息。每个MR都信任这些信息。
MRs may perform the RR procedure between each other. This creates a trusted association between the MR's HoA and CoA. The MR also claims to represent a specific network. This information is not trustworthy as such.
MRs可以在彼此之间执行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<->网络前缀信息来验证该声明，这些信息可能是较早收到的，也可能是由于HA的按需请求而收到的。如果他们匹配，MR的声明是真实的。如果网络被认为是可信的，则可以做出策略决定跳过此检查。关于可以做出此类决定的情况的准确定义不在本文件的范围内。建议的一般做法是执行检查。
Thanks to Alexandru Petrescu for constructive comments and support. Thanks to Jyrki Soini and Kari Laihonen for initial reviews. This work was supported by TEKES as part of the Future Internet program of TIVIT (Finnish Strategic Centre for Science, Technology and Innovation in the field of ICT).
感谢Alexandru Petrescu的建设性评论和支持。感谢Jyrki Soini和Kari Laihonen的初步审查。这项工作得到了TEKES的支持，作为TIVIT（芬兰信息和通信技术领域科学、技术和创新战略中心）未来互联网项目的一部分。
[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]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年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，“移动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 59442010年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.Erenen，“网络访问标识符”，RFC 42822005年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 62752011年7月。
Authors' Addresses
作者地址
Antti Makela Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto FINLAND
安蒂·马克拉阿尔托大学通信与网络系（Comnet）邮政信箱13000 FIN-00076芬兰阿尔托
EMail: antti.t.makela@iki.fi
EMail: antti.t.makela@iki.fi
Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND
Jouni Korhonen诺基亚西门子网络公司Linnoitustie 6 FI-02600 Espoo芬兰
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com