NEMO Working Group F. Zhao Internet-Draft S F. Wu Expires: April 18, 2005 UC Davis S. Jung Soongsil University October 18, 2004 NEMO Route Optimization Problem Statement, Requirements and Evaluation Considerations draft-zhao-nemo-ro-ps-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes and analyzes the routing optimization problem in NEMO, defines the requirements that must be met by NEMO route optimization solutions and then describes the metrics to evaluate the performance of NEMO route optimization solutions. Zhao, et al. Expires April 18, 2005 [Page 1] Internet-Draft NEMO RO Problem October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. The definition of "optimal" and "non-optimal" route . . . . . 6 4.1 Optimal route . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1 CN is not under the same nested NEMO as its peer, MNN . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2 CN is under the same nested NEMO as its peer, MNN . . 6 4.2 Non-optimal route . . . . . . . . . . . . . . . . . . . . 7 4.3 Approximately optimal route . . . . . . . . . . . . . . . 8 5. Limitation of NEMO Basic Support protocol . . . . . . . . . . 9 5.1 Reverse tunneling . . . . . . . . . . . . . . . . . . . . 9 5.2 HA as the only anchor point . . . . . . . . . . . . . . . 9 5.3 Inside the nested NEMO . . . . . . . . . . . . . . . . . . 9 5.4 Data plane based method . . . . . . . . . . . . . . . . . 9 5.5 Data packet and processing overhead . . . . . . . . . . . 10 5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. The formalization of the nested NEMO network . . . . . . . . . 11 7. The related tradeoff . . . . . . . . . . . . . . . . . . . . . 13 7.1 Data plane method vs. signaling plane method . . . . . . . 13 7.2 Optimization vs. the scalability issue in MR, CA and HA . 13 7.3 Optimization vs. the scope of change . . . . . . . . . . . 13 7.4 Location privacy vs. optimal route . . . . . . . . . . . . 13 7.5 Security vs. optimal route . . . . . . . . . . . . . . . . 13 7.6 Scalability vs. reliability . . . . . . . . . . . . . . . 14 8. The scope of NEMO RO problem . . . . . . . . . . . . . . . . . 15 8.1 What NEMO RO considers . . . . . . . . . . . . . . . . . . 15 8.2 What NEMO RO does not consider . . . . . . . . . . . . . . 15 9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Evaluation Considerations . . . . . . . . . . . . . . . . . 18 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 21 Zhao, et al. Expires April 18, 2005 [Page 2] Internet-Draft NEMO RO Problem October 2004 1. Introduction The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC2119 [7]. NEMO Basic Support protocol maintains the connectivity when MR changes its point of attachment to the Internet by establishing a bi- directional tunnel between MR and HA. Like MIP6, the protocol specification introduces one level of indirection in the routing system in favor of protocol simplicity and minimal changes on fixed nodes. However, it results in a non-optimal (We will define "optimal" and "non-optimal" later.) route between MNN and CN with a non-zero and even very large probability, which causes the significant communication delay. Moreover, by using IPv6 header encapsulation together with other options, NEMO Basic Support protocol also causes big overheads in packet payload and bandwidth. NEMO RO problem introduces more challenges and more difficulties than MIP6 RO problem because of the nested NEMO network where multiple levels of mobility are formed. Without NEMO RO solution, the performance becomes much worse especially in the nested NEMO. In this draft, we describe and analyze the routing optimization problem in NEMO, defines the requirements that must be met by NEMO route optimization solutions and then describes the metrics to evaluate the performance of NEMO route optimization solutions. Zhao, et al. Expires April 18, 2005 [Page 3] Internet-Draft NEMO RO Problem October 2004 2. Terminology The terms used in this draft are defined in [2], besides the following ones: Correspondent Agent (CA): An entity (router or host) performs the RO function with MR on behalf of CN. In NEMO when MR acts as a gateway and performs RO function for an entire mobile network associated with itself, its peer is CA rather than CN that is instead the peer of MNN from an end-to-end perspective. CA may be just CN itself or a router near CN or even CN's default router. One MR could have multiple CAs at the same time because MNNs behind this MR may communicate with CNs in the different networks. And in NEMO Basic Support protocol, HA acts as CA for any node in the Internet to communicate with MNN behind its MR. Anchor point: the entity that knows the binding information between host and location and thus is capable of forwarding the data packets destined for a host to the location directly. In the fixed network, each router is such kind of anchor point because IP address represents both location and host, and the destination IP address together with the routing table provides the sufficient knowledge on how to reach the destination. However in the NEMO mobile network that is compliant with NEMO Basic Support protocol, HA is the only anchor point for CN and MNN. In order to achieve the optimal route in NEMO, MR and CA should become anchor point too. In most cases, the closer to MNN/CN the anchor point is, the shorter the routing path is. Inbound direction: The direction from the Internet infrastructure to the inside of NEMO network. Outbound direction: The direction from the inside of NEMO network to the Internet infrastructure. Inbound route : The route taken by the packets forwarded in the inbound direction. Inbound route is used exchangeably with inbound path. Outbound route : The route taken by the packets forwarded in the outbound direction. Outbound route is used exchangeably with outbound path. Zhao, et al. Expires April 18, 2005 [Page 4] Internet-Draft NEMO RO Problem October 2004 3. Assumptions In this draft we do not consider the case of mobile HA. Instead we assume that all HAs are fixed nodes and are located in the Internet infrastructure. Firstly it is not clear yet about the need of mobile HA in the real life at this moment. Secondly and more importantly, since a mobile HA needs the help of another fixed HA in order to forward the traffic for MRs, the mobile HA case can be deduced into the similar case with only fixed HA. Our description has no difficulty to be extended into the mobile HA case. Thus we believe that this assumption is reasonable and does not prevent the thorough analysis on NEMO RO problem. Zhao, et al. Expires April 18, 2005 [Page 5] Internet-Draft NEMO RO Problem October 2004 4. The definition of "optimal" and "non-optimal" route NEMO route optimization solution aims to provide the optimal route between MNN and CN as well as between MR and CA. As it has been understood for a long time that the routing path in the Internet is asymmetric, in the following text we consider just either of two directions without explicit statement and the same analyses also apply to the other direction. 4.1 Optimal route In the NEMO Route Optimization problem, "optimal route" is not the topologically shortest path or the best route in terms of any other metric from source to destination. Based on the location of CN, "optimal route" is discussed in the following cases: 4.1.1 CN is not under the same nested NEMO as its peer, MNN CN may be located in either fixed or mobile network. As the route between MNN/MR and CN/CA consists of two portions, the route in the Internet and the route inside the (nested) NEMO network, we define them separately. The "optimal route" in the Internet is the route between the location of MNN/MR and the location of CN/CA based on the forwarding tables of Internet routers, which is usually built by inter-domain or intra-domain routing protocol. Precisely, location is the point of attachment to the Internet. While in MIP6 MN's Care-of-Address represents its location of attachment to the Internet, in the nested NEMO MNN/MR's Care-of-Address is not sufficient any more to represent its location of attachment to the Internet except the case of root-MR; Instead it represents the point of attachment to the parent MR or the location inside the parent NEMO. A sequence of Care-of-Addresses of MRs or other ways may be used to represent the location of MR in the NEMO RO solution. The "optimal route" inside the NEMO network is formed by the decision of each MR along the outbound and inbound path. In the outbound direction, MR just forwards the packets to its default router that is determined when MR associates to NEMO network while in the inbound direction, MR forwards the packets to the next hop depending on the solution. The inbound path inside the NEMO network may be different from the outbound path. Note that the route inside the NEMO network does not contain HA. 4.1.2 CN is under the same nested NEMO as its peer, MNN CN may be under the same MR or different MR from its peer. We assume that node1 wants to communicate with node2 under the same nested NEMO. Path p1 = is the sequence Zhao, et al. Expires April 18, 2005 [Page 6] Internet-Draft NEMO RO Problem October 2004 of routers inside the nested NEMO for node1 to reach node2 and path p2 = is the sequence of routers inside the nested NEMO for node2 to reach node1. Case 1: If the intersection of p1 and p2 is not empty, denoted by = where i1 < i2 < ... < ik and j1 < j2 < ... < jk, then ideally the optimal path between node1 and node2 is . Note that MR_(1,i1) is equal to MR_(2,j1). |-----| |-----| |---| MR2 |---| MR3 |--LFN3 | |-----| |-----| |-------| |-----| |Root-MR|---| MR1 | |-------| |-----| | |-----| |-----| |---| MR4 |---| MR5 |--LFN5 |-----| |-----| Figure 1: The optimal route inside the nested NEMO For example, in the nested NEMO shown by Figure 1, the optimal route between LFN3 and LFN5 is MR3<->MR2<->MR1<->MR4<->MR5. The optimal route in this case is the route turning around at the first MR that is aware of how to forward the data packets from source to destination without going out of the nested NEMO. However, in NEMO Basic Support protocol, the data packet takes a route that goes out of the nested NEMO and comes back to the same nested NEMO again. Case 2: If the intersection of p1 and p2 is empty (It may be due to multiple different root-MRs and no inter-communication between them), the "optimal route" inside the nested NEMO consists of both p1 and p2, and the "optimal route" inside the Internet follows the definition in Section 4.1.1. 4.2 Non-optimal route In NEMO Basic Support protocol, the packets are forwarded to an intermediate box, HA, in both directions rather than the location of destination directly, which results in a longer route than the "optimal route" with a high probability. We refer this kind of route as "non-optimal" route. Worse than MIP6, in the nested NEMO network the packets are forwarded to multiple HAs in both directions before arriving at the location of destination. [10] describes the Zhao, et al. Expires April 18, 2005 [Page 7] Internet-Draft NEMO RO Problem October 2004 non-optimal route that packets would take using existing Mobile IPv6 and NEMO Basic Support mechanisms 4.3 Approximately optimal route The solution to achieve an "optimal route" has to consider a lot of other factors, for example, scalability, efficiency, and security, to name a few. Although the solution may result in an approximately optimal route, it must be the best overall when all the related issues are taken into consideration. Zhao, et al. Expires April 18, 2005 [Page 8] Internet-Draft NEMO RO Problem October 2004 5. Limitation of NEMO Basic Support protocol In this section, we analyze the limitation of NEMO Basic Support protocol and the reasons to cause the non-optimal route. 5.1 Reverse tunneling In NEMO Basic Support protocol, all the packets forwarded by MR in the outbound direction have to go through HA firstly. If the reverse tunnel would be removed in NEMO RO solution, it is equivalent to the case where MR is the anchor point for the outbound packet. Instead in the normal fixed network, the data packets are sent to the destination directly. 5.2 HA as the only anchor point Since MR is refrained from announcing its MNP to the infrastructure due to the conflicts and routing instability issues, HA is the only anchor point for MNN as well as CN and thus the packets destined to MNNs can be served only by HA. Even worse in the nested NEMO, the packets inevitably have to go through multiple HAs in order to be forwarded to MNN correctly. The non-optimal route is formed because the binding information is available in HA only and the HA's location is limited in home network only. Image that there are as many HAs as routers scattering around the Internet, every data packet from CN is forwarded by a nearby HA and takes at least a nearly optimal route. Deploying multiple HAs in the different domains or spreading binding information needs to consider a lot of issues, such as fundamental changes, conflict and scalability etc. Compared with the fixed network, there is no limitation on the location of anchor point because each router is such an anchor point. 5.3 Inside the nested NEMO If MR inside the nested NEMO is refrained from announcing its MNP to other MRs, MR does not know how to forward in the inbound direction just based on the destination IP address and its own limited knowledge of topology. Thus MR has to depend on the explicit IP-in-IP header to forward to the next hop, which in return requires that each data packet should go through HA. 5.4 Data plane based method We categorize NEMO as a data plane method because 1) there is no Zhao, et al. Expires April 18, 2005 [Page 9] Internet-Draft NEMO RO Problem October 2004 signaling message introduced for CN to discover or update the binding information; 2) many changes are made in order for the routing decision to be explicitly carried in the data packet in an "in-band" fashion. The limitation of this data plane method is that every data packet has to experience the non-optimal route even though the optimal route may be existing and fairly stable within a certain time window. Considering the potential large number of data packets, the inefficiency as well as the benefits if the problem is solved are very big. On the other hand this method avoids the large change on the infrastructure. Given the fact that a big change on the infrastructure may take a longer time to deploy, a RO solution in data plane may qualify as a necessary step before a revolutionary change happens. 5.5 Data packet and processing overhead Encapsulation and other options in IPv6 header cause the overhead in data packet and bandwidth, packet fragmentation, and the processing overhead in MR and HA especially in the nested NEMO where every level of mobility introduces one encapsulation together with applicable option fields into the data packet. In the fixed network, encapsulation and other options are not needed since all the routing decision is purely based on the forwarding table and the destination IP address. 5.6 Summary One significant difference between MIP6 and NEMO is the management granularity that is a single host in MIPv6 and a mobile network in NEMO. Another significant difference is the multiple levels of mobility in the nested NEMO, which not only causes much longer routing path and bigger overhead in the data payload but also more challenges when attempting to solve NEMO RO problem, for example, given that any other factor is constant, the number of messages (RR test, BU etc) is in direct proportion to the number of MRs along the path if no cooperation among them. In summary, NEMO RO problem is a challenging problem and requires a well-designed NEMO RO solution. Zhao, et al. Expires April 18, 2005 [Page 10] Internet-Draft NEMO RO Problem October 2004 6. The formalization of the nested NEMO network The topology of the nested NEMO can be formalized into graph. When care is taken to avoid the loop to be formed, this graph is a Directed Acyclic Graph that may be also considered as a set of multiple overlapping trees. The inbound graph is a direct graph where each node in V denotes a MR and if one of egress interfaces in MRj gets its care-of-address from one MNP owned by MRi, the link from MRi to MRj, belongs to the edge set E. The outbound graph is a direct graph where each node in V denotes a MR and if MRj chooses MRi as its default router, the link from MRj to MRi, belongs to the edge set E. This method can also formalize a multi-homing nested NEMO where there could be more than one egress interface associated with one MR and more than one MR owning one or more MNPs. Figure 2 below shows an exmaple of nested NEMO network. |-------| |-------| | MR1 | | MR2 | |-------| |-------| | | | MNP1 | | MNP2 MNP2 | --?------+ +-------?------?----------+ | | | | | | |eth0|-------|eth1| |eth0|-------| |----| MR3 |----| |----| MR4 | |-------| |-------| In this figure, MR1 announces MNP1 and MNP2 while MR2 announces MNP2. MR3 has two interfaces that associate with MR1 and MR2 respectively while MR4 associates with MR2 only. Figure 2: An example of nested NEMO network The inbound graph is shown in Figure 3. Zhao, et al. Expires April 18, 2005 [Page 11] Internet-Draft NEMO RO Problem October 2004 |-------| |-------| | MR1 |--- ---| MR2 | |-------| \ / |-------| | | \ / | V V X V |-------| / \ |-------| | MR3 |<--/ \-->| MR4 | |-------| |-------| Figure 3: The inbound graph of a nested NEMO network We can simplify the inbound graph shown in Figure 3 into the following one. |-------| |-------| | MR1 |--- ---| MR2 | |-------| \ / |-------| | \ / | V X V |-------| / \ |-------| | MR3 |<--/ \-->| MR4 | |-------| |-------| Figure 4: The simplified inbound graph of a nested NEMO network Assume that MR3 chooses MR2 as the default router through eth1 and MR4 chooses MR1 as the default router through eth0. The outbound graph of this nested NEMO is shown in Figure 5. |-------| |-------| | MR1 |<-- -->| MR2 | |-------| \ / |-------| \ / X |-------| / \ |-------| | MR3 |---/ \---| MR4 | |-------| |-------| Figure 5: The outbound graph of a nested NEMO network The formalization may help us understand the problem better and develop the RO solution. For example, if an explicit next hop address is presented in the packet, MR has to check whether this next hop address belongs to one of its MNPs in order to prevent an attacker forcing the packet to be forwarded in a loop. Zhao, et al. Expires April 18, 2005 [Page 12] Internet-Draft NEMO RO Problem October 2004 7. The related tradeoff We discuss the tradeoffs when designing the solution for NEMO RO problem. 7.1 Data plane method vs. signaling plane method Data plane method needs fewer changes but introduces more overheads while signaling plane method may require more changes on the protocols. We need to consider how to utilize the advantages of both methods and avoid the disadvantages. 7.2 Optimization vs. the scalability issue in MR, CA and HA The closer to CN CA is, the more optimal route; but MR has to perform RO functions with more CAs when the number of different CNs is large and all CNs scatter around the Internet. MR may choose not to perform RO function but NEMO Basic Support protocol due to the management cost. On the other hand, if there are many MRs belonging to the same home network scattering around the Internet, because of the same reason, CA may also choose to perform NEMO Basic Support protocol with HA rather than to perform RO function with each MR. If there are many HAs, each of which is close to each MR belonging to the same home network, the route between MNN and CN is at least nearly optimal. Thus there is a tradeoff between the optimal route and the scalability issue in terms of the number of HAs. 7.3 Optimization vs. the scope of change The scope of change is in terms of the number of nodes that need to be changed in order to support NEMO RO solution. If all CNs are changed to support the NEMO RO, the optimal route is formed; however, if the scope of change is a limited number of nodes, the probability that a sub-optimal route is formed could be very large. 7.4 Location privacy vs. optimal route Bi-direction tunnel in NEMO Basic Support protocol can maintain some level of location privacy. A potential RO solution may require some location information to be revealed in order to facility route optimization. 7.5 Security vs. optimal route In NEMO Basic Support protocol, it is very possible that there pre- Zhao, et al. Expires April 18, 2005 [Page 13] Internet-Draft NEMO RO Problem October 2004 exists the security association between MR and HA, which helps resist the various attacks. However in NMEO RO solution, as the MR-HA tunnel may not exist and there is no pre-existing security association between two entities from the different domains, it is more challenging to maintain the same security strength as in NEMO Basic Support protocol. 7.6 Scalability vs. reliability This is a general tradeoff in NEMO. As MR manages a whole mobile network, when MR fails due to attack or error, a bunch of MNNs behind MR lose the connectivity even though any single MNN still functions well. However, generally it provides more scalability than MIP6. Zhao, et al. Expires April 18, 2005 [Page 14] Internet-Draft NEMO RO Problem October 2004 8. The scope of NEMO RO problem 8.1 What NEMO RO considers (Below is an incomplete list of issues related to NEMO RO problem quoted from the NEMO mailing list. More discussions are still needed.) o NEMO The optimal route when two communicating nodes are located either in the same or different (nested) NEMO network [10]. o VMN may choose not to perform MIP6 RO solution so that even though MR performs NEMO RO function, the packets originated from and destined to VMN still have to go through VMN's HA. We need to consider all the related issues if we want to remove this kind of sub-optimal route for VMN. o Missing signaling messages when performing NEMO RO o Obsolete state or signaling message when mobility causes the topology changes o RO problem when multi-homing is also involved o Data packet overhead when header encapsulation, options and routing header are used o Security problem. o Location privacy problem o Looping problem o Cross-over tunnel problem o BU storm 8.2 What NEMO RO does not consider TBD. Zhao, et al. Expires April 18, 2005 [Page 15] Internet-Draft NEMO RO Problem October 2004 9. Requirements The goal of NEMO RO solution is to provide an optimal route between any two nodes regradless of the location, the configuration, and the type etc. Besides those defined in [1], NEMO RO solution, hereafter referred to as "the solution", must meet the following requirements that are described in the descending order of importance as follows: R1: When any MR in NEMO performs NEMO RO function, the route taken by the traffic from this MR together with any MNN inside this MR's sub-NEMO MUST be better than the one resulted in by performing NEMO Basic Support protocol. R2: Signaling messages MUST be secured to guarantee the integrity, confidentiality, anti-replay and authorization. The insider attack where the attacker is on the routing path SHOULD be at least detected while the outsider attack where the attacker is not on the routing path MUST be resisted. The security mechanism MUST prevent the forged packet being forwarded in a loop inside NEMO and MUST not generate the new vulnerability. Overall, the security level and the location privacy MUST be kept as strong as in NEMO Basic Support protocol. R3: This solution SHOULD introduce limited signaling overhead, limited packet payload overhead, limited memory cost needed for processing, limited complexity in term of data structure and protocol state machine transition. R4: The solution MUST be able to support a potentially large number of MNNs, CNs, CAs as well as HAs (if applicable) and arbitrary levels of MRs unless because of other constraints. R5: The solution SHOULD avoid too many changes on MNN/MR/CN/CA/HA unless the significant performance improvement can be achieved. It is desired to keep the mobility transparency for MNN behind MR. R6: The solution SHOULD be able to handle the topology changes in any kind of mobility pattern very well and minimize the impact of handover over applications, in term of packet loss or delay. R7: The solution SHOULD function for multi-homing NEMO networks (multiple MNPs, multiple MRs and multiple network interfaces, etc.). The solution SHOULD not conflict with multi-homing mechanism, such as loading balance, fault tolerance etc. R8: Each MR can either independently decide whether to perform RO function or NEMO Basic Support protocol or collaborate with other MR based on its policy. The decision made by one MR MUST not Zhao, et al. Expires April 18, 2005 [Page 16] Internet-Draft NEMO RO Problem October 2004 prevent other MR performing either NEMO RO or NEMO Basic Support protocol properly. R9: The solution SHOULD ensure backward compatibility with other standards defined by the IETF. Especially the solution MUST not prevent the proper operation of Mobile IPv6 (i.e. the solution MUST allow MIP6-enabled MNNs to operate either of the CN, HA, or MN operations defined in MIP6.) and NEMO Basic Support protocol. More? Zhao, et al. Expires April 18, 2005 [Page 17] Internet-Draft NEMO RO Problem October 2004 10. Evaluation Considerations The following metrics are defined to evaluate how good a NEMO RO solution is besides meeting the requirements described above. Each metric may be assigned a weight in order to find a overall best RO solution. o Level of compatibility with NEMO Basic Support protocol o Complexity: How many changes to MNN/MR/CA/HA are introduced? Does the solution maintain the mobility transparency for MNN? o Performence: * The delay to discover and set up the optimal path * The packet overhead and/or signaling overhead to discover and set up the optimal path * The delay to re-discover and re-build the optimal path when the mobility causes the topology change * The packet overhead and/or signaling overhead to re-discover and re-build the optimal path when the mobility causes the topology change o Management cost: * The number of states established or maintained in MR/CA/HA * The number of MNNs supported by MR/CA/HA o More? Zhao, et al. Expires April 18, 2005 [Page 18] Internet-Draft NEMO RO Problem October 2004 11. Acknowledgement We sincerely thank Alexandru Petrescu, Thierry Ernst, Pascal Thubert, Carlos Jess Bernardos Cano and Masafumi Watari for their comments and valuable suggestions. 12 References [1] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-02 (work in progress), February 2004. [2] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-01 (work in progress), February 2004. [3] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubertet, "Network Mobility (NEMO) Basic Support Protocol", IETF proposed standard, draft-ietf-nemo-basic-support-03, June 2004. [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-00 (work in progress), July 2004. [6] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [8] Thubert, P., Molteni, M., Ng, C., Ohnishi, H. and E. Paik, "Taxonomy of Route Optimization models in the Nemo Context", draft-thubert-nemo-ro-taxonomy-02 (work in progress), February 2004. [9] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-05 (work in progress), June 2004. [10] Watari, M. and T. Ernst, "Route Optimization with Nested Correspondent Nodes", draft-watari-nemo-nested-cn-00 (work in progress), October 2004. Zhao, et al. Expires April 18, 2005 [Page 19] Internet-Draft NEMO RO Problem October 2004 Authors' Addresses Fan Zhao University of California, Davis University of California, Davis One Shield Avenue Davis, CA 95616 US Phone: +1 530 752 3128 EMail: fanzhao@ucdavis.edu S. Felix Wu University of California, Davis University of California, Davis One Shield Avenue Davis, CA 95616 US Phone: +1 530 754 7070 EMail: sfwu@ucdavis.edu Souhwan Jung Soongsil University Soongsil University 1-1, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82 2 820 0714 EMail: souhwanj@ssu.ac.kr Zhao, et al. Expires April 18, 2005 [Page 20] Internet-Draft NEMO RO Problem October 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhao, et al. Expires April 18, 2005 [Page 21]