Network Working Group C. Ng Request for Comments: 4889 Panasonic Singapore Labs Category: Informational F. Zhao UC Davis M. Watari KDDI R&D Labs P. Thubert Cisco Systems July 2007 Network Mobility Route Optimization Solution Space Analysis 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).
AbstractWith current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Benefits of NEMO Route Optimization . . . . . . . . . . . . . 4 3. Different Scenarios of NEMO Route Optimization . . . . . . . . 6 3.1. Non-Nested NEMO Route Optimization . . . . . . . . . . . . 6 3.2. Nested Mobility Optimization . . . . . . . . . . . . . . . 8 3.2.1. Decreasing the Number of Home Agents on the Path . . . 8 3.2.2. Decreasing the Number of Tunnels . . . . . . . . . . . 9 3.3. Infrastructure-Based Optimization . . . . . . . . . . . . 9 3.4. Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 10 4. Issues of NEMO Route Optimization . . . . . . . . . . . . . . 11
4.1. Additional Signaling Overhead . . . . . . . . . . . . . . 11 4.2. Increased Protocol Complexity and Processing Load . . . . 12 4.3. Increased Delay during Handoff . . . . . . . . . . . . . . 12 4.4. Extending Nodes with New Functionalities . . . . . . . . . 13 4.5. Detection of New Functionalities . . . . . . . . . . . . . 14 4.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Mobility Transparency . . . . . . . . . . . . . . . . . . 14 4.8. Location Privacy . . . . . . . . . . . . . . . . . . . . . 15 4.9. Security Consideration . . . . . . . . . . . . . . . . . . 15 4.10. Support of Legacy Nodes . . . . . . . . . . . . . . . . . 15 5. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 16 5.1. Which Entities Are Involved? . . . . . . . . . . . . . . . 16 5.1.1. Mobile Network Node and Correspondent Node . . . . . . 16 5.1.2. Mobile Router and Correspondent Node . . . . . . . . . 17 5.1.3. Mobile Router and Correspondent Router . . . . . . . . 17 5.1.4. Entities in the Infrastructure . . . . . . . . . . . . 18 5.2. Who Initiates Route Optimization? When? . . . . . . . . . 18 5.3. How Is Route Optimization Capability Detected? . . . . . . 19 5.4. How is the Address of the Mobile Network Node Represented? . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. How Is the Mobile Network Node's Address Bound to Location? . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5.1. Binding to the Location of Parent Mobile Router . . . 21 5.5.2. Binding to a Sequence of Upstream Mobile Routers . . . 23 5.5.3. Binding to the Location of Root Mobile Router . . . . 24 5.6. How Is Signaling Performed? . . . . . . . . . . . . . . . 26 5.7. How Is Data Transmitted? . . . . . . . . . . . . . . . . . 27 5.8. What Are the Security Considerations? . . . . . . . . . . 28 5.8.1. Security Considerations of Address Binding . . . . . . 28 5.8.2. End-to-End Integrity . . . . . . . . . . . . . . . . . 30 5.8.3. Location Privacy . . . . . . . . . . . . . . . . . . . 30 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . . 33
1] describes operational limitations and overheads incurred in a deployment of Network Mobility (NEMO) Basic Support , which could be alleviated by a set of NEMO Route Optimization techniques to be defined. The term "Route Optimization" is used in a broader sense than already defined for IPv6 Host Mobility in  to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node. Solutions that would fit that general description were continuously proposed since the early days of NEMO, even before the Working Group was formed. Based on that long-standing stream of innovation, this document classifies, at a generic level, the solution space of the possible approaches that could be taken to solve the Route Optimization-related problems for NEMO. The scope of the solutions, the benefits, and the impacts to the existing implementations and deployments are analyzed. This work should serve as a foundation for the NEMO WG to decide where to focus its Route Optimization effort, with a deeper understanding of the relative strengths and weaknesses of each approach. It should be beneficial for readers to keep in mind the design requirements of NEMO . A point to note is that since this document discusses aspects of Route Optimization, the reader may assume that a mobile network or a mobile host is away when they are mentioned throughout this document, unless it is explicitly specified that they are at home. 3] and , and NEMO-related terms defined in . In addition, the following Route Optimization-specific terms are used in this document: Correspondent Router (CR) This refers to the router that is capable of terminating a Route Optimization session on behalf of a Correspondent Node. Correspondent Entity (CE) This refers to the entity that a Mobile Router or Mobile Network Node attempts to establish a Route Optimization session with. Depending on the Route Optimization approach, the Correspondent Entity may be a Correspondent Node or Correspondent Router.
1]. Although a standardized NEMO Route Optimization solution has yet to materialize, one can expect it to show some of the following benefits: o Shorter Delay Route Optimization involves the selection and utilization of a lesser-cost (thus generally shorter and faster) route to be taken for traffic between a Mobile Network Node and its Correspondent Node. Hence, Route Optimization should improve the latency of the data traffic between the two end nodes. This may in turn lead to better overall Quality of Service characteristics, such as reduced jitter and packet loss. o Reduced Consumption of Overall Network Resources Through the selection of a shorter route, the total link utilization for all links used by traffic between the two end nodes should be much lower than that used if Route Optimization is not carried out. This would result in a lighter network load with reduced congestion. o Reduced Susceptibility to Link Failure If a link along the bi-directional tunnel is disrupted, all traffic to and from the mobile network will be affected until IP routing recovers from the failure. An optimized route would conceivably utilize a smaller number of links between the two end nodes. Hence, the probability of a loss of connectivity due to a single point of failure at a link should be lower as compared to the longer non-optimized route. o Greater Data Efficiency Depending on the actual solution for NEMO Route Optimization, the data packets exchanged between two end nodes may not require as many levels of encapsulation as that in NEMO Basic Support. This would mean less packet overheads and higher data efficiency. In particular, avoiding packet fragmentation that may be induced by the multiple levels of tunneling is critical for end-to-end efficiency from the viewpoints of buffering and transport protocols.
o Reduced Processing Delay In a nested mobile network, the application of Route Optimization may eliminate the need for multiple encapsulations required by NEMO Basic Support, which may result in less processing delay at the points of encapsulation and decapsulation. o Avoiding a Bottleneck in the Home Network NEMO Route Optimization allows traffic to bypass the Home Agents. Apart from having a more direct route, this also avoids routing traffic via the home network, which may be a potential bottleneck otherwise. o Avoid the Security Policy Issue Security policy may forbid a Mobile Router from tunneling traffic of Visiting Mobile Nodes into the home network of the Mobile Router. Route Optimization can be used to avoid this issue by forwarding traffic from Visiting Mobile Nodes directly to their destinations without going through the home network of the Mobile Router. However, it should be taken into consideration that a Route Optimization mechanism may not be an appropriate solution since the Mobile Router may still be held responsible for illegal traffic sent from its Mobile Network Nodes even when Route Optimization is used. In addition, there can be a variety of different policies that might conflict with the deployment of Route Optimization for Visiting Mobile Nodes. Being a policy issue, solving this with a protocol at the policy plane might be more appropriate. o Avoid the Instability and Stalemate  described a potential stalemate situation when a Home Agent is nested within a mobile network. Route Optimization may circumvent such stalemate situations by directly forwarding traffic upstream. However, it should be noted that certain Route Optimization schemes may require signaling packets to be first routed via the Home Agent before an optimized route can be established. In such cases, a Route Optimization solution cannot avoid the stalemate.
Figure 1. ************************** HAofMR * #*# * #*# +---------------------+ CN #*# | LEGEND | o #*# +---------------------+ o ############### #*# | #: Tunnel | CR ooooooooooooooo MR | *: NEMO Basic route | ############### | | o: Optimized route | MNN +---------------------+ Figure 1: MR-CR Optimization This form of optimization can carry traffic in both directions or independently for the two directions of traffic: o From MNN to CN The Mobile Router locates the Correspondent Router, establishes a tunnel with that Correspondent Router and sets up a route to the Correspondent Node via the Correspondent Router over the tunnel. Traffic to the Correspondent Node would no longer flow through the Home Agent anymore.
o From CN to MNN The Correspondent Router is on the path of the traffic from the Correspondent Node to the Home Agent. In addition, it has an established tunnel with the current Care-of Address (CoA) of the Mobile Router and is aware of the Mobile Network Prefix(es) managed by the Mobile Router. The Correspondent Router can thus intercept packets going to the mobile network, and forward them to the Mobile Router over the established tunnel. A straightforward approach to Route Optimization in NEMO is for the Mobile Router to attempt Route Optimization with a Correspondent Entity. This can be viewed as a logical extension to NEMO Basic Support, where the Mobile Router would send Binding Updates containing one or more Mobile Network Prefix options to the Correspondent Entity. The Correspondent Entity, having received the Binding Update, can then set up a bi-directional tunnel with the Mobile Router at the current Care-of Address of the Mobile Router, and inject a route to its routing table so that packets destined for addresses in the Mobile Network Prefix will be routed through the bi- directional tunnel. The definition of Correspondent Router does not limit it to be a fixed router. Here we consider the case where the Correspondent Router is a Mobile Router. Thus, Route Optimization is initiated and performed between a Mobile Router and its peer Mobile Router. Such solutions are often posed with a requirement to leave the Mobile Network Nodes untouched, as with the NEMO Basic Support protocol, and therefore Mobile Routers handle the optimization management on behalf of the Mobile Network Nodes. Thus, providing Route Optimization for a Visiting Mobile Node is often out of scope for such a scenario because such interaction would require extensions to the Mobile IPv6 protocol. This scenario is illustrated in Figure 2. HAofCR ********************************** HAofMR #*# #*# #*# #*# +---------------------+ #*# #*# | LEGEND | #*# #*# +---------------------+ #*# ############### #*# | #: Tunnel | CR ooooooooooooooo MR | *: NEMO Basic route | | ############### | | o: Optimized route | MNN2 MNN1 +---------------------+ Figure 2: MR-MR Optimization
This form of optimization can carry traffic for both directions identically: o MNN1 to/from MNN2 The Mobile Router locates the Correspondent Router, establishes a tunnel with that Correspondent Router, and sets up a route to the Mobile Network Node via the Correspondent Router over the tunnel. Traffic to the Mobile Networks Nodes would no longer flow through the Home Agents. Examples of this approach include Optimized Route Cache (ORC)  and Path Control Header (PCH) . 10].
10], Access Router Option (ARO) , and Nested Path Info (NPI) . 13] to optimize routes between themselves. Another example is to make use of proxy Home Agent such as defined in the global Home Agent to Home Agent (HAHA) protocol . A proxy Home Agent acts as a Home Agent for the Mobile Node, and acts as a Mobile Node for the Home Agent, Correspondent Node, Correspondent Router, and other proxies. In particular, the proxy Home Agent terminates the MRHA tunnel and the associated encryption, extracts the packets, and re- encapsulates them to the destination. In this case, proxy Home Agents are distributed in the infrastructure and each Mobile Router binds to the closest proxy. The proxy, in turn, performs a primary binding with a real Home Agent for that Mobile Router. Then, the proxy might establish secondary bindings with other Home Agents or proxies in the infrastructure, in order to improve the end-to-end path. In this case, the proxies discover each other using some form of Next Hop Resolution Protocol, establish a tunnel and exchange the relevant Mobile Network Prefix information in the form of explicit prefix routes. Alternatively, another approach is to use prefix delegation. Here, each Mobile Router in a nested mobile network is delegated a Mobile Network Prefix from the access router using DHCP Prefix Delegation . Each Mobile Router also autoconfigures its Care-of Address from this delegated prefix. In this way, the Care-of Addresses of each Mobile Router are all formed from an aggregatable address space
starting from the access router. This may be used to eliminate the multiple tunnels caused by nesting of Mobile Nodes. Figure 3 below. +--------+ +--------+ +--------+ +--------+ | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +------------------------------+ | MR1_HA |----| Internet |-----CN +--------+ +--------------+---------------+ | +----+----+ | MR1 | +----+----+ | ---+-----------+-----------+--- | | | +---+---+ +---+---+ +---+---+ | MR5 | | MR2 | | MR4 | +---+---+ +---+---+ +---+---+ | | | ---+--- +---+---+ ---+--- MNN2 | MR3 | MNN3 +---+---+ | ----+---- MNN1 Figure 3: An Example of a Nested Mobile Network One may be able to extend a well-designed NEMO Route Optimization for "Nested Mobility Optimization" (see Section 3.2) to provide for such kind of Intra-NEMO optimization, where, for example in Figure 3, MNN1 is treated as a Correspondent Node by MR5/MNN2, and MNN2 is treated as a Correspondent Node by MR3/MNN1. Another possibility is for the "Non-Nested NEMO Route Optimization" technique (see Section 3.1) to be applied here. Using the same example of communication between MNN1 and MNN2, both MR3 and MR2 can
treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and MR2 as Correspondent Routers for MNN1. An example of this approach is , which has the Mobile Routers announce their Mobile Network Prefixes to other Mobile Routers in the same nested Mobile Network. Yet another approach is to flatten any nested Mobile Network so that all nested Mobile Network Nodes appear to be virtually on the same link. Examples of such approaches include delegating a single prefix to the nested Mobile Network, having Mobile Routers to perform Neighbor Discovery on behalf of their Mobile Network Nodes, and exposing a single prefix over the entire mobile network using a Mobile Ad-Hoc (MANET) protocol. In particular, it might prove useful to develop a new type of MANET, specialized for the NEMO problem, a MANET for NEMO (MANEMO). The MANEMO will optimize the formation of the nested NEMO and maintain inner connectivity, whether or not a connection to the infrastructure can be established. Section 2, the scenarios described in Section 3 do so with some tradeoffs. This section explores some general issues that may impact a NEMO Route Optimization mechanism.
signaling messages over a longer period of time, or aggregating the signaling messages. Even so, the amount of signaling required might be overwhelming, since large mobile networks (such as those deployed on a train or plane) may potentially have a large number of flows with a large number of Correspondent Nodes. This might suggest a need to have some adaptive behavior that depends on the amount of signaling required versus the effort needed to tunnel home. Section 4.7 and Section 4.8), this mechanism also increases the delay during handoffs. Some of the solutions for Mobile IPv6, such as Fast Handovers for Mobile IPv6 , may be able to alleviate the increase in handoff delay.
o Correspondent Nodes It may prove to be difficult to introduce new functionalities at Correspondent Nodes, since by definition, any IPv6 node can be a Correspondent Node. This might mean that only those Correspondent Nodes that are modified can enjoy the benefits of Route Optimization. o Correspondent Routers Correspondent Routers are new entities introduced for the purpose of Route Optimization, and therefore new functionalities can be defined as needed. Section 4.4 is the need to detect the existence of such functionalities. In these cases, a detection mechanism might be helpful to allow the initiator of Route Optimization to detect whether support for the new functionalities is available. Furthermore, it might be advantageous to have a graceful fall back procedure if the required functionalities are unavailable.
18] and Route Optimization. In Mobile IPv6, a mobile node can decide whether or not to perform Route Optimization with a given Correspondent Node. Thus, the mobile node is in control of whether to trade location privacy for an optimized route. In NEMO Route Optimization, if the decision to perform Router Optimization is made by the Mobile Router, it will be difficult for Mobile Network Nodes to control the decision of having this tradeoff. 19].
Section 3, there are various different approaches to achieve Route Optimization in Network Mobility Support. In this section, we attempt to analyze the vast solution space of NEMO Route Optimization by asking the following questions: 1. Which entities are involved? 2. Who initiates Route Optimization? When? 3. How is Route Optimization capabilities detected? 4. How is the address of the Mobile Network Node represented? 5. How is the Mobile Network Node's address bound to location? 6. How is signaling performed? 7. How is data transmitted? 8. What are the security considerations? Section 4.4 and Section 4.5. Below is a list of combinations to be discussed in the following sub-sections: o Mobile Network Node and Correspondent Node o Mobile Router and Correspondent Node o Mobile Router and Correspondent Router o Entities in the Infrastructure
new functionalities would be required for both the Mobile Network Node and Correspondent Node. For the Mobile Network Node, it needs to be able to manage its mobility, and possibly be aware of the mobility of its upstream Mobile Router(s). For the Correspondent Node, it needs to be able to maintain the bindings sent by the Mobile Network Nodes. Section 5.1.1, the scalability issue here may be remedied since it is possible for the Correspondent Node to maintain only one session with the Mobile Router if it communicates with many Mobile Network Nodes associated with the same Mobile Router. Furthermore, with the Mobile Router handling Route Optimization, there is no need for Mobile Network Nodes to implement new functionalities. However, new functionality is likely to be required on the Correspondent Node. An additional point of consideration is the amount of state information the Mobile Router is required to maintain. Traditionally, it has been generally avoided having state information in the routers to increase proportionally with the number of pairs of communicating peers. Section 3.1. The advantage of these approaches is that no additional functionality is required for the Correspondent Node and Mobile Network Nodes. In addition, location privacy is relatively preserved, since the current location of the mobile network is only revealed to the Correspondent Router and not to the Correspondent Node (please refer to Section 5.8.3 for more discussions). Furthermore, if the Mobile Router and Correspondent Router exchange prefix information, this approach may scale well since a single Route Optimization session between the Mobile Router and Correspondent Router can achieve Route Optimization between any Mobile Network Node in the mobile network, and any Correspondent Node managed by the Correspondent Router. The main concern with this approach is the need for a mechanism to allow the Mobile Router to detect the presence of the Correspondent Router (see Section 5.3 for details), and its security impact. Both the Mobile Router and the Correspondent Router need some means to verify the validity of each other. This is discussed in greater detail in Section 5.8.
A deployment consideration with respect to the use of Correspondent Router is the location of the Correspondent Router relative to the Correspondent Node. On one hand, deploying the Correspondent Router nearer to the Correspondent Node would result in a more optimal path. On the other hand, a Correspondent Router that is placed farther away from the Correspondent Node can perform Route Optimization on behalf of more Correspondent Nodes. Section 3.3. The advantages of this approach include, firstly, not requiring new functionalities to be implemented on the Mobile Network Nodes and Correspondent Nodes, and secondly, having most of the complexity shifted to nodes in the infrastructure. However, one main issue with this approach is how the Mobile Router can detect the presence of such entities, and why the Mobile Router should trust these entities. This may be easily addressed if such entity is a Home Agent of the Mobile Router (such as in the global Home Agent to Home Agent protocol ). Another concern is that the resulting path may not be a true optimized one, since it depends on the relative positions of the infrastructure entities with respect to the mobile network and the Correspondent Node. Section 4.3. Some solution may enable the node on the correspondent side to initiate the Route Optimization session in certain situations. For instance, when the Route Optimization state that is already established on the Correspondent Entity is about to expire but the communication is still active, depending on the policy, the Correspondent Entity may initiate a Route Optimization request with the mobile node side.
There is also the question of when Route Optimization should be initiated. Because Route Optimization would certainly incur tradeoffs of various forms, it might not be desirable for Route Optimization to be performed for any kind of traffic. This is, however, implementation specific and policy driven. A related question is how often signaling messages should be sent to maintain the Route Optimization session. Typically, signaling messages are likely to be sent whenever there are topological changes. The discussion in Section 4.1 should be considered. In addition, a Lifetime value is often used to indicate the period of validity for the Route Optimization session. Signaling messages would have to be sent before the Lifetime value expires in order to maintain the Route Optimization session. The choice of Lifetime value needs to balance between different considerations. On one hand, a short Lifetime value would increase the amount of signaling overhead. On the other hand, a long Lifetime value may expose the Correspondent Entity to the risk of having an obsolete binding cache entry, which creates an opportunity for an attacker to exploit. 7]. Only the Correspondent Router that is capable of terminating the Route Optimization session on behalf of the Correspondent Node will respond. Another way is to insert a Router Alert Option (RAO) into a packet sent to the Correspondent Node . Any Correspondent Router en route will process the Router Alert Option and send a response to the Mobile Router.
Both approaches need to consider the possibility of multiple Correspondent Routers responding to the initiator, and both approaches will generate additional traffic or processing load to other routers. Furthermore, both approaches have yet to consider how the initiator can verify the authenticity of the Correspondent Routers that responded. Section 5.5), one must first ask how the address of the Mobile Network Node is represented. Basically, there are two ways to represent the Mobile Network Node's address: o inferred by the use of the Mobile Network Prefix, or o explicitly specifying the address of the Mobile Network Node. Using the Mobile Network Prefix would usually mean that the initiator is the Mobile Router, and has the benefit of binding numerous Mobile Network Nodes with one signaling. However, it also means that if location privacy is compromised, the location privacy of an entire Mobile Network Prefix would be compromised. On the other hand, using the Mobile Network Node's address would mean that either the initiator is the Mobile Network Node itself or the Mobile Router is initiating Route Optimization on behalf of the Mobile Network Node. Initiation by the Mobile Network Node itself means that the Mobile Network Node must have new functionalities implemented, while initiation by the Mobile Router means that the Mobile Router must maintain some Route Optimization states for each Mobile Network Node.
These are described in the following sub-sections. Section 5.4). o Sending Information of Parent Mobile Router This involves the Mobile Network Node sending the information of its Mobile Router to the Correspondent Entity, thus allowing the Correspondent Entity to establish a binding between the address of the Mobile Network Node to the location of the parent Mobile Router. An example of such an approach would be . o Mobile Router as a Proxy Another approach is for the parent Mobile Router to act as a "proxy" for its Mobile Network Nodes. In this case, the Mobile Router uses the standard Mobile IPv6 Route Optimization procedure to bind the address of a Mobile Network Node to the Mobile Router's Care-of Address. For instance, when the Mobile Network Node is a Local Fixed Node without Mobile IPv6 Route Optimization functionality, the Mobile Router may initiate the Return Routability procedure with a Correspondent Node on behalf of the Local Fixed Node. An example of such an approach would be . On the other hand, if the Mobile Network Node is a Visiting Mobile Node, it might be necessary for the Visiting Mobile Node to delegate the rights of Route Optimization signaling to the Mobile
Router (see  for an example of such delegation). With this delegation, either the Visiting Mobile Network Node or the Mobile Router can initiate the Return Routability procedure with the Correspondent Node. For the case where the Return Routability procedure is initiated by the Visiting Mobile Node, the Mobile Router will have to transparently alter the content of the Return Routability signaling messages so that packets sent from the Correspondent Node to the Visiting Node will be routed to the Care-of Address of the Mobile Router once Route Optimization is established. The case where the Return Routability procedure is initiated by the Mobile Router is similar to the case where the Mobile Network Node is a Local Fixed Node. For all of the approaches listed above, when the Mobile Network Node is deeply nested within a Mobile Network, the Correspondent Entity would need to gather Binding Updates from all the upstream Mobile Routers in order to build the complete route to reach the Mobile Network Node. This increases the complexity of the Correspondent Entity, as the Correspondent Entity may need to perform multiple binding cache look-ups before it can construct the complete route. Other than increasing the complexity of the Correspondent Entity, these approaches may incur extra signaling overhead and delay for a nested Mobile Network Node. For instance, every Mobile Router on the upstream of the Mobile Network Node needs to send Binding Updates to the Correspondent Entity. If this is done by the upstream Mobile Routers independently, it may incur additional signaling overhead. Also, since each Binding Update takes a finite amount of time to reach and be processed by the Correspondent Entity, the delay from the time an optimized route is changed till the time the change is registered on the Correspondent Entity will increase proportionally with the number of Mobile Routers on the upstream of the Mobile Network Node (i.e., the level of nesting of the Mobile Network Node). For "Binding Update with Mobile Network Prefix" and "Sending Information of Parent Mobile Router", new functionality is required at the Correspondent Entity, whereas "Mobile Router as a Proxy" keeps the functionality of the Correspondent Entity the same as a Mobile IPv6 Correspondent Node. However, this is done at an expense of the Mobile Routers, since in "Mobile Router as a Proxy", the Mobile Router must maintain state information for every Route Optimization session its Mobile Network Nodes have. Furthermore, in some cases, the Mobile Router needs to look beyond the standard IPv6 headers for ingress and egress packets, and alter the packet contents appropriately (this may impact end-to-end integrity, see 5.8.2). One advantage shared by all the approaches listed here is that only mobility protocol is affected. In other words, no modification is
required on other existing protocols (such as Neighbor Discovery). There is also no additional requirement on existing infrastructure (such as the access network). In addition, having upstream Mobile Routers send Binding Updates independently means that the Correspondent Entity can use the same binding cache entries of upstream Mobile Routers to construct the complete route to two Mobile Network Nodes that have common upstream Mobile Routers. This may translate to lower memory consumption since the Correspondent Entity need not store one complete route per Mobile Network Node when it is having Route Optimization sessions with multiple Mobile Network Nodes from the same mobile network. 10] and . Different from Section 5.5.1, this approach constructs the complete route to a specific Mobile Network Node at the mobile network side, thus offering the opportunity to reduce the signaling overhead. Since the complete route is conveyed to the Correspondent Entity in a single transmission, it is possible to reduce the delay from the time an optimized route is changed till the time the change is registered on the Correspondent Entity to its minimum. One question that immediately comes to mind is how the Mobile Network Node gets hold of the sequence of locations of its upstream Mobile Routers. This is usually achieved by having such information inserted as special options in the Router Advertisement messages advertised by upstream Mobile Routers. To do so, not only must a Mobile Router advertise its current location to its Mobile Network Nodes, it must also relay information embedded in Router Advertisement messages it has received from its upstream Mobile Routers. This might imply a compromise of the mobility transparency of a mobile network (see Section 4.7). In addition, it also means that whenever an upstream Mobile Router changes its point of attachment, all downstream Mobile Network Nodes must perform Route Optimization signaling again, possibly leading to a "Signaling Storm" (see Section 4.1). A different method of conveying locations of upstream Mobile Routers is (such as used in ) where upstream Mobile Routers insert their current point of attachment into a Reverse Routing Header embedded
within a packet sent by the Mobile Network Node. This may raise security concerns that will be discussed later in Section 5.8.2. In order for a Correspondent Entity to bind the address of a Mobile Network Node to a sequence of locations of upstream Mobile Routers, new functionalities need to be implemented on the Correspondent Entity. The Correspondent Entity also needs to store the complete sequence of locations of upstream Mobile Routers for every Mobile Network Node. This may demand more memory compared to Section 5.5.1 if the same Correspondent Entity has a lot of Route Optimization sessions with Mobile Network Nodes from the same nested Mobile Network. In addition, some amount of modifications or extension to existing protocols is also required, such as a new type of IPv6 routing header or a new option in the Router Advertisement message. 15]). Each Mobile Router also autoconfigures its Care-of Address from this delegated prefix. In this way, the Care-of Addresses of Mobile Routers are all from an aggregatable address space starting from the access router. A Mobile Network Node with Mobile IPv6 functionality may also autoconfigure its Care-of Address from this delegated prefix, and use standard Mobile IPv6 mechanism's to bind its Home Address to this Care-of Address. Examples of this approach include , , and . This approach has the advantage of keeping the implementations of Correspondent Nodes unchanged. However, it requires the access
router (or some other entity within the access network) and Mobile Router to possess prefix delegation functionality, and also maintain information on what prefix is delegated to which node. How to efficiently assign a subset of Mobile Network Prefix to child Mobile Routers could be an issue because Mobile Network Nodes may dynamically join and leave with an unpredictable pattern. In addition, a change in the point of attachment of the root Mobile Router will also require every nested Mobile Router (and possibly Visiting Mobile Nodes) to change their Care-of Addresses and delegated prefixes. These will cause a burst of Binding Updates and prefix delegation activities where every Mobile Router and every Visiting Mobile Node start sending Binding Updates to their Correspondent Entities. o Neighbor Discovery Proxy This approach (such as  and ) achieves Route Optimization by having the Mobile Router act as a Neighbor Discovery  proxy for its Mobile Network Nodes. The Mobile Router will configure a Care-of Address from the network prefix advertised by its access router, and also relay this prefix to its subnets. When a Mobile Network Node configures an address from this prefix, the Mobile Router will act as a Neighbor Discovery proxy on its behalf. In this way, the entire mobile network and its access network form a logical multilink subnet, thus eliminating any nesting. This approach has the advantage of keeping the implementations of Correspondent Nodes unchanged. However, it requires the root Mobile Router to act as a Neighbor Discovery proxy for all the Mobile Network Nodes that are directly or indirectly attached to it. This increases the processing load of the root Mobile Router. In addition, a change in the point of attachment of the root Mobile Router will require every nested Mobile Router (and possibly Visiting Mobile Nodes) to change their Care-of Addresses. Not only will this cause a burst of Binding Updates where every Mobile Router and every Visiting Mobile Node start sending Binding Updates to their Correspondent Entities, it will also cause a burst of Duplicate Address Discovery messages to be exchanged between the mobile network and the access network. Furthermore, Route Optimization for Local Fixed Nodes is not possible without new functionalities implemented on the Local Fixed Nodes. o Hierarchical Registrations Hierarchical Registration involves Mobile Network Nodes (including nested Mobile Routers) registering themselves with either their parent Mobile Routers or the root Mobile Router itself. After registrations, Mobile Network Nodes would tunnel packets directly
to the upstream Mobile Router they register with. At the root Mobile Router, packets tunneled from sub-Mobile Routers or Mobile Network Nodes are tunneled directly to the Correspondent Entities, thus avoiding nested tunneling. One form of such an approach uses the principle of Hierarchical Mobile IPv6 , where the root Mobile Router acts as a Mobility Anchor Point. It is also possible for each parent Mobile Router to act as Mobility Anchor Points for its child Mobile Routers, thus forming a hierarchy of Mobility Anchor Points. One can also view these Mobility Anchor Points as local Home Agents, thus forming a cascade of mobile Home Agents. In this way, each Mobile Router terminates its tunnel at its parent Mobile Router. Hence, although there are equal numbers of tunnels as the level of nestings, there is no tunnel encapsulated within another. Examples of this approach include , , , and . An advantage of this approach is that the functionalities of the Correspondent Nodes are unchanged. o Mobile Ad-Hoc Routing It is possible for nodes within a mobile network to use Mobile Ad- hoc routing for packet-forwarding between nodes in the same mobile network. An approach of doing so might involve a router acting as a gateway for connecting nodes in the mobile network to the global Internet. All nodes in the mobile network would configure their Care-of Addresses from one or more prefixes advertised by that gateway, while their parent Mobile Routers use Mobile Ad-hoc routing to forward packets to that gateway or other destinations inside the mobile network. One advantage that is common to all the approaches listed above is that local mobility of a Mobile Network Node within a nested mobile network is hidden from the Correspondent Entity. 10]. Off-plane signaling uses dedicated signaling packets rather than embedding signaling information into headers of data packets. Proposals involving the sending of Binding Updates fall into this category.
The advantage of in-plane signaling is that any change in the mobile network topology can be rapidly propagated to the Correspondent Entity as long as there is a continuous stream of data to be transmitted. However, this might incur a substantial overhead on the data packets. Off-plane signaling, on the other hand, sends signaling messages independently from the data packet. This has the advantage of reducing the signaling overhead in situations where there are relatively fewer topological changes to the mobile network. However, data packet transmission may be disrupted while off-plane signaling takes place. An entirely different method of signaling makes use of upper-layer protocols to establish the bindings between the address of a Mobile Network Node and the location of the mobile network. Such binding information can then be passed down to the IP layer to insert the appropriate entry in the Binding Cache or routing table. An example of such a mechanism is , which uses the Session Initiation Protocol (SIP) to relay binding information. 35]. In this way, the original packet can be tunneled to the location bound to the address of the Mobile Network Node using the normal routing infrastructure. Depending on how the location is bound to the address of the Mobile Network Node, the number of encapsulations required might vary. For instance, if the Correspondent Entity knows the full sequence of points of attachment, it might be necessary for there to be multiple encapsulations in order to forward the data packet through each point of attachment. This may lead to the need for multiple tunnels and extra packet header overhead. It is possible to alleviate this by using Robust Header Compression techniques  to compress the multiple tunnel packet headers. o Routing Headers A second way to route packets through the optimized path is to use routing headers. This is useful especially for the case where the Correspondent Entity knows the sequence of locations of upstream Mobile Routers (see Section 5.5.2), since a routing header can
contain multiple intermediate destinations. Each intermediate destination corresponds to a point of attachment bound to the address of the Mobile Network Node. This requires the use of a new Routing Header type, or possibly an extension of the Type 2 Routing Header as defined by Mobile IPv6 to contain multiple addresses instead of only one. o Routing Entries in Parent Mobile Routers Yet another way is for parent Mobile Routers to install routing entries in their routing table that will route Route Optimized packets differently, most likely based on source address routing. This usually applies to approaches described in Section 5.5.3. For instance, the Prefix Delegation approach  would require parent Mobile Routers to route packets differently if the source address belongs to the prefix delegated from the access network. 19], such as snooping (sending packets meant for a Mobile Network Node to an attacker) or denial-of-service (DoS) (flooding a victim with packets meant for a Mobile Network Node) attacks. When the binding is performed between the address of the Mobile Network Node and one Care-of Address (possibly of the Mobile Router; see Section 5.5.1 and Section 5.5.3), the standard Return Routability procedure specified in Mobile IPv6 might be sufficient to provide a reasonable degree of assurance to the Correspondent Entity. This also allows the Correspondent Entity to re-use existing implementations. But in other situations, an extension to the Return Routability procedure might be necessary. For instance, consider the case where the Mobile Router sends a Binding Update containing Mobile Network Prefix information to the Correspondent Entity (see Section 5.5.1). Although the Return
Routability procedure allows the Correspondent Entity to verify that the Care-of and Home Addresses of the Mobile Router are indeed collocated, it does not allow the Correspondent Entity to verify the validity of the Mobile Network Prefix. If the Correspondent Entity accepts the binding without verification, it will be exposed to attacks where the attacker tricks the Correspondent Entity into forwarding packets destined for a mobile network to the attacker (snooping) or victim (DoS);  discusses this security threat further. The need to verify the validity of network prefixes is not constrained to Correspondent Entities. In approaches that involve the Correspondent Routers (see Section 5.1.3), there have been suggestions for the Correspondent Router to advertise the network prefix(es) of Correspondent Nodes that the Correspondent Router is capable of terminating Route Optimization on behalf of to Mobile Network Nodes. In such cases, the Mobile Network Nodes also need a mechanism to check the authenticity of such claims. Even if the Correspondent Routers do not advertise the network prefix, the Mobile Network Nodes also have the need to verify that the Correspondent Router is indeed a valid Correspondent Router for a given Correspondent Node. In Section 5.5.2, the registration signaling involves sending the information about one or more upstream Mobile Routers. The Correspondent Entity (or Home Agent) must also have the means to verify such information. Again, the standard Return Routability procedure as defined in  is inadequate here, as it is not designed to verify the reachability of an address over a series of upstream routers. An extension such as attaching a routing header to the Care-of Test (CoT) message to verify the authenticity of the locations of upstream Mobile Routers is likely to be needed. The risk, however, is not confined to Correspondent Entities. The Mobile Network Nodes are also under the threat of receiving false information from their upstream Mobile Routers, which they might pass to Correspondent Entities (this also implies that Correspondent Entities cannot rely on any security associations they have with the Mobile Network Nodes to establish the validity of address bindings). There are some considerations that this kind of on-path threat exists in the current Internet anyway especially when no (or weak) end-to- end protection is used. All these concerns over the authenticity of addresses might suggest that perhaps a more radical and robust approach is necessary. This is currently under extensive study in various Working Groups of the IETF, and many related documents might be of interest here. For instance, in Secure Neighbor Discovery (SEND) , Cryptographically Generated Addresses (CGAs)  could be used to establish the
ownership of Care-of Addresses.  employs the Home Agent to check the signaling messages sent by Mobile Routers to provide a way for Correspondent Entities to verify the authenticity of Mobile Network Prefixes specified.  documents various proposed enhancements to the Mobile IPv6 Route Optimization mechanism that might be applied to NEMO Route Optimization as well, such as , which allows the Correspondent Entity to authenticate a certain operator's Home Agent by verifying the associated certificate. The Host Identity Protocol (HIP)  with end-host mobility considerations  may be extended for NEMO Route Optimization as well. In addition, interested readers might want to refer to , which discussed the general problem of making Route Optimization in NEMO secure and explored some possible solution schemes. There is also a proposed mechanism in  for Mobile Network Node to delegate some rights to their Mobile Routers, which may be used to allow the Mobile Routers to prove their authenticities to Correspondent Entities when establishing Route Optimization sessions on behalf of the Mobile Network Nodes. Section 5.5.1, the Mobile Router sends messages using the Mobile Network Node's address as the source address. This is done mainly to achieve zero new functionalities required at the Correspondent Entities and the Mobile Network Nodes. However, adopting such a strategy may interfere with existing or future protocols, most particularly security-related protocols. This is especially true when the Mobile Router needs to make changes to packets sent by Mobile Network Nodes. In a sense, these approaches break the end-to- end integrity of packets. A related concern is that this kind of approach may also require the Mobile Router to inspect the packet contents sent to/by Mobile Network Nodes. This may prove to be difficult or impossible if such contents are encrypted. The concern over end-to-end integrity arises for the use of a Reverse Routing Header (see Section 5.5.2) too, since Mobile Routers would insert new contents to the header of packets sent by downstream Mobile Network Nodes. This makes it difficult for Mobile Network Nodes to protect the end-to-end integrity of such information with security associations.
that aspect, please refer to . Instead, we consider the following three aspects to location privacy: o Revelation of Location to Correspondent Entity Route optimization is achieved by creating a binding between the address of the Mobile Network Node and the current location of the Mobile Network. It is thus inevitable that the location of the Mobile Network Node be revealed to the Correspondent Entity. The concern may be alleviated if the Correspondent Entity is not the Correspondent Node, since this implies that the actual traffic end point (i.e., the Correspondent Node) would remain ignorant of the current location of the Mobile Network Node. o Degree of Revelation With network mobility, the degree of location exposure varies, especially when one considers nested mobile networks. For instance, for approaches that bind the address of the Mobile Network Node to the location of the root Mobile Router (see Section 5.5.3), only the topmost point of attachment of the mobile network is revealed to the Correspondent Entity. For approaches such as those described in Section 5.5.1 and Section 5.5.2, more information (such as Mobile Network Prefixes and current locations of upstream Mobile Routers) is revealed. Techniques such as exposing only locally-scoped addresses of intermediate upstream mobile routers to Correspondent Entities may be used to reduce the degree of revelation. o Control of the Revelation When Route Optimization is initiated by the Mobile Network Node itself, it is in control of whether or not to sacrifice location privacy for an optimized route. However, if it is the Mobile Router that initiates Route Optimization (e.g., "Binding Update with Mobile Network Prefix" and "Mobile Router as a Proxy" in Section 5.5.1), then control is taken away from the Mobile Network Node. An additional signaling mechanism between the Mobile Network Node and its Mobile Router can be used in this case to prevent the Mobile Router from attempting Route Optimization for a given traffic stream.
this document attempts to present a detailed and in-depth analysis of the NEMO Route Optimization solution space by first describing the benefits a Route Optimization solution is expected to bring, then illustrating the different scenarios in which a Route Optimization solution applies, and next presenting some issues a Route Optimization solution might face. We have also asked ourselves some of the basic questions about a Route Optimization solution. By investigating different possible answers to these questions, we have explored different aspects to a Route Optimization solution. The intent of this work is to enhance our common understanding of the Route Optimization problem and solution space. Section 4.9 for a brief discussion of the security concern with respect to Route Optimization in general, and Section 5.8 for a more detailed analysis of the various Route Optimization approaches.  Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.  Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
 Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.  Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.  Wakikawa, R., Koshiba, S., Uehara, K., and J. Murai, "ORC: Optimized Route Cache Management Protocol for Network Mobility", 10th International Conference on Telecommunications, vol 2, pp 1194-1200, February 2003.  Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol (ORC)", Work in Progress, November 2004.  Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Route Optimization Scheme based on Path Control Header", Work in Progress, April 2004.  Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", Work in Progress, February 2007.  Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization with Access Router Option", Work in Progress, July 2004.  Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Secure Nested Tunnels Optimization using Nested Path Information", Work in Progress, September 2003.  Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.  Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA protocol", Work in Progress, September 2006.  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.  Baek, S., Yoo, J., Kwon, T., Paik, E., and M. Nam, "Routing Optimization in the same nested mobile network", Work in Progress, October 2005.  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
 Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.  Bernardos, C., Bagnulo, M., and M. Calderon, "MIRON: MIPv6 Route Optimization for NEMO", 4th Workshop on Applications and Services in Wireless Network, Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf, August 2004.  Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. Oliva, "Design and Experimental Evaluation of a Route Optimisation Solution for NEMO", IEEE Journal on Selected Areas in Communications (J-SAC), vol 24, no 9, September 2006.  Bernardos, C., Bagnulo, M., Calderon, M., and I. Soto, "Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", Work in Progress, July 2005.  Ylitalo, J., "Securing Route Optimization in NEMO", Workshop of 12th Network and Distributed System Security Syposuim, NDSS Workshop 2005, online: http://www.isoc.org/isoc/conferences/ ndss/05/workshop/ylitalo.pdf, February 2005.  Perera, E., Lee, K., Kim, H., and J. Park, "Extended Network Mobility Support", Work in Progress, July 2003.  Lee, K., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", 58th IEEE Vehicular Technology Conference, vol 3, pp 2035-2038, October 2003.  Lee, K., Jeong, J., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", Work in Progress, February 2004.  Jeong, J., Lee, K., Park, J., and H. Kim, "Route Optimization based on ND-Proxy for Mobile Nodes in IPv6 Mobile Network", 59th IEEE Vehicular Technology Conference, vol 5, pp 2461-2465, May 2004.  Jeong, J., Lee, K., Kim, H., and J. Park, "ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network", Work in Progress, February 2004.
 Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.  Kang, H., Kim, K., Han, S., Lee, K., and J. Park, "Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router", Work in Progress, June 2003.  Lee, D., Lim, K., and M. Kim, "Hierarchical FRoute Optimization for Nested Mobile Network", 18th Int'l Conf on Advance Information Networking and Applications, vol 1, pp 225-229, 2004.  Takagi, Y., Ohnishi, H., Sakitani, K., Baba, K., and S. Shimojo, "Route Optimization Methods for Network Mobility with Mobile IPv6", IEICE Trans. on Comms, vol E87-B, no 3, pp 480- 489, March 2004.  Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route optimization method in a mobile network", Work in Progress, October 2003.  Lee, C., Zheng, J., and C. HUang, "SIP-based Network Mobility (SIP-NEMO) Route Optimization (RO)", Work in Progress, October 2006.  Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.  Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.  Minaburo, A., Paik, E., Toutain, L., and J. Bonnin, "ROHC (Robust Header Compression) in NEMO network", Work in Progress, July 2005.  Ng, C. and J. Hirano, "Extending Return Routability Procedure for Network Prefix (RRNP)", Work in Progress, October 2004.  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
 Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.  Zhao, F., Wu, F., and S. Jung, "Extensions to Return Routability Test in MIP6", Work in Progress, February 2005.  Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-based Binding Update Protocol (CBU)", Work in Progress, March 2005.  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", Work in Progress, April 2007.  Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, March 2007.  Calderon, M., Bernardos, C., Bagnulo, M., and I. Soto, "Securing Route Optimization in NEMO", Third International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, WIOPT 2005, pages 248-254, April 2005.
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 email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.