Network Working Group P. Thubert Internet-Draft M. Molteni Expires: August 15, 2004 Cisco Systems C. Ng Panasonic Singapore Labs H. Ohnishi NTT E. Paik Seoul National Univ. February 15, 2004 Taxonomy of Route Optimization models in the Nemo Context draft-thubert-nemo-ro-taxonomy-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 August 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract NEMO enables Mobile Networks by extending Mobile IP to support Mobile Routers. This memo documents how the MIPv6 concept of Route Optimization can to be adapted for NEMO to optimize traffic routing between nodes in a mobile network and their correspodnet nodes. Different route optimizations schemes are discussed, including: Thubert, et al. Expires August 15, 2004 [Page 1] Internet-Draft RO-Taxonomy February 2004 1. route optimization with corresponding nodes initiated bu mobile routers on behalf of the mobile network nodes; 2. a visiting mobile node performing MIPv6 RO over the NEMO base protocol; 3. performing RO over the routing infrastructure involving optimizing the route between two routers situated near to each end point, instead of end-to-end; and 4. minimizing the number of tunnels required when there is multiple levels of nesting. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MIPv6 Route Optimization over NEMO . . . . . . . . . . . . . . 4 4. Optimization within the infrastructure . . . . . . . . . . . . 4 4.1 Route Optimization within a ISP network . . . . . . . . . . . 5 4.2 Correspondent Router . . . . . . . . . . . . . . . . . . . . . 6 4.3 Distributed Anchor Routers . . . . . . . . . . . . . . . . . . 7 5. Nested Mobile Network . . . . . . . . . . . . . . . . . . . . 8 5.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . . . 8 5.2 Route Optimization inside the Nested Mobile Network . . . . . 12 6. General Considerations . . . . . . . . . . . . . . . . . . . . 12 6.1 Securing the protocol in nested tunnels optimization . . . . . 12 6.2 Recursive complexity in route optimization . . . . . . . . . . 12 6.3 Mobile Access router selection . . . . . . . . . . . . . . . . 13 6.4 Mobility transparency and RO . . . . . . . . . . . . . . . . . 14 6.5 Multihoming Considerations . . . . . . . . . . . . . . . . . . 15 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 19 Thubert, et al. Expires August 15, 2004 [Page 2] Internet-Draft RO-Taxonomy February 2004 1. Introduction This document assumes the reader is familiar with Mobile IPv6 defined in [1], with the concept of Mobile Router (MR) and with the Nemo terminology defined in [2]. From the discussions on the mailing list, it appears that the common current understanding of the problem space of Route Optimization (RO), in the Nemo context, is still limited. This draft attempts to clarify the state of the discussion and propose a taxonomy of the various aspects of the problem. We will look at different possible types of route optimizations related to mobile network. Firstly, the Mobile Router can initiate route optimization with corresponding nodes (CN) on behalf of the mobile network nodes (MNN). Secondly, we consider the feasibility of having a visiting mobile node (VMN) performing MIPv6 RO over the NEMO base protocol. Thirdly, we explore the prospect of performing RO over the routing infrastructure. This involves optimizing the route between two routers situated near to each end point. Lastly, route optimizations involving nested mobile networks are explored. This involves minimizing the number of tunnels required when there is multiple levels of nesting. 2. MR-to-CN This section covers the case where the Route Optimization is performed between the MR and the correspondent nodes which mobile network nodes (MNNs) are communicating with. This scenario is useful when a lot of MNNs in a mobile network is communicating with a few corresponding nodes. In such cases the MR only needs to send one binding update (BU) to optimized the route between CN and a few MNNs. A major issue with this form of optimization is that the end-to-end principle of the MIPv6 Reverse Routability (RR) test is broken. The RR test is meant to ensure the care-of address (CoA) and the home address (HoA) are collocated. With a mobile network, when the MR performs RO on behalf of the MNNs, the CoA in BU will be the MR's CoA. Thus, a MNN is reachable via the CoA, but not at the CoA. Some tricks may be performed on the fly by the MRs but it seems that a clean MR-to-CN optimization for Nemo will impact the CN function. Thubert, et al. Expires August 15, 2004 [Page 3] Internet-Draft RO-Taxonomy February 2004 Once we modify the CN behavior, we need to introduce a negotiation from the start of the RR test to determine the protocol. In particular, the Mobile Node and the CN must decide whether checking the collocation is possible, and if not, whether a CN is willing to accept the risk. If not, the optimization may be limited to triangular routing MR->CN->HA->MR. This is a major evolution from [1], since MIPv6 has no such negotiation capability at this time. 3. MIPv6 Route Optimization over NEMO MIPv6 mobile nodes can move everywhere. If the user brings mobile nodes (e.g. MIP VoIP terminal) into the vehicle that supports NEMO function, packets destined to the mobile node will have to be routed not only to its home agent but also the home agent of the mobile router. This pattern resembles Nested NEMO case which is described in later section. This solution is needed to use both MIPv6 and NEMO technologies efficiently. When a Mobile Node visits a Mobile Network, the best Route Optimization is obtained if the path in the Infrastructure is the same as if the Mobile Network was attached at the attachment point of the Mobile Router (i.e., there is not additional Tunneling that is linked to NEMO). A possible approach to this is to extend the solution for nested mobile network optimization to include VMN as well. In this case, the VMN is treated as though it is an MR. This type of solution will most likely require some extensions for a MIPv6 VMN and CN. 4. Optimization within the infrastructure This section elaborates on cases where the Route Optimization is performed within the Routing Infrastructure. This model is useful when an ISP wants to control the route optimization procedures and does not desire to add any functions to the CN or the MR in order to achieve route optimizations between CN and LFN. In this model, both the LFN behind the MR and the Correspondent can be MIP agnostic. The drawback is the introduction of Mobile Routes in specific Routers, causing additional signaling and load to the Routing Fabric. The general idea is that there is a correspondent-side router (C-side Router) in the infrastructure that is located "closer" to the CN than Thubert, et al. Expires August 15, 2004 [Page 4] Internet-Draft RO-Taxonomy February 2004 the HA of the MR. This C-side Router can terminate MIP on behalf of the CN. Correspondent nnnnnnnnnnnnnnnnnnnnnnnn Home Agent # n # o # n # # :== Tunnel o # n # o :== Optimized o # n # n :== Non-Optimized o # n # ################################## n # C-Side oooooooooooooooooooooooooooooooo Mobile Router ################################ Router | ====Mobile Network======= Optimization in the Infrastructure This optimization is only valid when the path via the C-side Router is shorter than the path via the Home Agent. The Optimization can take place independently for the 2 directions of the traffic: Egress The MR locates the C-side Router, establishes a tunnel with that Router and sets a route to the Correspondent Node via the C-side Router over the Tunnel. After this, traffic to the Correspondent Node does not flow through the Home Agent anymore. Ingress The C-side Router is on the way of the traffic from the Correspondent Node to the Home Agent. Also, it is aware of the MR and the mobile network behind the MR and establishes the appropriate tunnel and route. After this, it is able to reroute traffic to the mobile network over the tunnel to the MR. 4.1 Route Optimization within a ISP network This form of Route Optimization provides local savings for an ISP. This idea was described in Ohnishi's Mobile Border Gateway draft. The goal is to locate the closest (BGP) gateway for a Correspondent that is located outside of the domain, and tunnel between the MR and that gateway as opposed to the Home Agent for that specific Correspondent. Thubert, et al. Expires August 15, 2004 [Page 5] Internet-Draft RO-Taxonomy February 2004 4.2 Correspondent Router A globally better optimization is obtained if the tunnel from the MR is terminated closer to the destination on the Correspondent side. This is the role of a Correspondent Router (CR). +-------------------+ # :== Tunnel | Autonomous System | o :== Optimized | ----------------- | n :== Non-Optimized | | | | | Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent | | # n # | o | # n # | o | # n # | o | # n # | o | # n # | o | # n # | #################################### ? | CR oooooooooooooooooooooooooooooooooooooo Mobile | #################################### Router | | | +-------------------+ ===========Mobile Network======== Correspondent Router The MR locates the CR for a given Correspondent and establishes a Tunnel to the CR for that destination and its prefix(es). Then, the CR establishes the Tunnel back to the MR and the Mobile Routes to the MR's Mobile Networks via that Tunnel. A key point is that the CR must be on the interception path of the traffic from the Correspondent to the Mobile Networks in order to reroute the traffic over the appropriate Tunnel. This can be achieved in several fashions: Redistribution There's a limited Number of CRs that cover an Autonomous System. They redistribute the Mobile Routes on the fly, or within rate and amount limits. Garbage Collection is done at appropriate time to limit the perturbation on the Routing. Default Router The CR is a Default Router for the Correspondent, or for the whole AS of the Correspondent (it's a border gateway). In this case, redistribution is not needed. Thubert, et al. Expires August 15, 2004 [Page 6] Internet-Draft RO-Taxonomy February 2004 Core Routers The Core Routers for the network of the Correspondent are all CRs. If the path from the correspondent to the Home Agent does not pass via a CR, then it's not worth optimizing. If it is, then the CRs are on the way. Again, redistribution is not needed. 4.3 Distributed Anchor Routers Taking the idea of a correspondent router a step further, it is possible to have a distributed set of anchor routers across the Internet. Outgoing packets sent from a mobile network will be tunneled to one of the nearest anchor router (instead of to the home agent of the mobile router). This M-Side (Mobile Network Side) anchor router will decapsulate the packet, inspect the destination, and tunnel the packet to another anchor router situated near the CN (C-Side Anchor Router). From there, the packet will be decapsulated and forwarded to the CN. Correspondent nnnnnnnnnnnnnnnnnnnnnnn Home Agent o # n # o # n # # :== Tunnel o # n # o :== Optimized o # n # n :== Non-Optimized o # n # C-Side ################## M-Side ###### n # Anchor oooooooooooooooooo Anchor oooo Mobile Router ################## Router #### Router | ====Mobile Network======= Optimization in the Infrastructure The C-Side Anchor Router will be subjected to the same condition as listed in the previous sub-section if packets sent from the CN to the mobile network are to be route-optimized too. Otherwise, the solution will only partially optimize routing to a triangular routing (i.e. packet sent by CN will still go through the home agent of the mobile network). The anchor router share many similarities with the concept of Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6) [9]. In fact, it can be combined with HMIPv6 whereby each M-Side anchor router is also an MAP, and the MR obtains a regional care-of-address from the MAP. Thubert, et al. Expires August 15, 2004 [Page 7] Internet-Draft RO-Taxonomy February 2004 5. Nested Mobile Network 5.1 Nested Tunnels Optimization This section covers the case where one mobile network is within another mobile network. For example, a user brings a Personal Area Network (PAN) consisting of some IP devices to a train which is also using NEMO technology. In another example, a car which conatins a mobile network moves into the ferry which has another mobile network. This configuration of mobile networks within another mobile network is called nested Mobile Networks. Let us illustrate the problem by an example. In this example, the nested Mobile Network has a tree topology. In the tree each node is a basic Mobile Network, represented by its MR. +---------------------+ | Internet |---CN +---------------|-----+ / Access Router MR3_HA | ======?====== MR1 | ====?=============?==============?=== MR5 MR2 MR6 | | | =========== ===?========= ============= MR3 | ==|=========?== Net3 LFN1 MR4 | ========= An example nested Mobile Network This example focuses on a Local Fixed Node (LFN) at depth 3 (in Net3) inside the tree, represented by its mobile router MR3. The path to the Top Level Mobile Router (TLMR) MR1 and then the Internet is: MR3 -> MR2 -> MR1 -> Internet Consider the case where a LFN belonging to Net3 sends a packet to a Correspondent Node (CN) in the Internet, and the CN replies back. Thubert, et al. Expires August 15, 2004 [Page 8] Internet-Draft RO-Taxonomy February 2004 With no Nested Tunnels Optimization, we would have three bi-directional nested tunnels, as described in [3] and illustrated in the following drawings: -----------. --------/ /-----------. -------/ | | /----------- CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN MR3_HA -------\ | | \----------- MR3 MR2_HA --------\ \----------- MR2 MR1_HA ----------- MR1 No Nested Tunnels Optimization Such a solution introduces the following problems: "Pinball" routing Both inbound and outbound packets will flow via the HAs of all the MRs on their path within the NEMO, with increased latency, less resilience and more bandwidth usage. To illustrate this effect, the figure below shows the route taken by a packet sent from LFN to CN: +--> HAofMR1 ---------------------+ | | +----------------- HAofMR2 <--+ | | | +---------------+ | | V HAofMR3 <------+ CN | | LFN --> MR1 --> MR2 --> MR3 'Pinball' Routing Packet size An extra IPv6 header is added per level of nesting to all the packets. The header compression suggested in [4] cannot be applied because both the source and destination (the intermediate MR and Thubert, et al. Expires August 15, 2004 [Page 9] Internet-Draft RO-Taxonomy February 2004 its HA), are different hop to hop. On the other hand, with a Nested Tunnel Optimization, we would have at most one bi-directional tunnel outside the Mobile Network, that may depend on the traffic flow: __- --_ Tunnel---------------------------- MR1 ( Mobile ) MR3 CN ----------( - - - - - - - - - - ( - - - - )--------- LFN Endpoint---------------------------- MR1 ( Network ) MR3 --___--- Nested Tunnels Optimization The end-point of such a Tunnel on the Mobile side may either be MR1 or MR3, depending on the solution. In the case of a Mobile Node visiting Net3, that Mobile Node may also be the end-point. The potential approaches for avoiding the nesting of tunnels include: Mobile Aggregation This model applies to a category of problems were the Mobile Networks share a same administration and consistently move together (e.g. a fleet at sea). In this model, there is a cascade of Home Agents. The main Home Agent is fixed in the infrastructure, and advertises an aggregated view of all the Mobile Networks. This aggregation is actually divided over a number of Mobile Routers, the TLMRs. The TLMRs subdivide some of their address space to the other Mobile Routers forming their fleet, for which they are Home Agent. As Home Agents, the TLMRs terminate MIP Tunnels from the inside of the Mobile Network. As Mobile Router, they also terminate their home Tunnels. As routers, they forward packets between the 2 tunnels. Surrogate The TLMR acts as a proxy in the MIP registration, in a fashion of MIPv4 Foreign Agent or HMIP MAP (see [9]). For instance, the TLMR maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and switches packets between the two. Thubert, et al. Expires August 15, 2004 [Page 10] Internet-Draft RO-Taxonomy February 2004 Internal Routing and gateway This item can be approached from a MANET standpoint. This was already done for DSR (see [10]) and AODV (see [11] and [8]) From a Nemo standpoint, a full MANET is not necessary since the goal is to find a way to the infrastructure, as opposed to any-to-any connectivity. RRH The Reverse Routing Header (RRH) approach avoids the multiple encapsulation of the traffic but maintains the home tunnel of the first MR on the egress path. It is described in details in [5]. The first MR on the way out (egress direction) encapsulates the packet over its reverse tunnel, using a form of Record Route header, the RRH. The next MRs simply swap their CoA and the source of the packet, saving the original source in the RRH. The HA transforms the RRH in a Routing Header to perform a Source Routing across the nested Mobile Network, along the ingress path to the target MR. Access Router Option The Access Router Option (ARO) approach [6] is somewhat similar to the RRH in that only the home tunnel of the first MR in the egress path is maintained. This is done by having MR to send an ARO in Binding Update to inform its HA the address of its access router. Using this information, HA can build a Routing Header to source-route a packet to the target MR within in a nested mobile network. Details can be found in [6]. Prefix delegation approach The prefix delegation approach [7] is somewhat to HMIPv6 what Nemo is to MIPv6. The Access Router of the nested structure is both a Nemo Home Agent and a DHCP-PD server, for an aggregation that it owns and advertises to the Infrastructure. When visiting the nested structure, each MR is delegated a mobile network prefix from the AR using DHCP-Prefix Delegation. The MR registers this delegated MNP to the AR that is acting as a Nemo Home Agent. The MR also autoconfigures an address from the delegated MNP and uses it as a CareOf to register its own MNPs to its own Home Agent using Nemo basic support. It is possible for a MR to protect its own MNPs while advertising in the clear the local MNP for other MRs to roam in. This allows a strict privacy of visited and visitors, and enables some specific policies in each Mobile Router. Details can be found in [7]. Thubert, et al. Expires August 15, 2004 [Page 11] Internet-Draft RO-Taxonomy February 2004 5.2 Route Optimization inside the Nested Mobile Network Although optimization within a mobile network is not within the charter of the NEMO working group, it might be insightful to discuss such optimizations. The expectation is that the mobile routes installed by NEMO can cohabit with a MANET support that would perform the RO inside the Nested Mobile Network. In other words, MIP redistributes its prefixes locally to a MANET and the MR-HA tunnel is bypassed. 6. General Considerations 6.1 Securing the protocol in nested tunnels optimization These approaches are generally difficult to secure unless all the Mobile Routers and Visiting Mobile Node belong to a same administrative domain and share predefined Security Associations. Even if an intermediate MR is 'trusted', this does not prove it is able to provide the necessary bandwidth, and may not provide a good service. Eventually, a MR that is capable of securing (IPSec) its traffic may select a Mobile Access Router based on quality of service heuristics as opposed as trust. The problem is global to the whole Mobile Network in the case of a MANET-based solution. For an RRH-based solution, the threat comes from on-axis MRs in the nested Mobile Network but is mostly limited to denial of service. This is detailed in [5]. The approach taken is to limit the threat to Black Hole and Grey Hole by using IPSec. 6.2 Recursive complexity in route optimization A number of drafts and publications suggest -or can be extended to- a model where the Home Agent and any arbitrary Correspondent would actually get individual binding from the chain of nested Mobile Routers, and form a routing header appropriately. An intermediate MR would keep track of all the pending communications between hosts in its subtree of Mobile Networks and their CNs, and a binding message to each CN each time it changes its point of attachment. If this was done, then each CN, by receiving all the binding messages and processing them recursively, could infer a partial topology of the nested Mobile Network, sufficient to build a multi-hop routing header for packets sent to nodes inside the nested Mobile Network. Thubert, et al. Expires August 15, 2004 [Page 12] Internet-Draft RO-Taxonomy February 2004 However, this extension has a cost: 1. Binding Update storm when one MR changes its point of attachment, it needs to send a BU to all the CNs of each node behind him. When the Mobile Network is nested, the number of nodes and relative CNs can be huge, leading to congestions and drops. 2. Protocol Hacks Also, in order to send the BUs, the MR has to keep track of all the traffic it forwards to maintain his list of CNs. In case of IPSec tunneled traffic, that CN information may not be available. 3. CN operation The computation burden of the CN becomes heavy, because it has to analyze each BU in a recursive fashion in order to infer nested Mobile Network topology required to build a multi hop routing header. 4. Missing BU If a CN doesn't receive the full set of PSBU sent by the MR, it will not be able to infer the full path to a node inside the nested Mobile Network. The RH will be incomplete and the packet may or may not be delivered. 5. Obsolete BU If the Binding messages are sent asynchronously by each MR, then, when the relative position of MRs and/or the TLMR point of attachment change rapidly, the image of Mobile Network that the CN maintains is highly unstable. If only one BU in the chain is obsolete due to the movement of an intermediate MR, the connectivity may be lost. 6.3 Mobile Access router selection In some case, nested Mobile Networks attaches to visiting network with multiples mobile access router that are gateways to the global internet. These RO methods may cover the function in which how the MR in the nested Mobile Network choose the one of the mobile access routers. This function is not explicitly described in current methods and needs to be discussed. Thubert, et al. Expires August 15, 2004 [Page 13] Internet-Draft RO-Taxonomy February 2004 6.4 Mobility transparency and RO [cwng's interpretation of Mobility Transparency in RO] It is desirable in mobility-related protocols that the mobility of a mobile node is transparent to other entities and other layers in the mobile node. The Basic NEMO support achieve this mobility transparency of the mobile network to the MNNs by a MR-HA tunnel so that MNNs need not be aware of the MR's change in point of attachment. Such a feature is, as mentioned, desirable. However, when route optimizations, end-to-end principle, and other factors come into consideration, achieving mobility transparency may not be practical. For instance, to achieve nested tunnel optimizations, the mobility of the top-level MR is often exposed to other entities, such as the HA of a nested MR. In the case of MR performing BU for MNNs, it might be necessary to pass mobility information of the MR to CN (and even MNN) in order not to break the end-to-end principle. For the scenario of optimization using infrastructure, the mobility information might be necessarily exposed to correspondent routers or MAP. Thus, one should bear in mind when designing RO solution that a sacrifice might be necessary when weighing conflicting factors such as mobility transparency, optimization level, and end-to-end integrity. [Hosik's interpretation of Mobility Transparency in RO] In the case of extended support of NEMO such as nested NEMO, mobility transparency is desirable but that is not mandatory for the efficiency of the route optimization. For example, the notebook and PDA inside a vehicle can access to the Internet through the mobile router of the vehicle. In that case, if the movement of the vehicle affects to the notebook or the PDA, they can perform individual binding update operation to the correspondent node or its home agent but that can cause location privacy problem. [Onishi's interpretation of Mobility Transparency in RO] In RO solutions, MR can optimize the route between its own HA and MR. It is desirable that communication can not be interrupted by this route optimization. ???? Thubert, et al. Expires August 15, 2004 [Page 14] Internet-Draft RO-Taxonomy February 2004 6.5 Multihoming Considerations In multihomed mobile networks, route optimization is dependant on how the connections to the Internet are available and selected. In case of macro mobility, we may have multiple HAs from place to place. New route optimization could be possible by routing between CN and one of the multiple Home Agents (possibly using differenc Home Addresses). When multiple connections are available for the purpose of fault tolerance, a selection mechanism is needed for CN to eveluate the connection availability in order to perform route optimization. 7. Conclusion The Problem space of Route Optimization in the NEMO context is multifold and can be split is several work areas. It will be critical, though, that the solution to a given piece of the puzzle be compatible and integrate smoothly with the others. Hopefully, the solutions will build on MIPv6 ([1]), as recommended by the NEMO Charter. On the other hand, MIPv6 seems to be evolving in a direction that makes it more and more difficult to provide a NEMO solution with backward compatibility, since: 1) The RR test prevents a MR-LFN dichotomy on the Mobile Side, 2) The RR test has no negotiable option and is not open for extension, and 3) The HaO and RH type 2 are designed for a collocated CareOf Address. More specifically, they are not designed to be multi-hop as RRH is, and not extensible, though RRH can be considered as an extension of HAO. The authors intent is to trigger fruitful discussions that in turn will enhance our common understanding of the problem space so that at some point, this paper turns into a problem statement for the Nemo Route Optimization. 8. Acknowledgements The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa and Patrick Wetterwald for their various contributions. Thubert, et al. Expires August 15, 2004 [Page 15] Internet-Draft RO-Taxonomy February 2004 References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-00 (work in progress), May 2003. [3] kniveton, t., "Mobile Router Support with Mobile IP", draft-kniveton-mobrtr-02 (work in progress), July 2002. [4] Deering, S. and B. Zill, "Redundant Address Deletion when Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr-deletion-00 (work in progress), November 2001. [5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-04 (work in progress), February 2004. [6] Tanaka, T. and C. Ng, "Securing Nested Tunnels Optimization with Access Router Option", draft-ng-nemo-access-router-option-00 (work in progress), November 2002. [7] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", draft-droms-nemo-dhcpv6-pd-01 (work in progress), February 2004. [8] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc Networks", draft-wakikawa-manet-globalv6-03 (work in progress), October 2003. [9] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical MIPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-06 (work in progress), July 2002. [10] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", draft-ietf-manet-dsr-09 (work in progress), April 2003. [11] Perkins, C., Royer, E. and S. Das, "Ad Hoc On Demand Distance Vector (AODV) Routing", draft-ietf-manet-aodv-11 (work in progress), July 2002. [12] Postel, J., "Internet Protocol", STD 5, RFC 791, September Thubert, et al. Expires August 15, 2004 [Page 16] Internet-Draft RO-Taxonomy February 2004 1981. [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Authors' Addresses Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 FRANCE EMail: pthubert@cisco.com Marco Molteni Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 FRANCE EMail: mmolteni@cisco.com Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG EMail: cwng@psl.com.sg Hiroyuki Ohnishi NTT network service systems laboratories, NTT cooperation 9-11, Midori-Cho 3-Chome Musashino-shi Tokyo 180-8585 JAPAN EMail: ohnishi.hiroyuki@lab.ntt.co.jp Thubert, et al. Expires August 15, 2004 [Page 17] Internet-Draft RO-Taxonomy February 2004 Eun Kyoung Paik Seoul National University Shillim-dong, Kwanak-gu Seoul 151-744 KOREA EMail: eun@mmlab.snu.ac.kr Thubert, et al. Expires August 15, 2004 [Page 18] Internet-Draft RO-Taxonomy February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Thubert, et al. Expires August 15, 2004 [Page 19] Internet-Draft RO-Taxonomy February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Thubert, et al. Expires August 15, 2004 [Page 20]