summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4888.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4888.txt')
-rw-r--r--doc/rfc/rfc4888.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc4888.txt b/doc/rfc/rfc4888.txt
new file mode 100644
index 0000000..8a0ca9b
--- /dev/null
+++ b/doc/rfc/rfc4888.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+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).
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 1]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 2]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+1. Introduction
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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].
+
+2. NEMO Route Optimization Problem Statement
+
+ 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.
+
+ 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
+
+
+
+Ng, et al. Informational [Page 3]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ 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.
+
+2.1. Sub-Optimality with NEMO Basic Support
+
+ 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:
+
+ o Longer Route Leading to Increased Delay and Additional
+ Infrastructure Load
+
+ 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.
+
+ 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
+
+ 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
+
+
+
+
+Ng, et al. Informational [Page 4]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ 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!
+
+ o Increased Processing Delay
+
+ 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.
+
+ o Increased Chances of Packet Fragmentation
+
+ 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.
+
+ o Increased Susceptibility to Link Failure
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 5]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+2.2. Bottleneck in the Home Network
+
+ 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.
+
+ 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.
+
+2.3. Amplified Sub-Optimality in Nested Mobile Networks
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 6]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ +--------+ +--------+ +--------+ +--------+
+ | 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
+
+ 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.
+
+ ----------.
+ ---------/ /----------.
+ -------/ | | /-------
+ MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
+ MR3-------\ | | \-------MR3_HA
+ MR2--------\ \----------MR2_HA
+ MR1---------MR1_HA
+
+ Figure 2: Nesting of Bi-Directional Tunnels
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 7]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ This leads to the following problems:
+
+ o Pinball Route
+
+ 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.
+
+ o Increased Packet Size
+
+ 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.
+
+ 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.
+
+2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Ng, et al. Informational [Page 8]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+2.5. Security Policy Prohibiting Traffic from Visiting Nodes
+
+ 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.
+
+ 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.
+
+ 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.
+
+2.6. Instability of Communications within a Nested Mobile Network
+
+ 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.
+
+ 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
+
+
+
+
+Ng, et al. Informational [Page 9]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ longer communicate with each other, even though the direct path
+ from MNN to CN2 is unaffected;
+
+ 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.
+
+ 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.
+
+2.7. Stalemate with a Home Agent Nested in a Mobile Network
+
+ 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.
+
+ 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.
+
+ 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.
+
+3. Conclusion
+
+ 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.
+
+
+
+
+
+
+Ng, et al. Informational [Page 10]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ 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.
+
+4. Security Considerations
+
+ 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.
+
+ 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.
+
+5. Acknowledgments
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 11]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+6. References
+
+6.1. Normative Reference
+
+ [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
+ "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
+ January 2005.
+
+ [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
+ RFC 3753, June 2004.
+
+ [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
+ RFC 4885, July 2007.
+
+6.2. Informative Reference
+
+ [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+ IPv6", RFC 3775, June 2004.
+
+ [5] Ernst, T., "Network Mobility Support Goals and Requirements",
+ RFC 4886, July 2007.
+
+ [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications",
+ RFC 1889, January 1996.
+
+ [7] Deering, S. and B. Zill, "Redundant Address Deletion when
+ Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
+
+ [8] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach,
+ "Threats for Basic Network Mobility Support (NEMO threats)",
+ Work in Progress, January 2004.
+
+ [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.
+
+ [10] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
+ Mobility Home Network Models", RFC RFC4887, July 2007.
+
+ [11] Draves, R., "Default Address Selection for Internet Protocol
+ version 6 (IPv6)", RFC 3484, February 2003.
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 12]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+Appendix A. Various Configurations Involving Nested Mobile Networks
+
+ 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.
+
+A.1. CN Located in the Fixed Infrastructure
+
+ 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.
+
+ +--------+ +--------+ +--------+
+ | 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
+
+
+
+
+Ng, et al. Informational [Page 13]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+A.1.1. Case A: LFN and Standard IPv6 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:
+
+
+ 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.
+
+
+ Figure 4: MNN and CN Are Standard IPv6 Nodes
+
+A.1.2. Case B: VMN and MIPv6 CN
+
+ 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:
+
+
+ 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
+
+A.1.3. Case C: VMN and Standard IPv6 CN
+
+ 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:
+
+
+
+
+Ng, et al. Informational [Page 14]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ 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
+
+ Providing Route Optimization involving a Mobile IPv6 node may require
+ optimization among the Mobile Routers and the Mobile IPv6 node.
+
+A.2. CN Located in Distinct Nested NEMOs
+
+ 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".
+
+ +--------+ +--------+ +--------+ +--------+
+ | 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
+
+
+
+
+
+
+Ng, et al. Informational [Page 15]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+A.2.1. Case D: LFN and Standard IPv6 CN
+
+ 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.
+
+
+ 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
+
+A.2.2. Case E: VMN and MIPv6 CN
+
+ 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:
+
+
+ 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
+
+A.2.3. Case F: VMN and Standard IPv6 CN
+
+ 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
+
+
+
+Ng, et al. Informational [Page 16]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ 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:
+
+
+
+ 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
+
+A.3. MNN and CN Located in the Same Nested NEMO
+
+ 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.
+
+ +--------+ +--------+ +--------+ +--------+
+ | 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
+
+
+
+
+Ng, et al. Informational [Page 17]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ Figure 11: MNN and CN Located in the Same Nested NEMO
+
+A.3.1. Case G: LFN and Standard IPv6 CN
+
+ 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:
+
+
+ 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
+
+A.3.2. Case H: VMN and MIPv6 CN
+
+ 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:
+
+
+ 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
+
+
+
+
+
+
+Ng, et al. Informational [Page 18]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+A.3.3. Case I: VMN and Standard IPv6 CN
+
+ 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:
+
+
+ 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
+
+A.4. CN Located Behind the Same Nested MR
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 19]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ +--------+ +--------+ +--------+ +--------+
+ | 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
+
+A.4.1. Case J: LFN and Standard IPv6 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
+
+
+ Figure 16: MNN and CN Are Standard IPv6 Nodes
+
+A.4.2. Case K: VMN and MIPv6 CN
+
+ 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:
+
+
+
+
+Ng, et al. Informational [Page 20]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ 1
+ MNN --- CN
+ VMN MIPv6 Node
+
+
+ Figure 17: MNN and CN are MIPv6 Mobile Nodes
+
+ 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.
+
+A.4.3. Case L: VMN and Standard IPv6 CN
+
+ 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:
+
+
+ 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
+
+ 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.
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 21]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+Appendix B. Example of How a Stalemate Situation Can Occur
+
+ 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.
+
+ 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.
+
+ /-----CN
+ +----------+
+ home link 1 +--------+ | |
+ ----+-----------------| HA1/BR |---| Internet |
+ | +--------+ | |
+ | +----------+
+ +--+--+ +-----+
+ | MR1 | | HA2 |
+ +--+--+ +--+--+
+ | |
+ -+--------+-- mobile net 1 / home link 2
+ |
+ +--+--+ +--+--+
+ | MR2 | | LFN |
+ +--+--+ +--+--+
+ | |
+ -+--------+- mobile net 2
+
+ Figure 19: Initial Deployment
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 22]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ /-----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
+
+ 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:
+
+ 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.
+
+ 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.
+
+
+
+
+
+Ng, et al. Informational [Page 23]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+ /-----CN
+ +----------+
+ +--------+ | |
+ | HA1/BR |---| Internet |
+ +--------+ | |
+ +----------+
+ \
+ +-----+
+ | AR |
+ +--+--+
+ |
+ +--+--+ +-----+
+ | MR2 | | LFN |
+ +--+--+ +--+--+
+ | |
+ mobile net 2 -+--------+-
+ |
+ +--+--+ +-----+
+ | MR1 | | HA2 |
+ +--+--+ +--+--+
+ | |
+ mobile net 1 -+--------+-
+
+ Figure 21: Stalemate Situation Occurs
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 24]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+Authors' Addresses
+
+ Chan-Wah Ng
+ Panasonic Singapore Laboratories Pte Ltd
+ Blk 1022 Tai Seng Ave #06-3530
+ Tai Seng Industrial Estate, Singapore 534415
+ SG
+
+ 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
+
+ EMail: pthubert@cisco.com
+
+
+ Masafumi Watari
+ KDDI R&D Laboratories Inc.
+ 2-1-15 Ohara
+ Fujimino, Saitama 356-8502
+ JAPAN
+
+ EMail: watari@kddilabs.jp
+
+
+ Fan Zhao
+ UC Davis
+ One Shields Avenue
+ Davis, CA 95616
+ US
+
+ Phone: +1 530 752 3128
+ EMail: fanzhao@ucdavis.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 25]
+
+RFC 4888 NEMO RO Problem Statement July 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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.
+
+ 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.
+
+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.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Ng, et al. Informational [Page 26]
+