diff options
Diffstat (limited to 'doc/rfc/rfc4889.txt')
| -rw-r--r-- | doc/rfc/rfc4889.txt | 2131 |
1 files changed, 2131 insertions, 0 deletions
diff --git a/doc/rfc/rfc4889.txt b/doc/rfc/rfc4889.txt new file mode 100644 index 0000000..0e59716 --- /dev/null +++ b/doc/rfc/rfc4889.txt @@ -0,0 +1,2131 @@ + + + + + + +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). + +Abstract + + With 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. + +Table of Contents + + 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 + + + +Ng, et al. Informational [Page 1] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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 + + + + + + + + + + + + + + +Ng, et al. Informational [Page 2] + +RFC 4889 NEMO RO Space Analysis July 2007 + + +1. Introduction + + Network Mobility Route Optimization Problem Statement [1] describes + operational limitations and overheads incurred in a deployment of + Network Mobility (NEMO) Basic Support [2], 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 [3] 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 [4]. 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. + +1.1. Terminology + + It is expected that readers are familiar with terminologies related + to mobility in [3] and [5], and NEMO-related terms defined in [6]. + 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. + + + +Ng, et al. Informational [Page 3] + +RFC 4889 NEMO RO Space Analysis July 2007 + + +2. Benefits of NEMO Route Optimization + + NEMO Route Optimization addresses the problems discussed in [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. + + + + + + +Ng, et al. Informational [Page 4] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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 + + [1] 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. + + + + + + + + + +Ng, et al. Informational [Page 5] + +RFC 4889 NEMO RO Space Analysis July 2007 + + +3. Different Scenarios of NEMO Route Optimization + + There are multiple proposals for providing various forms of Route + Optimization in the NEMO context. In the following sub-sections, we + describe the different scenarios that would require a Route + Optimization mechanism and list the potential solutions that have + been proposed in that area. + +3.1. Non-Nested NEMO Route Optimization + + The Non-Nested NEMO Route Optimization involves a Mobile Router + sending binding information to a Correspondent Entity. It does not + involve nesting of Mobile Routers or Visiting Mobile Nodes. The + Correspondent Entity can be a Correspondent Node or a Correspondent + Router. The interesting case is when the Correspondent Entity is a + Correspondent Router. With the use of Correspondent Router, Route + Optimization session is terminated at the Correspondent Router on + behalf of the Correspondent Node. As long as the Correspondent + Router is located "closer" to the Correspondent Node than the Home + Agent of the Mobile Router, the route between Mobile Network Node and + the Correspondent Node can be said to be optimized. For this + purpose, Correspondent Routers may be deployed to provide an optimal + route as illustrated in 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. + + + + + +Ng, et al. Informational [Page 6] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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 + + + + + + +Ng, et al. Informational [Page 7] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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) [7][8] + and Path Control Header (PCH) [9]. + +3.2. Nested Mobility Optimization + + Optimization in Nested Mobility targets scenarios where a nesting of + mobility management protocols is created (i.e., Mobile IPv6-enabled + host inside a mobile network or multiple Mobile Routers that attach + behind one another creating a nested mobile network). Note that + because Mobile IPv6 defines its own Route Optimization mechanism in + its base protocol suite as a standard, collaboration between this and + NEMO protocols brings various complexities. + + There are two main aspects in providing optimization for Nested + Mobility, and they are discussed in the following sub-sections. + +3.2.1. Decreasing the Number of Home Agents on the Path + + The aim is to remove the sub-optimality of paths caused by multiple + tunnels established between multiple Mobile Nodes and their Home + Agents. Such a solution will seek to minimize the number of Home + Agents along the path, by bypassing some of the Home Agent(s) from + the original path. Unlike the scenario where no nesting is formed + and only a single Home Agent exists along the path, bypassing one of + the many Home Agents can still be effective. + + Solutions for Nested Mobility scenarios can usually be divided into + two cases based on whether the nesting involves Mobile IPv6 hosts or + only involves Mobile Routers. Since Mobile IPv6 defines its own + Route Optimization mechanism, providing an optimal path for such + hosts will require interaction with the protocol and may require an + altering of the messages exchanged during the Return Routability + procedure with the Correspondent Node. + + An example of this approach include Reverse Routing Header (RRH) + [10]. + + + + +Ng, et al. Informational [Page 8] + +RFC 4889 NEMO RO Space Analysis July 2007 + + +3.2.2. Decreasing the Number of Tunnels + + The aim is to reduce the amplification effect of nested tunnels due + to the nesting of tunnels between the Visiting Mobile Node and its + Home Agent within the tunnel between the parent Mobile Router and the + parent Mobile Router's Home Agent. Such a solution will seek to + minimize the number of tunnels, possibly by collapsing the amount of + tunnels required through some form of signaling between Mobile Nodes, + or between Mobile Nodes and their Home Agents, or by using routing + headers to route packets through a discovered path. These limit the + consequences of the amplification effect of nested tunnels, and at + best, the performance of a nested mobile network will be the same as + though there were no nesting at all. + + Examples of this approach include the Reverse Routing Header (RRH) + [10], Access Router Option (ARO) [11], and Nested Path Info (NPI) + [12]. + +3.3. Infrastructure-Based Optimization + + An infrastructure-based optimization is an approach where + optimization is carried out fully in the infrastructure. One example + is to make use of Mobility Anchor Points (MAPs) such as defined in + HMIPv6 [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 [14]. 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 + [15]. 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 + + + + +Ng, et al. Informational [Page 9] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + starting from the access router. This may be used to eliminate the + multiple tunnels caused by nesting of Mobile Nodes. + +3.4. Intra-NEMO Optimization + + A Route Optimization solution may seek to improve the communications + between two Mobile Network Nodes within a nested mobile network. + This would avoid traffic being injected out of the nested mobile + network and route them within the nested mobile network. An example + is the optimized route taken between MNN1 and MNN2 in 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 + + + +Ng, et al. Informational [Page 10] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and + MR2 as Correspondent Routers for MNN1. An example of this approach + is [16], 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. + +4. Issues of NEMO Route Optimization + + Although Route Optimization can bring benefits as described in + 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. + +4.1. Additional Signaling Overhead + + The nodes involved in performing Route Optimization would be expected + to exchange additional signaling messages in order to establish Route + Optimization. The required amount of signaling depends on the + solution, but is likely to exceed the amount required in the home + Binding Update procedure defined in NEMO Basic Support. The amount + of signaling is likely to increase with the increasing number of + Mobile Network Nodes and/or Correspondent Nodes, and may be amplified + with nesting of mobile networks. It may scale to unacceptable + heights, especially to the resource-scarce mobile node, which + typically has limited power, memory, and processing capacity. + + This may lead to an issue that impacts NEMO Route Optimization, known + as the phenomenon of "Binding Update Storm", or more generally, + "Signaling Storm". This occurs when a change in point of attachment + of the mobile network is accompanied with a sudden burst of signaling + messages, resulting in temporary congestion, packet delays, or even + packet loss. This effect will be especially significant for wireless + environment where bandwidth is relatively limited. + + It is possible to moderate the effect of Signaling Storm by + incorporating mechanisms such as spreading the transmissions burst of + + + + +Ng, et al. Informational [Page 11] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +4.2. Increased Protocol Complexity and Processing Load + + It is expected that NEMO Route Optimization will be more complicated + than NEMO Basic Support. Thus, complexity of nodes that are required + to incorporate new functionalities to support NEMO Route Optimization + would be higher than those required to provide NEMO Basic Support. + + Coupled with the increased complexity, nodes that are involved in the + establishment and maintenance of Route Optimization will have to bear + the increased processing load. If such nodes are mobile, this may + prove to be a significant cost due to the limited power and + processing resources such devices usually have. + +4.3. Increased Delay during Handoff + + Due to the diversity of locations of different nodes that Mobile + Network Node may signal with and the complexity of NEMO Route + Optimization procedure that may cause several rounds of signaling + messages, a NEMO Route Optimization procedure may take a longer time + to finish its handoff than that in NEMO Basic Support. This may + exacerbate the overall delay during handoffs and further cause + performance degradation of the applications running on Mobile Network + Nodes. + + Another NEMO-specific delay during handoff is that in a nested mobile + network, a child Mobile Network Node may need to detect or be + notified of the handoff of its parent Mobile Router so that it can + begin signaling its own Correspondent Entities. Apart from the + compromise of mobility transparency and location privacy (see + 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 [17], may be able to alleviate the increase in handoff + delay. + + + + + + +Ng, et al. Informational [Page 12] + +RFC 4889 NEMO RO Space Analysis July 2007 + + +4.4. Extending Nodes with New Functionalities + + In order to support NEMO Route Optimization, some nodes need to be + changed or upgraded. Smaller number of nodes required to be changed + will allow for easier adoption of the NEMO Route Optimization + solution in the Internet and create less impact on existing Internet + infrastructure. The number and the types of nodes involved with new + functionalities also affect how much of the route is optimized. In + addition, it may also be beneficial to reuse existing protocols (such + as Mobile IPv6) as much as possible. + + Possible nodes that may be required to change include the following: + + o Local Fixed Nodes + + It may prove to be difficult to introduce new functionalities at + Local Fixed Nodes, since by definition, any IPv6 node can be a + Local Fixed Node. This might mean that only those Local Fixed + Nodes that are modified can enjoy the benefits of Route + Optimization. + + o Visiting Mobile Nodes + + Visiting Mobile Nodes in general should already implement Mobile + IPv6 functionalities, and since Mobile IPv6 is a relatively new + standard, there is still a considerable window to allow mobile + devices to implement new functionalities. + + o Mobile Routers + + It is expected that Mobile Routers will implement new + functionalities in order to support Route Optimization. + + o Access Routers + + Some approaches require access routers, or nodes in the access + network, to implement some new functionalities. It may prove to + be difficult to do so, since access routers are, in general, + standard IPv6 routers. + + o Home Agents + + It is relatively easier for new functionalities to be implemented + in Home Agents. + + + + + + + +Ng, et al. Informational [Page 13] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +4.5. Detection of New Functionalities + + One issue that is related to the need for new functionalities as + described in 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. + +4.6. Scalability + + Given the same number of nodes, the number of Route Optimization + sessions would usually be more than the number of NEMO Basic Support + tunnels. If all Route Optimization sessions of a mobile network are + maintained by a single node (such as the Mobile Router), this would + mean that the single node has to keep track of the states of all + Route Optimization sessions. This may lead to scalability issues + especially when that single node is a mobile device with limited + memory and processing resources. + + A similar scalability issue may be faced by a Correspondent Entity as + well if it maintains many route-optimized sessions on behalf of a + Correspondent Node(s) with a large number of Mobile Routers. + +4.7. Mobility Transparency + + One advantage of NEMO Basic Support is that the Mobile Network Nodes + need not be aware of the actual location and mobility of the mobile + network. With some approaches for Route Optimization, it might be + necessary to reveal the point of attachment of the Mobile Router to + the Mobile Network Nodes. This may mean a tradeoff between mobility + transparency and Route Optimization. + + + + +Ng, et al. Informational [Page 14] + +RFC 4889 NEMO RO Space Analysis July 2007 + + +4.8. Location Privacy + + Without Route Optimization, the Correspondent Nodes are not aware of + the actual location and mobility of the mobile network and its Mobile + Network Nodes. To achieve Route Optimization, it might be necessary + to reveal the point of attachment of the Mobile Router to the + Correspondent Nodes. This may mean a tradeoff between location + privacy [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. + +4.9. Security Consideration + + As Mobile Router and Home Agent usually belong to the same + administration domain, it is likely that there exists a security + association between them, which is leveraged by NEMO Basic Support to + conduct the home Binding Update in a secure way. However, NEMO Route + Optimization usually involves nodes from different domains (for + example, Mobile Router and Correspondent Entity); thus, the existence + of such a security association is not a valid assumption in many + deployment scenarios. For this reason, the security protection of + NEMO Route Optimization signaling message is considered "weaker" than + that in NEMO Basic Support. It is expected that some additional + security mechanisms are needed to achieve the same or similar level + of security as in NEMO Basic Support. + + When considering security issues of NEMO Route Optimization, it might + be useful to keep in mind some of the security issues considered when + Mobile IPv6 Route Optimization was designed as documented in [19]. + +4.10. Support of Legacy Nodes + + NEMO Basic Support is designed so that all legacy Mobile Network + Nodes (such as those that are not aware of the mobility of the + network they are in, and those that do not understand any mobility + protocols) can still reach and be reached from the Internet. Some + Route Optimization schemes, however, require that all Mobile Routers + implement the same Route Optimization scheme in order for them to + operate. Thus, a nested Mobile Router may not be able to achieve + Route Optimization if it is attached to a legacy Local Fixed Router. + + + + + +Ng, et al. Informational [Page 15] + +RFC 4889 NEMO RO Space Analysis July 2007 + + +5. Analysis of Solution Space + + As described in 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? + +5.1. Which Entities Are Involved? + + There are many combinations of entities involved in Route + Optimization. When considering the role each entity plays in Route + Optimization, one has to bear in mind the considerations described in + 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 + +5.1.1. Mobile Network Node and Correspondent Node + + A Mobile Network Node can establish Route Optimization with its + Correspondent Node, possibly the same way as a Mobile Node + establishes Route Optimization with its Correspondent Node in Mobile + IPv6. This would achieve the most optimal route, since the entire + end-to-end path is optimized. However, there might be scalability + issues since both the Mobile Network Node and the Correspondent Node + may need to maintain many Route Optimization sessions. In addition, + + + +Ng, et al. Informational [Page 16] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +5.1.2. Mobile Router and Correspondent Node + + Alternatively, the Mobile Router can establish Route Optimization + with a Correspondent Node on behalf of the Mobile Network Node. + Since all packets to and from the Mobile Network Node must transit + the Mobile Router, this effectively achieves an optimal route for the + entire end-to-end path as well. Compared with 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. + +5.1.3. Mobile Router and Correspondent Router + + Approaches involving Mobile Routers and Correspondent Routers are + described in 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. + + + +Ng, et al. Informational [Page 17] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +5.1.4. Entities in the Infrastructure + + Approaches using entities in the infrastructure are described in + 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 [14]). 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. + +5.2. Who Initiates Route Optimization? When? + + Having determined the entities involved in the Route Optimization in + the previous sub-section, the next question is which of these + entities should initiate the Route Optimization session. Usually, + the node that is moving (i.e., Mobile Network Node or Mobile Router) + is in the best position to detect its mobility. Thus, in general, it + is better for the mobile node to initiate the Route Optimization + session in order to handle the topology changes in any kind of + mobility pattern and achieve the optimized route promptly. However, + when the mobile node is within a nested mobile network, the detection + of the mobility of upstream Mobile Routers may need to be conveyed to + the nested Mobile Network Node. This might incur longer signaling + delay as discussed in 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. + + + + + +Ng, et al. Informational [Page 18] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +5.3. How Is Route Optimization Capability Detected? + + The question here is how the initiator of Route Optimization knows + whether the Correspondent Entity supports the functionality required + to established a Route Optimization session. The usual method is for + the initiator to attempt Route Optimization with the Correspondent + Entity. Depending on the protocol specifics, the initiator may + receive (i) a reply from the Correspondent Entity indicating its + capability, (ii) an error message from the Correspondent Entity, or + (iii) no response from the Correspondent Entity within a certain time + period. This serves as an indication of whether or not the + Correspondent Entity supports the required functionality to establish + Route Optimization. This form of detection may incur additional + delay as a penalty when the Correspondent Entity does not have Route + Optimization capability, especially when the Route Optimization + mechanism is using in-band signaling. + + When the Correspondent Entity is not the Correspondent Node but a + Correspondent Router, an immediate question is how its presence can + be detected. One approach is for the initiator to send an Internet + Control Message Protocol (ICMP) message containing the address of the + Correspondent Node to a well-known anycast address reserved for all + Correspondent Routers [7][8]. 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 [9]. Any Correspondent Router en route will process the Router + Alert Option and send a response to the Mobile Router. + + + +Ng, et al. Informational [Page 19] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +5.4. How is the Address of the Mobile Network Node Represented? + + Normally, Route Optimization would mean that a binding between the + address of a Mobile Network Node and the location of the mobile + network is registered at the Correspondent Entity. Before exploring + different ways of binding (see 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. + +5.5. How Is the Mobile Network Node's Address Bound to Location? + + In order for route to be optimized, it is generally necessary for the + Correspondent Entity to create a binding between the address and the + location of the Mobile Network Node. This can be done in the + following ways: + + o binding the address to the location of the parent Mobile Router, + + o binding the address to a sequence of upstream Mobile Routers, and + + o binding the address to the location of the root Mobile Router. + + + + +Ng, et al. Informational [Page 20] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + These are described in the following sub-sections. + +5.5.1. Binding to the Location of Parent Mobile Router + + By binding the address of Mobile Network Node to the location of its + parent Mobile Router, the Correspondent Entity would know how to + reach the Mobile Network Node via the current location of the parent + Mobile Router. This can be done by: + + o Binding Update with Mobile Network Prefix + + 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 would be routed through the bi-directional + tunnel. + + Note that in this case, the address of the Mobile Network Node is + implied by the Mobile Network Prefix (see 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 [11]. + + 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 + [20][21][22]. + + 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 + + + +Ng, et al. Informational [Page 21] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + Router (see [23] 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 + + + +Ng, et al. Informational [Page 22] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +5.5.2. Binding to a Sequence of Upstream Mobile Routers + + For a nested Mobile Network Node, it might be more worthwhile to bind + its address to the sequence of points of attachment of upstream + Mobile Routers. In this way, the Correspondent Entity can build a + complete sequence of points of attachment from a single transmission + of the binding information. Examples using this approach are [10] + and [12]. + + 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 [10]) where upstream Mobile Routers insert their + current point of attachment into a Reverse Routing Header embedded + + + +Ng, et al. Informational [Page 23] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +5.5.3. Binding to the Location of Root Mobile Router + + A third approach is to bind the address of the Mobile Network Node to + the location of the root Mobile Router, regardless of how deeply + nested the Mobile Network Node is within a nested Mobile Network. + Whenever the Correspondent Entity needs to forward a packet to the + Mobile Network Node, it only needs to forward the packet to this + point of attachment. The mobile network will figure out how to + forward the packet to the Mobile Network Node by itself. This kind + of approach can be viewed as flattening the structure of a nested + Mobile Network, so that it seems to the Correspondent Entity that + every node in the Mobile Network is attached to the Internet at the + same network segment. + + There are various approaches to achieve this: + + o Prefix Delegation + + Here, each Mobile Router in a nested mobile network is delegated a + Mobile Network Prefix from the access router (such as using + Dynamic Host Configuration Protocol (DHCP) Prefix Delegation + [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 [24], [25], and [26]. + + This approach has the advantage of keeping the implementations of + Correspondent Nodes unchanged. However, it requires the access + + + +Ng, et al. Informational [Page 24] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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 [27] and [28]) achieves Route Optimization + by having the Mobile Router act as a Neighbor Discovery [29] 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 + + + +Ng, et al. Informational [Page 25] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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 [13], 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 [30], [31], [32], and [33]. + + 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. + +5.6. How Is Signaling Performed? + + In general, Route Optimization signaling can be done either in-plane, + off-plane, or both. In-plane signaling involves embedding signaling + information into headers of data packets. A good example of in-plane + signaling would be Reverse Routing Header [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. + + + + + +Ng, et al. Informational [Page 26] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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 [34], which uses the Session Initiation + Protocol (SIP) to relay binding information. + +5.7. How Is Data Transmitted? + + With Route Optimization established, one remaining question to be + answered is how data packets can be routed to follow the optimized + route. There are the following possible approaches: + + o Encapsulations + + One way to route packets through the optimized path is to use IP- + in-IP encapsulations [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 + [36][37][38] 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 + + + +Ng, et al. Informational [Page 27] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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 [24][25][26] would + require parent Mobile Routers to route packets differently if the + source address belongs to the prefix delegated from the access + network. + +5.8. What Are the Security Considerations? + +5.8.1. Security Considerations of Address Binding + + The most important security consideration in Route Optimization is + certainly the security risks a Correspondent Entity is exposed to by + creating a binding between the address of a Mobile Network Node and + the specified location(s) of the mobile network. Generally, it is + assumed that the Correspondent Entity and Mobile Network Node do not + share any pre-existing security association. However, the + Correspondent Entity must have some ways of verifying the + authenticity of the binding specified, else it will be susceptible to + various attacks described in [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 + + + +Ng, et al. Informational [Page 28] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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); [39] 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 [3] 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) [40], Cryptographically + Generated Addresses (CGAs) [41] could be used to establish the + + + +Ng, et al. Informational [Page 29] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + ownership of Care-of Addresses. [42] 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. [18] documents various proposed enhancements to + the Mobile IPv6 Route Optimization mechanism that might be applied to + NEMO Route Optimization as well, such as [43], which allows the + Correspondent Entity to authenticate a certain operator's Home Agent + by verifying the associated certificate. The Host Identity Protocol + (HIP) [44] with end-host mobility considerations [45] may be extended + for NEMO Route Optimization as well. + + In addition, interested readers might want to refer to [46], 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 [23] 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. + +5.8.2. End-to-End Integrity + + In some of the approaches, such as "Mobile Router as a Proxy" in + 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. + +5.8.3. Location Privacy + + Another security-related concern is the issue of location privacy. + This document currently does not consider the location privacy + threats caused by an on-path eavesdropper. For more information on + + + +Ng, et al. Informational [Page 30] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + that aspect, please refer to [18]. 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. + +6. Conclusion + + The problem space of Route Optimization in the NEMO context is + multifold and can be split into several work areas. It will be + critical, though, that the solution to a given piece of the puzzle be + compatible and integrated smoothly with others. With this in mind, + + + +Ng, et al. Informational [Page 31] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + 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. + +7. Security Considerations + + This is an informational document that analyzes the solution space of + NEMO Route Optimization. Security considerations of different + approaches are described in the relevant sections throughout this + document. Particularly, please refer to 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. + +8. 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, Felix Wu, and Souhwan Jung. In addition, sincere + appreciation is also extended to Jari Arkko, Carlos Jesus Bernardos, + Greg Daley, Thierry Ernst, T.J. Kniveton, Erik Nordmark, Alexandru + Petrescu, Hesham Soliman, Ryuji Wakikawa, and Patrick Wetterwald for + their various contributions. + +9. References + +9.1. Normative References + + [1] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility + Route Optimization Problem Statement", RFC 4888, July 2007. + + [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, + "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, + January 2005. + + [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in + IPv6", RFC 3775, June 2004. + + [4] Ernst, T., "Network Mobility Support Goals and Requirements", + RFC 4886, July 2007. + + + +Ng, et al. Informational [Page 32] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + [5] Manner, J. and M. Kojo, "Mobility Related Terminology", + RFC 3753, June 2004. + + [6] Ernst, T. and H-Y. Lach, "Network Mobility Support + Terminology", RFC 4885, July 2007. + +9.2. Informative References + + [7] 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. + + [8] Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol + (ORC)", Work in Progress, November 2004. + + [9] 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. + + [10] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and + its application to Mobile Networks", Work in Progress, + February 2007. + + [11] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization + with Access Router Option", Work in Progress, July 2004. + + [12] 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. + + [13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, + "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", + RFC 4140, August 2005. + + [14] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA + protocol", Work in Progress, September 2006. + + [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [16] Baek, S., Yoo, J., Kwon, T., Paik, E., and M. Nam, "Routing + Optimization in the same nested mobile network", Work + in Progress, October 2005. + + [17] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, + July 2005. + + + +Ng, et al. Informational [Page 33] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + [18] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements + to Mobile IPv6 Route Optimization", RFC 4651, February 2007. + + [19] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. + Nordmark, "Mobile IP Version 6 Route Optimization Security + Design Background", RFC 4225, December 2005. + + [20] 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. + + [21] 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. + + [22] Bernardos, C., Bagnulo, M., Calderon, M., and I. Soto, "Mobile + IPv6 Route Optimisation for Network Mobility (MIRON)", Work + in Progress, July 2005. + + [23] 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. + + [24] Perera, E., Lee, K., Kim, H., and J. Park, "Extended Network + Mobility Support", Work in Progress, July 2003. + + [25] 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. + + [26] 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. + + [27] 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. + + [28] 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. + + + + +Ng, et al. Informational [Page 34] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + [29] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + + [30] 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. + + [31] 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. + + [32] 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. + + [33] Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route + optimization method in a mobile network", Work in Progress, + October 2003. + + [34] Lee, C., Zheng, J., and C. HUang, "SIP-based Network Mobility + (SIP-NEMO) Route Optimization (RO)", Work in Progress, + October 2006. + + [35] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 + Specification", RFC 2473, December 1998. + + [36] 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. + + [37] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology + and Channel Mapping Examples", RFC 3759, April 2004. + + [38] Minaburo, A., Paik, E., Toutain, L., and J. Bonnin, "ROHC + (Robust Header Compression) in NEMO network", Work in Progress, + July 2005. + + [39] Ng, C. and J. Hirano, "Extending Return Routability Procedure + for Network Prefix (RRNP)", Work in Progress, October 2004. + + [40] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + + +Ng, et al. Informational [Page 35] + +RFC 4889 NEMO RO Space Analysis July 2007 + + + [41] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [42] Zhao, F., Wu, F., and S. Jung, "Extensions to Return + Routability Test in MIP6", Work in Progress, February 2005. + + [43] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-based + Binding Update Protocol (CBU)", Work in Progress, March 2005. + + [44] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, + "Host Identity Protocol", Work in Progress, April 2007. + + [45] Henderson, T., "End-Host Mobility and Multihoming with the Host + Identity Protocol", Work in Progress, March 2007. + + [46] 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ng, et al. Informational [Page 36] + +RFC 4889 NEMO RO Space Analysis 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 + + + Fan Zhao + University of California Davis + One Shields Avenue + Davis, CA 95616 + US + + Phone: +1 530 752 3128 + EMail: fanzhao@ucdavis.edu + + + Masafumi Watari + KDDI R&D Laboratories Inc. + 2-1-15 Ohara + Fujimino, Saitama 356-8502 + JAPAN + + EMail: watari@kddilabs.jp + + + Pascal Thubert + Cisco Systems + Village d'Entreprises Green Side + 400, Avenue de Roumanille + Batiment T3, Biot - Sophia Antipolis 06410 + FRANCE + + EMail: pthubert@cisco.com + + + + + + + + + + + + +Ng, et al. Informational [Page 37] + +RFC 4889 NEMO RO Space Analysis 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 38] + |