Network Working Group C. Ng
Request for Comments: 4888 Panasonic Singapore Labs
Category: Informational P. Thubert
Cisco Systems
M. Watari
KDDI R&D Labs
F. Zhao
UC Davis
July 2007
Network Working Group C. Ng
Request for Comments: 4888 Panasonic Singapore Labs
Category: Informational P. Thubert
Cisco Systems
M. Watari
KDDI R&D Labs
F. Zhao
UC Davis
July 2007
Network Mobility Route Optimization Problem Statement
网络移动性路由优化问题陈述
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO.
在当前网络移动性（NEMO）基本支持下，当移动网络不在时，与移动网络节点之间的所有通信必须通过移动路由器和归属代理之间建立的双向隧道。这种次优路由导致与数据包交付相关的各种低效率，例如延迟增加和瓶颈链路导致流量拥塞，这最终会中断与移动网络节点之间的所有通信。此外，随着移动网络的嵌套，这些低效率变得更加复杂，在特定的部署中可能会出现僵局。本文件调查了此类问题，并为NEMO提供了路线优化（RO）背后的动机。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Route Optimization Problem Statement . . . . . . . . . . 3
2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2. Bottleneck in the Home Network . . . . . . . . . . . . . . 6
2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6
2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9
2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12
6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12
Appendix A. Various Configurations Involving Nested Mobile
Networks . . . . . . . . . . . . . . . . . . . . . . 13
A.1. CN Located in the Fixed Infrastructure . . . . . . . . . . 13
A.1.1. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14
A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14
A.1.3. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14
A.2. CN Located in Distinct Nested NEMOs . . . . . . . . . . . 15
A.2.1. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16
A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
A.2.3. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16
A.3. MNN and CN Located in the Same Nested NEMO . . . . . . . . 17
A.3.1. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18
A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
A.3.3. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19
A.4. CN Located Behind the Same Nested MR . . . . . . . . . . . 19
A.4.1. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20
A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
A.4.3. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21
Appendix B. Example of How a Stalemate Situation Can Occur . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Route Optimization Problem Statement . . . . . . . . . . 3
2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2. Bottleneck in the Home Network . . . . . . . . . . . . . . 6
2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6
2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9
2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12
6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12
Appendix A. Various Configurations Involving Nested Mobile
Networks . . . . . . . . . . . . . . . . . . . . . . 13
A.1. CN Located in the Fixed Infrastructure . . . . . . . . . . 13
A.1.1. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14
A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14
A.1.3. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14
A.2. CN Located in Distinct Nested NEMOs . . . . . . . . . . . 15
A.2.1. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16
A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
A.2.3. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16
A.3. MNN and CN Located in the Same Nested NEMO . . . . . . . . 17
A.3.1. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18
A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
A.3.3. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19
A.4. CN Located Behind the Same Nested MR . . . . . . . . . . . 19
A.4.1. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20
A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
A.4.3. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21
Appendix B. Example of How a Stalemate Situation Can Occur . . . 22
With current Network Mobility (NEMO) Basic Support [1], all communications to and from nodes in a mobile network must go through the bi-directional tunnel established between the Mobile Router and its Home Agent (also known as the MRHA tunnel) when the mobile network is away. Although such an arrangement allows Mobile Network Nodes to reach and be reached by any node on the Internet, limitations associated to the base protocol degrade overall performance of the network and, ultimately, can prevent all communications to and from the Mobile Network Nodes.
使用当前网络移动性（NEMO）基本支持[1]，当移动网络不在时，与移动网络中的节点之间的所有通信必须通过移动路由器与其归属代理之间建立的双向隧道（也称为MRHA隧道）。尽管这样的布置允许移动网络节点到达因特网上的任何节点并被其到达，但是与基本协议相关联的限制降低了网络的整体性能，并且最终可以阻止与移动网络节点之间的所有通信。
Some of these concerns already exist with Mobile IPv6 [4] and were addressed by the mechanism known as Route Optimization, which is part of the base protocol. With Mobile IPv6, Route Optimization mostly improves the end-to-end path between the Mobile Node and Correspondent Node, with an additional benefit of reducing the load of the Home Network, thus its name.
移动IPv6[4]已经存在其中一些问题，并通过称为路由优化的机制解决了这些问题，路由优化是基本协议的一部分。在移动IPv6中，路由优化主要是改善移动节点和对应节点之间的端到端路径，还有一个额外的好处是减少家庭网络的负载，因此得名。
NEMO Basic Support presents a number of additional issues, making the problem more complex, so it was decided to address Route Optimization separately. In that case, the expected benefits are more dramatic, and a Route Optimization mechanism could enable connectivity that would be broken otherwise. In that sense, Route Optimization is even more important to NEMO Basic Support than it is to Mobile IPv6.
NEMO基本支持提出了许多其他问题，使问题更加复杂，因此决定单独解决路由优化问题。在这种情况下，预期的好处更为显著，路由优化机制可以实现否则将被破坏的连接。从这个意义上讲，路由优化对于NEMO基础支持比移动IPv6更为重要。
This document explores limitations inherent in NEMO Basic Support, and their effects on communications between a Mobile Network Node and its corresponding peer. This is detailed in Section 2. It is expected that readers are familiar with general terminologies related to mobility in [4][2], NEMO-related terms defined in [3], and NEMO goals and requirements [5].
本文档探讨了NEMO基本支持中固有的限制，以及它们对移动网络节点与其对应对等方之间通信的影响。第2节对此进行了详细说明。希望读者熟悉[4][2]中与机动性相关的通用术语、[3]中定义的NEMO相关术语以及NEMO目标和要求[5]。
Given the NEMO Basic Support protocol, all data packets to and from Mobile Network Nodes must go through the Home Agent, even though a shorter path may exist between the Mobile Network Node and its Correspondent Node. In addition, with the nesting of Mobile Routers, these data packets must go through multiple Home Agents and several levels of encapsulation, which may be avoided. This results in various inefficiencies and problems with packet delivery, which can ultimately disrupt all communications to and from the Mobile Network Nodes.
根据NEMO基本支持协议，进出移动网络节点的所有数据包必须通过归属代理，即使移动网络节点与其对应节点之间可能存在较短的路径。此外，随着移动路由器的嵌套，这些数据包必须经过多个家庭代理和多个级别的封装，这是可以避免的。这导致了数据包交付的各种低效和问题，最终会中断与移动网络节点之间的所有通信。
In the following sub-sections, we will describe the effects of a pinball route with NEMO Basic Support, how it may cause a bottleneck to be formed in the Home Network, and how these get amplified with
在下面的小节中，我们将描述有NEMO基本支持的弹球路线的影响，它如何可能导致家庭网络中形成瓶颈，以及这些瓶颈如何随着时间的推移而扩大
nesting of mobile networks. Closely related to nesting, we will also look into the sub-optimality even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. This is followed by a description of security policy in the Home Network that may forbid transit traffic from Visiting Mobile Nodes in mobile networks. In addition, we will explore the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network. We will also provide additional motivations for Route Optimization by considering the potential stalemate situation when a Home Agent is part of a mobile network.
移动网络的嵌套。与嵌套密切相关的是，即使在NEMO基础支持上使用移动IPv6路由优化，我们也将研究次优性。接着描述了家庭网络中的安全策略，该策略可能禁止过境流量访问移动网络中的移动节点。此外，我们将探讨MRHA隧道对同一移动网络不同链路上两个移动网络节点之间通信的影响。我们还将考虑当归属代理是移动网络的一部分时可能出现的僵局情况，为路由优化提供额外的动机。
With NEMO Basic Support, all packets sent between a Mobile Network Node and its Correspondent Node are forwarded through the MRHA tunnel, resulting in a pinball route between the two nodes. This has the following sub-optimal effects:
在NEMO基本支持下，移动网络节点与其对应节点之间发送的所有数据包都通过MRHA隧道转发，从而在两个节点之间形成弹球路由。这具有以下次优效果：
o Longer Route Leading to Increased Delay and Additional Infrastructure Load
o 更长的路由导致更大的延迟和额外的基础设施负载
Because a packet must transit from a mobile network to the Home Agent then to the Correspondent Node, the transit time of the packet is usually longer than if the packet were to go straight from the mobile network to the Correspondent Node. When the Correspondent Node (or the mobile network) resides near the Home Agent, the increase in packet delay can be very small. However, when the mobile network and the Correspondent Node are relatively near to one another but far away from the Home Agent on the Internet, the increase in delay is very large. Applications such as real-time multimedia streaming may not be able to tolerate such increase in packet delay. In general, the increase in delay may also impact the performance of transport protocols such as TCP, since the sending rate of TCP is partly determined by the round-trip time (RTT) perceived by the communication peers.
由于数据包必须从移动网络传输到归属代理，然后再传输到对应节点，因此数据包的传输时间通常比数据包直接从移动网络传输到对应节点的时间长。当对应节点（或移动网络）位于归属代理附近时，数据包延迟的增加可能非常小。然而，当移动网络和对应节点彼此相对靠近但远离因特网上的归属代理时，延迟的增加非常大。诸如实时多媒体流之类的应用程序可能无法容忍分组延迟的这种增加。通常，延迟的增加还可能影响传输协议（如TCP）的性能，因为TCP的发送速率部分由通信对等方感知的往返时间（RTT）决定。
Moreover, by using a longer route, the total resource utilization for the traffic would be much higher than if the packets were to follow a direct path between the Mobile Network Node and Correspondent Node. This would result in additional load in the infrastructure.
此外，通过使用更长的路由，与分组沿着移动网络节点和对应节点之间的直接路径时相比，业务的总资源利用率将高得多。这将导致基础结构中的额外负载。
o Increased Packet Overhead
o 增加的数据包开销
The encapsulation of packets in the MRHA tunnel results in increased packet size due to the addition of an outer header. This reduces the bandwidth efficiency, as an IPv6 header can be
在MRHA隧道中封装数据包导致由于添加外部报头而增加的数据包大小。这降低了带宽效率，因为IPv6报头可以
quite substantial relative to the payload for applications such as voice samples. For instance, given a voice application using an 8 kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms (as in RFC 1889 [6]), the packet transmission rate will be 50 packets per second. Each additional IPv6 header is an extra 320 bits per packet (i.e., 16 kbps), which is twice the actual payload!
相对于语音样本等应用程序的有效负载而言，这相当可观。例如，给定使用8kbps算法（例如，g.729）的语音应用程序，并每20ms采集一个语音样本（如RFC 1889[6]），分组传输速率将为每秒50个分组。每个额外的IPv6报头是每个数据包额外的320位（即16 kbps），这是实际有效负载的两倍！
o Increased Processing Delay
o 增加处理延迟
The encapsulation of packets in the MRHA tunnel also results in increased processing delay at the points of encapsulation and decapsulation. Such increased processing may include encryption/ decryption, topological correctness verifications, MTU computation, fragmentation, and reassembly.
在MRHA隧道中封装数据包也会导致封装和去封装点的处理延迟增加。这种增加的处理可以包括加密/解密、拓扑正确性验证、MTU计算、分段和重新组装。
o Increased Chances of Packet Fragmentation
o 增加数据包碎片的机会
The augmentation in packet size due to packet encapsulation may increase the chances of the packet being fragmented along the MRHA tunnel. This can occur if there is no prior path MTU discovery conducted, or if the MTU discovery mechanism did not take into account the encapsulation of packets. Packet fragmentation will result in a further increase in packet delays and further reduction of bandwidth efficiency.
由于数据包封装而导致的数据包大小的增加可能会增加数据包沿MRHA隧道分段的机会。如果之前没有进行路径MTU发现，或者MTU发现机制没有考虑数据包的封装，则可能会发生这种情况。数据包碎片化将导致数据包延迟的进一步增加和带宽效率的进一步降低。
o Increased Susceptibility to Link Failure
o 增加链路故障的易感性
Under the assumption that each link has the same probability of link failure, a longer routing path would be more susceptible to link failure. Thus, packets routed through the MRHA tunnel may be subjected to a higher probability of being lost or delayed due to link failure, compared to packets that traverse directly between the Mobile Network Node and its Correspondent Node.
在假设每个链路具有相同的链路故障概率的情况下，较长的路由路径更容易发生链路故障。因此，与直接在移动网络节点与其对应节点之间穿过的分组相比，通过MRHA隧道路由的分组可能由于链路故障而遭受更高的丢失或延迟概率。
Apart from the increase in packet delay and infrastructure load, forwarding packets through the Home Agent may also lead to either the Home Agent or the Home Link becoming a bottleneck for the aggregated traffic from/to all the Mobile Network Nodes. A congestion at home would lead to additional packet delay, or even packet loss. In addition, Home Agent operations such as security check, packet interception, and tunneling might not be as optimized in the Home Agent software as plain packet forwarding. This could further limit the Home Agent capacity for data traffic. Furthermore, with all traffic having to pass through the Home Link, the Home Link becomes a single point of failure for the mobile network.
除了分组延迟和基础设施负载的增加之外，通过归属代理转发分组还可能导致归属代理或归属链路成为来自/到所有移动网络节点的聚合流量的瓶颈。家中的拥塞会导致额外的数据包延迟，甚至数据包丢失。此外，在Home Agent软件中，Home Agent操作（如安全检查、数据包拦截和隧道）可能没有普通数据包转发那样优化。这可能进一步限制归属代理的数据流量容量。此外，由于所有业务必须通过归属链路，归属链路成为移动网络的单点故障。
Data packets that are delayed or discarded due to congestion at the Home Network would cause additional performance degradation to applications. Signaling packets, such as Binding Update messages, that are delayed or discarded due to congestion at the Home Network may affect the establishment or update of bi-directional tunnels, causing disruption of all traffic flow through these tunnels.
由于家庭网络拥塞而延迟或丢弃的数据包将导致应用程序性能进一步下降。由于家庭网络的拥塞而延迟或丢弃的信令分组，例如绑定更新消息，可能影响双向隧道的建立或更新，导致通过这些隧道的所有业务流中断。
A NEMO Route Optimization mechanism that allows the Mobile Network Nodes to communicate with their Correspondent Nodes via a path that is different from the MRHA tunneling and thereby avoiding the Home Agent may alleviate or even prevent the congestion at the Home Agent or Home Link.
允许移动网络节点经由不同于MRHA隧道的路径与其对应节点通信并由此避免归属代理的NEMO路由优化机制可减轻甚至防止归属代理或归属链路处的拥塞。
By allowing other mobile nodes to join a mobile network, and in particular mobile routers, it is possible to form arbitrary levels of nesting of mobile networks. With such nesting, the use of NEMO Basic Support further amplifies the sub-optimality of routing. We call this the amplification effect of nesting, where the undesirable effects of a pinball route with NEMO Basic Support are amplified with each level of nesting of mobile networks. This is best illustrated by an example shown in Figure 1.
通过允许其他移动节点加入移动网络，特别是移动路由器，可以形成任意级别的移动网络嵌套。通过这种嵌套，NEMO基本支持的使用进一步放大了路由的次优性。我们称之为嵌套的放大效应，其中带有NEMO基本支持的弹球路线的不良效应随着移动网络的每一层嵌套而放大。图1所示的示例最好地说明了这一点。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN1
+--------+ +------------------------------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN2
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN1
+--------+ +------------------------------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN2
Figure 1: An Example of a Nested Mobile Network
图1：嵌套移动网络的示例
Using NEMO Basic Support, the flow of packets between a Mobile Network Node, MNN, and a Correspondent Node, CN1, would need to go through three separate tunnels, illustrated in Figure 2 below.
使用NEMO基本支持，移动网络节点MNN和对应节点CN1之间的数据包流需要通过三个单独的隧道，如下图2所示。
----------.
---------/ /----------.
-------/ | | /-------
MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
MR3-------\ | | \-------MR3_HA
MR2--------\ \----------MR2_HA
MR1---------MR1_HA
----------.
---------/ /----------.
-------/ | | /-------
MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
MR3-------\ | | \-------MR3_HA
MR2--------\ \----------MR2_HA
MR1---------MR1_HA
Figure 2: Nesting of Bi-Directional Tunnels
图2：双向隧道的嵌套
This leads to the following problems:
这会导致以下问题：
o Pinball Route
o 弹球路线
Both inbound and outbound packets will flow via the Home Agents of all the Mobile Routers on their paths within the mobile network, with increased latency, less resilience, and more bandwidth usage. Appendix A illustrates in detail the packets' routes under different nesting configurations of the Mobile Network Nodes.
入站和出站数据包都将通过移动网络中所有移动路由器路径上的归属代理流动，延迟增加，弹性降低，带宽使用率增加。附录A详细说明了移动网络节点在不同嵌套配置下的数据包路由。
o Increased Packet Size
o 增加的数据包大小
An extra IPv6 header is added per level of nesting to all the packets. The header compression suggested in [7] cannot be applied because both the source and destination (the intermediate Mobile Router and its Home Agent) are different hop to hop.
每个嵌套级别都会向所有数据包添加一个额外的IPv6头。无法应用[7]中建议的报头压缩，因为源和目标（中间移动路由器及其归属代理）是不同的逐跳。
Nesting also amplifies the probability of congestion at the Home Networks of the upstream Mobile Routers. In addition, the Home Link of each upstream Mobile Router will also be a single point of failure for the nested Mobile Router.
嵌套还增加了上游移动路由器的家庭网络发生拥塞的概率。此外，每个上游移动路由器的主链路也将是嵌套移动路由器的单点故障。
When a Mobile IPv6 host joins a mobile network, it becomes a Visiting Mobile Node of the mobile network. Packets sent to and from the Visiting Mobile Node will have to be routed not only via the Home Agent of the Visiting Mobile Node, but also via the Home Agent of the Mobile Router in the mobile network. This suffers the same amplification effect of nested mobile network mentioned in Section 2.3.
当移动IPv6主机加入移动网络时，它将成为移动网络的访问移动节点。发送到访问移动节点和从访问移动节点发送的分组将必须不仅经由访问移动节点的归属代理路由，而且还经由移动网络中的移动路由器的归属代理路由。这与第2.3节中提到的嵌套移动网络具有相同的放大效应。
In addition, although Mobile IPv6 [4] allows a mobile host to perform Route Optimization with its Correspondent Node in order to avoid tunneling with its Home Agent, the "optimized" route is no longer optimized when the mobile host is attached to a mobile network. This is because the route between the mobile host and its Correspondent Node is subjected to the sub-optimality introduced by the MRHA tunnel. Interested readers may refer to Appendix A for examples of how the routes will appear with nesting of Mobile IPv6 hosts in mobile networks.
此外，尽管移动IPv6[4]允许移动主机与其对应节点执行路由优化以避免与其归属代理进行隧道，但当移动主机连接到移动网络时，“优化”路由不再优化。这是因为移动主机与其对应节点之间的路由受到MRHA隧道引入的次优性的影响。感兴趣的读者可参考附录A，了解移动网络中移动IPv6主机嵌套时路由的显示示例。
The readers should also note that the same sub-optimality would apply when the mobile host is outside the mobile network and its Correspondent Node is in the mobile network.
读者还应注意，当移动主机位于移动网络之外且其对应节点位于移动网络中时，同样的次优性也适用。
NEMO Basic Support requires all traffic from visitors to be tunneled to the Mobile Router's Home Agent. This might represent a breach in the security of the Home Network (some specific attacks against the Mobile Router's binding by rogue visitors have been documented in [8][9]). Administrators might thus fear that malicious packets will be routed into the Home Network via the bi-directional tunnel. As a consequence, it can be expected that in many deployment scenarios, policies will be put in place to prevent unauthorized Visiting Mobile Nodes from attaching to the Mobile Router.
NEMO基本支持要求访客的所有流量通过隧道传输到移动路由器的主代理。这可能意味着家庭网络的安全性遭到破坏（恶意访问者对移动路由器绑定的某些特定攻击已在[8][9]中记录）。因此，管理员可能担心恶意数据包将通过双向隧道路由到家庭网络。因此，可以预期，在许多部署场景中，将实施策略以防止未经授权的访问移动节点连接到移动路由器。
However, there are deployment scenarios where allowing unauthorized Visiting Mobile Nodes is actually desirable. For instance, when Mobile Routers attach to other Mobile Routers and form a nested NEMO, they depend on each other to reach the Internet. When Mobile Routers have no prior knowledge of one another (no security association, Authentication, Authorization, and Accounting (AAA), Public-Key Infrastructure (PKI), etc.), it could still be acceptable to forward packets, provided that the packets are not tunneled back to the Home Networks.
然而，在一些部署场景中，允许未经授权访问移动节点实际上是可取的。例如，当移动路由器连接到其他移动路由器并形成嵌套的NEMO时，它们相互依赖以到达互联网。当移动路由器彼此没有先验知识（没有安全关联、身份验证、授权和记帐（AAA）、公钥基础设施（PKI）等）时，只要数据包没有通过隧道传回家庭网络，转发数据包仍然是可以接受的。
A Route Optimization mechanism that allows traffic from Mobile Network Nodes to bypass the bi-directional tunnel between a Mobile Router and its Home Agent would be a necessary first step towards a Tit for Tat model, where MRs would benefit from a reciprocal altruism, based on anonymity and innocuousness, to extend the Internet infrastructure dynamically.
允许来自移动网络节点的流量绕过移动路由器与其归属代理之间的双向隧道的路由优化机制将是走向针锋相对模型的必要第一步，在该模型中，MRs将受益于基于匿名性和无害性的互惠利他主义，动态扩展互联网基础设施。
Within a nested mobile network, two Mobile Network Nodes may communicate with each other. Let us consider the previous example illustrated in Figure 1 where MNN and CN2 are sharing a communication session. With NEMO Basic Support, a packet sent from MNN to CN2 will need to be forwarded to the Home Agent of each Mobile Router before reaching CN2, whereas, a packet following the direct path between them need not even leave the mobile network. Readers are referred to Appendix A.3 for detailed illustration of the resulting routing paths.
在嵌套移动网络中，两个移动网络节点可以相互通信。让我们考虑前面的例子，如图1所示，其中MNN和CN2共享通信会话。在NEMO基本支持下，从MNN发送到CN2的数据包需要在到达CN2之前转发到每个移动路由器的归属代理，而沿着它们之间的直接路径的数据包甚至不需要离开移动网络。读者可参考附录A.3，以获得最终布线路径的详细说明。
Apart from the consequences of increased packet delay and packet size, which are discussed in previous sub-sections, there are two additional effects that are undesirable:
除了前面小节中讨论的数据包延迟和数据包大小增加的后果外，还有两个额外的影响是不可取的：
o when the nested mobile network is disconnected from the Internet (e.g., MR1 loses its egress connectivity), MNN and CN2 can no
o 当嵌套移动网络与Internet断开连接时（例如，MR1失去其出口连接），MNN和CN2无法连接
longer communicate with each other, even though the direct path from MNN to CN2 is unaffected;
即使从MNN到CN2的直接路径不受影响，彼此之间的通信时间也更长；
o the egress link(s) of the root Mobile Router (i.e., MR1) becomes a bottleneck for all the traffic that is coming in and out of the nested mobile network.
o 根移动路由器（即MR1）的出口链路成为进出嵌套移动网络的所有流量的瓶颈。
A Route Optimization mechanism could allow traffic between two Mobile Network Nodes nested within the same mobile network to follow a direct path between them, without being routed out of the mobile network. This may also off-load the processing burden of the upstream Mobile Routers when the direct path between the two Mobile Network Nodes does not traverse these Mobile Routers.
路由优化机制可以允许嵌套在同一移动网络中的两个移动网络节点之间的通信遵循它们之间的直接路径，而不会被路由出移动网络。当两个移动网络节点之间的直接路径不穿过这些移动路由器时，这也可以减轻上游移动路由器的处理负担。
Several configurations for the Home Network are described in [10]. In particular, there is a mobile home scenario where a (parent) Mobile Router is also a Home Agent for its mobile network. In other words, the mobile network is itself an aggregation of Mobile Network Prefixes assigned to (children) Mobile Routers.
[10]中描述了家庭网络的几种配置。特别是，存在一个移动家庭场景，（父）移动路由器也是其移动网络的家庭代理。换句话说，移动网络本身就是分配给（子）移动路由器的移动网络前缀的集合。
A stalemate situation exists in the case where the parent Mobile Router visits one of its children. The child Mobile Router cannot find its Home Agent in the Internet and thus cannot establish its MRHA tunnel and forward the visitor's traffic. The traffic from the parent is thus blocked from reaching the Internet, and it will never bind to its own (grandparent) Home Agent. Appendix B gives a detailed illustration of how such a situation can occur.
在父移动路由器访问其一个子路由器的情况下存在僵局。子移动路由器无法在互联网上找到其归属代理，因此无法建立其MRHA隧道并转发访问者的流量。因此，来自父母的流量被阻止进入互联网，并且它永远不会绑定到自己（祖父母）的家庭代理。附录B详细说明了这种情况是如何发生的。
Then again, a Route Optimization mechanism that bypasses the nested tunnel might enable the parent traffic to reach the Internet and let it bind. At that point, the child Mobile Router would be able to reach its parent and bind in turn. Additional nested Route Optimization solutions might also enable the child to locate its Home Agent in the nested structure and bind regardless of whether or not the Internet is reachable.
此外，绕过嵌套隧道的路由优化机制可能使父流量能够到达Internet并让其绑定。在这一点上，子移动路由器将能够到达其父路由器并依次绑定。附加的嵌套路由优化解决方案还可以使子级在嵌套结构中找到其主代理并绑定，而不管是否可以访问Internet。
With current NEMO Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in various inefficiencies associated with packet delivery. This document investigates such inefficiencies and provides the motivation behind Route Optimization for NEMO.
在当前的NEMO基本支持下，当移动网络不在时，与移动网络节点之间的所有通信都必须通过MRHA隧道。这导致与数据包传递相关的各种低效。本文件调查了此类低效情况，并为NEMO提供了路线优化背后的动机。
We have described the sub-optimal effects of pinball routes with NEMO Basic Support, how they may cause a bottleneck to be formed in the Home Network, and how they get amplified with nesting of mobile networks. These effects will also be seen even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. In addition, other issues concerning the nesting of mobile networks that might provide additional motivation for a NEMO Route Optimization mechanism were also explored, such as the prohibition of forwarding traffic from a Visiting Mobile Node through an MRHA tunnel due to security concerns, the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network, and the possibility of a stalemate situation when Home Agents are nested within a mobile network.
我们已经描述了在NEMO基本支持下弹球路线的次优效果，它们如何在家庭网络中形成瓶颈，以及它们如何随着移动网络的嵌套而放大。即使在NEMO基础支持上使用移动IPv6路由优化，也会看到这些影响。此外，还探讨了可能为NEMO路由优化机制提供额外动力的移动网络嵌套的其他问题，例如出于安全考虑，禁止通过MRHA隧道转发来自访问移动节点的流量，MRHA隧道对同一移动网络不同链路上的两个移动网络节点之间通信的影响，以及当归属代理嵌套在移动网络中时出现僵局的可能性。
This document highlights some limitations of NEMO Basic Support. In particular, some security concerns could prevent interesting applications of the protocol, as detailed in Section 2.5.
本文件强调了NEMO基本支持的一些局限性。特别是，如第2.5节所述，一些安全问题可能会妨碍协议的有趣应用。
Route Optimization for RFC 3963 [1] might introduce new threats, just as it might alleviate existing ones. This aspect will certainly be a key criterion in the evaluation of the proposed solutions.
RFC 3963[1]的路由优化可能会引入新的威胁，正如它可能会缓解现有的威胁一样。这方面无疑将是评估拟议解决方案的关键标准。
The authors wish to thank the co-authors of previous versions from which this document is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by Masafumi Watari on the extracted appendix was written while still at Keio University. In addition, sincere appreciation is also extended to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa, and Patrick Wetterwald for their various contributions.
作者希望感谢本文件的前几个版本的共同作者：Marco Molteni、Paik Eun Kyong、Hiroyuki Ohnishi、Thierry Ernst、Felix Wu和Souhwan Jung。Watari Masafumi关于阑尾提取的早期工作是在庆应大学时完成的。此外，我们还衷心感谢贾里·阿尔科、卡洛斯·贝尔纳多斯、格雷格·戴利、T.J.克尼维顿、亨里克·列夫科维茨、埃里克·诺德马克、亚历山德罗·彼得雷斯库、赫萨姆·索利曼、卢吉·瓦基卡瓦和帕特里克·维特瓦尔德所作的各种贡献。
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[1] Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[2] Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[3] Ernst，T.和H.Lach，“网络移动支持术语”，RFC 48852007年7月。
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[4] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[5] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
[5] Ernst，T.，“网络移动性支持目标和要求”，RFC 48862007年7月。
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[7] Deering, S. and B. Zill, "Redundant Address Deletion when Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
[7] Deering，S.和B.Zill，“在IPv6中封装IPv6时删除冗余地址”，正在进行的工作，2001年11月。
[8] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, "Threats for Basic Network Mobility Support (NEMO threats)", Work in Progress, January 2004.
[8] Petrescu，A.，Olivereau，A.，Janneteau，C.，和H-Y.Lach，“基本网络移动支持的威胁（NEMO威胁）”，正在进行的工作，2004年1月。
[9] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat Analysis on NEMO Basic Operations", Work in Progress, July 2004.
[9] Jung，S.，Zhao，F.，Wu，S.，Kim，H-G.，和S-W.Sohn，“NEMO基本作战的威胁分析”，正在进行的工作，2004年7月。
[10] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC RFC4887, July 2007.
[10] Thubert，P.，Wakikawa，R.，和V.Devarapalli，“网络移动家庭网络模型”，RFC RFC4887，2007年7月。
[11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[11] Draves，R.，“因特网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
In the following sections, we try to describe different communication models that involve a nested mobile network and to clarify the issues for each case. We illustrate the path followed by packets if we assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms. Different cases are considered where a Correspondent Node is located in the fixed infrastructure, in a distinct nested mobile network as the Mobile Network Node, or in the same nested mobile network as the Mobile Network Node. Additionally, cases where Correspondent Nodes and Mobile Network Nodes are either standard IPv6 nodes or Mobile IPv6 nodes are considered. As defined in [3], standard IPv6 nodes are nodes with no mobility functions whatsoever, i.e., they are not Mobile IPv6 or NEMO enabled. This means that they cannot move around keeping open connections and that they cannot process Binding Updates sent by peers.
在下面的章节中，我们试图描述涉及嵌套移动网络的不同通信模型，并澄清每种情况下的问题。如果我们假设节点仅使用移动IPv6和NEMO基本支持机制，我们将说明数据包所遵循的路径。考虑不同的情况，其中对应节点位于固定基础设施中，位于作为移动网络节点的不同嵌套移动网络中，或者位于作为移动网络节点的相同嵌套移动网络中。此外，还考虑了对应节点和移动网络节点是标准IPv6节点或移动IPv6节点的情况。如[3]中所定义，标准IPv6节点是没有任何移动功能的节点，即，它们不支持移动IPv6或NEMO。这意味着它们无法保持打开的连接，也无法处理对等方发送的绑定更新。
The most typical configuration is the case where a Mobile Network Node communicates with a Correspondent Node attached in the fixed infrastructure. Figure 3 below shows an example of such topology.
最典型的配置是移动网络节点与连接在固定基础设施中的对应节点通信的情况。下面的图3显示了此类拓扑的示例。
+--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+
| | |
+-------------------------+
| Internet |----+ CN
+-------------------------+
| |
+---+---+ +--+-----+
root-MR | MR1 | | VMN_HA |
+---+---+ +--------+
|
+---+---+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
----+----
MNN
+--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+
| | |
+-------------------------+
| Internet |----+ CN
+-------------------------+
| |
+---+---+ +--+-----+
root-MR | MR1 | | VMN_HA |
+---+---+ +--------+
|
+---+---+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
----+----
MNN
Figure 3: CN Located at the Infrastructure
图3：位于基础设施的CN
The simplest case is where both MNN and CN are fixed nodes with no mobility functions. That is, MNN is a Local Fixed Node, and CN is a standard IPv6 node. Packets are encapsulated between each Mobile Router and its respective Home Agent (HA). As shown in Figure 4, in such a case, the path between the two nodes would go through:
最简单的情况是，MNN和CN都是没有移动功能的固定节点。也就是说，MNN是本地固定节点，CN是标准IPv6节点。数据包封装在每个移动路由器及其各自的归属代理（HA）之间。如图4所示，在这种情况下，两个节点之间的路径将通过：
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node
The digits represent the number of IPv6 headers.
这些数字表示IPv6标头的数量。
Figure 4: MNN and CN Are Standard IPv6 Nodes
图4:MNN和CN是标准IPv6节点
In this second case, both end nodes are Mobile IPv6-enabled mobile nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 Route Optimization may thus be initiated between the two and packets would not go through the Home Agent of the Visiting Mobile Node or the Home Agent of the Correspondent Node (not shown in the figure). However, packets will still be tunneled between each Mobile Router and its respective Home Agent, in both directions. As shown in Figure 5, the path between MNN and CN would go through:
在第二种情况下，两个终端节点都是支持移动IPv6的移动节点，即MNN是访问移动节点。因此，移动IPv6路由优化可以在两者之间启动，并且分组将不会通过访问移动节点的归属代理或对应节点的归属代理（图中未示出）。然而，数据包仍将在每个移动路由器及其各自的归属代理之间双向进行隧道传输。如图5所示，MNN和CN之间的路径将通过：
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6
Figure 5: MNN and CN Are MIPv6 Mobile Nodes
图5:MNN和CN是MIPv6移动节点
When the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed because the standard IPv6 Correspondent Node cannot process Mobile IPv6 signaling. Therefore, MNN would establish a bi-directional tunnel with its HA, which causes the flow to go out the nested NEMO. Packets between MNN and CN would thus go through MNN's own Home Agent (VMN_HA). The path would therefore be as shown in Figure 6:
当通信涉及作为访问移动节点或作为对应节点的移动IPv6节点时，无法执行移动IPv6路由优化，因为标准IPv6对应节点无法处理移动IPv6信令。因此，MNN将利用其HA建立一个双向隧道，从而使水流流出嵌套的NEMO。因此，MNN和CN之间的数据包将通过MNN自己的归属代理（VMN_HA）传递。因此，路径如图6所示：
2 3 4 5 4
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
VMN |
| 3
1 2 |
CN --- VMN_HA --- MR3_HA
IPv6 Node
2 3 4 5 4
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
VMN |
| 3
1 2 |
CN --- VMN_HA --- MR3_HA
IPv6 Node
Figure 6: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
图6:MNN是一个MIPv6移动节点，CN是一个标准IPv6节点
Providing Route Optimization involving a Mobile IPv6 node may require optimization among the Mobile Routers and the Mobile IPv6 node.
提供涉及移动IPv6节点的路由优化可能需要在移动路由器和移动IPv6节点之间进行优化。
The Correspondent Node may be located in another nested mobile network, different from the one MNN is attached to, as shown in Figure 7. We define such configuration as "distinct nested mobile networks".
对应节点可以位于另一个嵌套移动网络中，不同于连接到的MNN，如图7所示。我们将这种配置定义为“不同的嵌套移动网络”。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
| |
+---+---+ +---+---+
root-MR | MR1 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR2 | | MR5 |
+---+---+ +---+---+
| |
+---+---+ ----+----
sub-MR | MR3 | CN
+---+---+
|
----+----
MNN
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
| |
+---+---+ +---+---+
root-MR | MR1 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR2 | | MR5 |
+---+---+ +---+---+
| |
+---+---+ ----+----
sub-MR | MR3 | CN
+---+---+
|
----+----
MNN
Figure 7: MNN and CN Located in Distinct Nested NEMOs
图7：MNN和CN位于不同的嵌套NEMO中
Similar to Case A, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network, decapsulated by the Home Agents, and then encapsulated again on their way down the nested mobile network.
与案例A类似，我们从两个终端节点都没有任何移动功能的案例开始。数据包在离开嵌套移动网络的过程中封装在每个移动路由器上，由归属代理解除封装，然后在沿着嵌套移动网络向下的过程中再次封装。
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node
Figure 8: MNN and CN Are Standard IPv6 Nodes
图8:MNN和CN是标准IPv6节点
Similar to Case B, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization. Again, packets will not go through the Home Agent of the MNN or the Home Agent of the Mobile IPv6 Correspondent Node (not shown in the figure). However, packets will still be tunneled for each Mobile Router to its Home Agent and vice versa. Therefore, the path between MNN and CN would go through:
与情况B类似，当两个终端节点都是移动IPv6节点时，这两个节点可以发起移动IPv6路由优化。同样，数据包不会通过MNN的归属代理或移动IPv6对应节点的归属代理（图中未显示）。但是，每个移动路由器的数据包仍将通过隧道传输到其归属代理，反之亦然。因此，MNN和CN之间的路径将通过：
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
MIPv6 Node
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
MIPv6 Node
Figure 9: MNN and CN Are MIPv6 Mobile Nodes
图9:MNN和CN是MIPv6移动节点
Similar to Case C, when the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 Route Optimization cannot be performed because the standard IPv6 Correspondent Node cannot process Mobile IPv6 signaling. MNN would
与情况C类似，当通信涉及作为访问移动节点或作为对应节点的移动IPv6节点时，无法执行MIPv6路由优化，因为标准IPv6对应节点无法处理移动IPv6信令。MNN会
therefore establish a bi-directional tunnel with its Home Agent. Packets between MNN and CN would thus go through MNN's own Home Agent as shown in Figure 10:
因此，与其国内代理建立双向隧道。因此，MNN和CN之间的数据包将通过MNN自己的归属代理，如图10所示：
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
1 2 3 2 1 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA
IPv6 Node
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
1 2 3 2 1 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA
IPv6 Node
Figure 10: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
图10:MNN是一个MIPv6移动节点，CN是一个标准IPv6节点
Figure 11 below shows the case where the two communicating nodes are connected behind different Mobile Routers that are connected in the same nested mobile network, and thus behind the same root Mobile Router. Route Optimization can avoid packets being tunneled outside the nested mobile network.
下面的图11显示了两个通信节点连接在同一嵌套移动网络中连接的不同移动路由器后面，从而连接在同一根移动路由器后面的情况。路由优化可以避免数据包在嵌套移动网络外被隧道传输。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN
Figure 11: MNN and CN Located in the Same Nested NEMO
图11:MNN和CN位于同一嵌套NEMO中
Again, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network via the root Mobile Router, decapsulated and encapsulated by the Home Agents, and then make their way back to the nested mobile network through the same root Mobile Router. Therefore, the path between MNN and CN would go through:
同样，我们从两个终端节点都没有任何移动功能的情况开始。在通过根移动路由器离开嵌套移动网络的过程中，数据包被封装在每个移动路由器上，由归属代理解除封装和封装，然后通过同一根移动路由器返回嵌套移动网络。因此，MNN和CN之间的路径将通过：
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 12: MNN and CN Are Standard IPv6 nodes
图12:MNN和CN是标准IPv6节点
Similar to Case B and Case E, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization, which will avoid the packets going through the Home Agent of MNN or the Home Agent of the Mobile IPv6 CN (not shown in the figure). However, packets will still be tunneled between each Mobile Router and its respective Home Agent in both directions. Therefore, the path would be the same as with Case G and go through:
与情况B和情况E类似，当两个终端节点都是移动IPv6节点时，两个节点可以发起移动IPv6路由优化，这将避免数据包通过MNN的归属代理或移动IPv6 CN的归属代理（图中未显示）。然而，数据包仍将在每个移动路由器及其各自的归属代理之间双向进行隧道传输。因此，路径将与案例G相同，并通过：
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
MIPv6 Node
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
MIPv6 Node
Figure 13: MNN and CN Are MIPv6 Mobile Nodes
图13:MNN和CN是MIPv6移动节点
As for Case C and Case F, when the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, MNN will establish a bi-directional tunnel with its Home Agent. Packets between MNN and CN would thus go through MNN's own Home Agent. The path would therefore be as shown in Figure 14:
对于情况C和情况F，当通信涉及作为访问移动节点或作为对应节点的移动IPv6节点时，不能执行移动IPv6路由优化。因此，MNN将与其国内代理建立双向隧道。因此，MNN和CN之间的数据包将通过MNN自己的归属代理。因此，路径如图14所示：
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 14: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
图14:MNN是一个MIPv6移动节点，CN是一个标准IPv6节点
Figure 15 below shows the case where the two communicating nodes are connected behind the same nested Mobile Router. The optimization is required when the communication involves MIPv6-enabled nodes.
下面的图15显示了两个通信节点连接在同一嵌套移动路由器后面的情况。当通信涉及启用MIPv6的节点时，需要进行优化。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+---+---+
|
+-------+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
-+--+--+-
MNN CN
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+---+---+
|
+-------+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
-+--+--+-
MNN CN
Figure 15: MNN and CN Located Behind the Same Nested MR
图15：位于同一嵌套MR后面的MNN和CN
If both end nodes are Local Fixed Nodes, no special function is necessary for optimization of their communications. The path between the two nodes would go through:
如果两个终端节点都是本地固定节点，则无需特殊功能来优化其通信。两个节点之间的路径将通过：
1
MNN --- CN
LFN IPv6 Node
1
MNN --- CN
LFN IPv6 Node
Figure 16: MNN and CN Are Standard IPv6 Nodes
图16:MNN和CN是标准IPv6节点
Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization. Although few packets would go out the nested mobile network for the Return Routability initialization, however, unlike Case B and Case E, packets will not get tunneled outside the nested mobile network. Therefore, packets between MNN and CN would eventually go through:
与情况H类似，当两个终端节点都是移动IPv6节点时，这两个节点可以发起移动IPv6路由优化。虽然很少有数据包会出于返回可路由性初始化而离开嵌套移动网络，但是，与情况B和情况E不同，数据包不会在嵌套移动网络外部进行隧道传输。因此，MNN和CN之间的数据包最终将通过：
1
MNN --- CN
VMN MIPv6 Node
1
MNN --- CN
VMN MIPv6 Node
Figure 17: MNN and CN are MIPv6 Mobile Nodes
图17:MNN和CN是MIPv6移动节点
If the root Mobile Router is disconnected while the nodes exchange keys for the Return Routability procedure, they may not communicate even though they are connected on the same link.
如果根移动路由器在节点交换返回路由程序密钥时断开连接，则即使它们连接在同一链路上，它们也可能无法通信。
When the communication involves a Mobile IPv6 node either as a Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, even though the two nodes are on the same link, MNN will establish a bi-directional tunnel with its Home Agent, which causes the flow to go out the nested mobile network. The path between MNN and CN would require another Home Agent (VMN_HA) to go through for this Mobile IPv6 node:
当通信涉及作为访问移动网络节点或作为对应节点的移动IPv6节点时，无法执行移动IPv6路由优化。因此，即使两个节点在同一条链路上，MNN也会与其归属代理建立一个双向隧道，从而使流量流出嵌套的移动网络。MNN和CN之间的路径需要另一个归属代理（VMN_HA）通过此移动IPv6节点：
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
IPv6 Node
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
IPv6 Node
Figure 18: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
图18:MNN是一个MIPv6移动节点，CN是一个标准IPv6节点
However, MNN may also decide to use its Care-of Address (CoA) as the source address of the packets, thus avoiding the tunneling with the MNN's Home Agent. This is particularly useful for a short-term communications that may easily be retried if it fails. Default Address Selection [11] provides some mechanisms for controlling the choice of the source address.
然而，MNN还可以决定使用其转交地址（CoA）作为分组的源地址，从而避免与MNN的归属代理的隧道。这对于短期通信特别有用，如果通信失败，很容易重试。默认地址选择[11]提供了一些控制源地址选择的机制。
Section 2.7 describes the occurrence of a stalemate situation where a Home Agent of a Mobile Router is nested behind the Mobile Router. Here, we illustrate a simple example where such a situation can occur.
第2.7节描述了一种僵局情况的发生，即移动路由器的归属代理嵌套在移动路由器后面。这里，我们举一个简单的例子来说明这种情况可能发生的地方。
Consider a mobility configuration depicted in Figure 19 below. MR1 is served by HA1/BR and MR2 is served by HA2. The 'BR' designation indicates that HA1 is a border router. Both MR1 and MR2 are at home in the initial step. HA2 is placed inside the first mobile network, thus representing a "mobile" Home Agent.
考虑下面图19所示的移动性配置。MR1由HA1/BR提供服务，MR2由HA2提供服务。“BR”表示HA1是边界路由器。在最初的步骤中，MR1和MR2都在家里。HA2被放置在第一移动网络内，因此代表“移动”归属代理。
/-----CN
+----------+
home link 1 +--------+ | |
----+-----------------| HA1/BR |---| Internet |
| +--------+ | |
| +----------+
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
-+--------+-- mobile net 1 / home link 2
|
+--+--+ +--+--+
| MR2 | | LFN |
+--+--+ +--+--+
| |
-+--------+- mobile net 2
/-----CN
+----------+
home link 1 +--------+ | |
----+-----------------| HA1/BR |---| Internet |
| +--------+ | |
| +----------+
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
-+--------+-- mobile net 1 / home link 2
|
+--+--+ +--+--+
| MR2 | | LFN |
+--+--+ +--+--+
| |
-+--------+- mobile net 2
Figure 19: Initial Deployment
图19：初步部署
In Figure 19 above, communications between CN and LFN follow a direct path as long as both MR1 and MR2 are positioned at home. No encapsulation intervenes.
在上面的图19中，只要MR1和MR2都位于家中，CN和LFN之间的通信遵循直接路径。没有封装介入。
In the next step, consider that the MR2's mobile network leaves home and visits a foreign network, under Access Router (AR) like in Figure 20 below.
在下一个步骤中，考虑MR2的移动网络离开家，访问接入路由器（AR）下的外部网络，如下面的图20所示。
/-----CN
+----------+
home link 1 +--------+ | |
--+-----------| HA1/BR |---| Internet |
| +--------+ | |
+--+--+ +-----+ +----------+
| MR1 | | HA2 | \
+--+--+ +--+--+ +-----+
| | | AR |
-+--------+- mobile net 1 +--+--+
home link 2 |
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
/-----CN
+----------+
home link 1 +--------+ | |
--+-----------| HA1/BR |---| Internet |
| +--------+ | |
+--+--+ +-----+ +----------+
| MR1 | | HA2 | \
+--+--+ +--+--+ +-----+
| | | AR |
-+--------+- mobile net 1 +--+--+
home link 2 |
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
Figure 20: Mobile Network 2 Leaves Home
图20：移动网络2离开家
Once MR2 acquires a Care-of Address under AR, the tunnel setup procedure occurs between MR2 and HA2. MR2 sends a Binding Update to HA2 and HA2 replies with a Binding Acknowledgement to MR2. The bi-directional tunnel has MR2 and HA2 as tunnel endpoints. After the tunnel MR2HA2 has been set up, the path taken by a packet from CN towards LFN can be summarized as:
一旦MR2获得AR下的转交地址，隧道设置程序将在MR2和HA2之间进行。MR2向HA2发送绑定更新，HA2向MR2回复绑定确认。双向隧道将MR2和HA2作为隧道端点。隧道MR2HA2建立后，数据包从CN到LFN的路径可以总结为：
CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.
CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN。
Non-encapsulated packets are marked "->" while encapsulated packets are marked "=>".
非封装数据包标记为“->”，而封装数据包标记为“=>”。
Consider next the attachment of the first mobile network under the second mobile network, like in Figure 21 below.
考虑下一个移动网络在第二移动网络下的连接，如下面的图21所示。
After this movement, MR1 acquires a Care-of Address valid in the second mobile network. Subsequently, it sends a Binding Update (BU) message addressed to HA1. This Binding Update is encapsulated by MR2 and sent towards HA2, which is expected to be placed in mobile net 1 and expected to be at home. Once HA1/BR receives this encapsulated BU, it tries to deliver to MR1. Since MR1 is not at home, and a tunnel has not yet been set up between MR1 and HA1, HA1 is not able to route this packet and drops it. Thus, the tunnel establishment procedure between MR1 and HA1 is not possible, because the tunnel between MR2 and HA2 had been previously torn down (when the mobile net 1 moved from home). The communications between CN and LFN stops, even though both mobile networks are connected to the Internet.
在该移动之后，MR1获取在第二移动网络中有效的转交地址。随后，它向HA1发送一条绑定更新（BU）消息。此绑定更新由MR2封装并发送到HA2，HA2预计将放置在移动网络1中，并将在家中。一旦HA1/BR收到这个封装的BU，它就会尝试传递给MR1。由于MR1不在家，而且在MR1和HA1之间还没有建立隧道，HA1无法路由该数据包并丢弃它。因此，MR1和HA1之间的隧道建立程序是不可能的，因为MR2和HA2之间的隧道先前已经被拆除（当移动网络1从家中移动时）。CN和LFN之间的通信停止，即使两个移动网络都连接到Internet。
/-----CN
+----------+
+--------+ | |
| HA1/BR |---| Internet |
+--------+ | |
+----------+
\
+-----+
| AR |
+--+--+
|
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
|
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
mobile net 1 -+--------+-
/-----CN
+----------+
+--------+ | |
| HA1/BR |---| Internet |
+--------+ | |
+----------+
\
+-----+
| AR |
+--+--+
|
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
|
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
mobile net 1 -+--------+-
Figure 21: Stalemate Situation Occurs
图21：出现僵局的情况
If both tunnels between MR1 and HA1, and between MR2 and HA2, were up simultaneously, they would have "crossed over" each other. If the tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be noticed that the path of the tunnel MR1-HA1 includes only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels are crossing over each other if the IP path between two endpoints of one tunnel includes one and only one endpoint of the other tunnel (assuming that both tunnels are up). When both endpoints of one tunnel are included in the path of the other tunnel, then tunnels are simply encapsulating each other.
如果MR1和HA1之间以及MR2和HA2之间的两条隧道同时开通，它们就会相互“交叉”。如果隧道MR1-HA1和MR2-HA2如图21所示，可以注意到隧道MR1-HA1的路径仅包括隧道MR2-HA2的一个端点（MR2端点）。如果一个隧道的两个端点之间的IP路径包括且仅包括另一个隧道的一个端点，则两个MR-HA隧道相互交叉（假设两个隧道都已连接）。当一个隧道的两个端点都包含在另一个隧道的路径中时，隧道只是彼此封装。
Authors' Addresses
作者地址
Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate, Singapore 534415 SG
陈华吴松下新加坡实验室私人有限公司，地址：新加坡泰生大道1022号，邮编：534415
Phone: +65 65505420
EMail: chanwah.ng@sg.panasonic.com
Phone: +65 65505420
EMail: chanwah.ng@sg.panasonic.com
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 FRANCE
Pascal Thubert Cisco Systems Village d'Enterprises Green Side 400，法国索菲亚安提波利斯市比奥区鲁曼尼耶大道T3号，邮编：06410
EMail: pthubert@cisco.com
EMail: pthubert@cisco.com
Masafumi Watari KDDI R&D Laboratories Inc. 2-1-15 Ohara Fujimino, Saitama 356-8502 JAPAN
日本Saitama Ohara Fujimino第2-1-15号大原藤野市Masafumi Watari KDDI研发实验室有限公司356-8502
EMail: watari@kddilabs.jp
EMail: watari@kddilabs.jp
Fan Zhao UC Davis One Shields Avenue Davis, CA 95616 US
范昭加州大学戴维斯分校美国加利福尼亚州戴维斯市希尔兹大道一号，邮编95616
Phone: +1 530 752 3128
EMail: fanzhao@ucdavis.edu
Phone: +1 530 752 3128
EMail: fanzhao@ucdavis.edu
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。