Mobility for IPv4 Working Group S. Gundavelli Internet-Draft K. Leung Intended status: Standards Track Cisco Expires: June 11, 2009 K. Srinivasa December 08, 2008 Multiple Tunnel Support for Mobile IPv4 draft-gundavelli-mip4-multiple-tunnel-support-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 June 11, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines extensions to Mobile IPv4 protocol for allowing a mobile node or a mobile router with multiple interfaces to register a care-of address for each of the available interfaces and to simultaneously establish multiple Mobile IP tunnels to the home agent, each through a different interface path. This capability is required for enabling a mobile node to utilize all the available wireless access links and build an higher aggregated data pipe to the Gundavelli, et al. Expires June 11, 2009 [Page 1] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 home agent by setting the home address reachability over all of those tunnel paths. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Extensions . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Multiple Tunnel Request Extension . . . . . . . . . . . . 6 4.2. New Registration Reply Codes . . . . . . . . . . . . . . . 8 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Mobile Node Operation: . . . . . . . . . . . . . . . . . . 8 5.2. Foreign Agent Operation: . . . . . . . . . . . . . . . . . 10 5.3. Home Agent Operation: . . . . . . . . . . . . . . . . . . 10 6. Supported Configuration . . . . . . . . . . . . . . . . . . . 11 7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 13 8. Protocol Configuration Variables . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Gundavelli, et al. Expires June 11, 2009 [Page 2] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 1. Introduction With the availability of multiple wireless technologies and services, mobile devices are now equipped with multiple wireless interfaces and have the ability to connect to the network over any of those interfaces and access the Internet. However, the available bandwidth on any single interface or the connected link is still quite low and is not sufficient either for a mobile router to support large mobile networks with many users or even for a mobile node to be able to run multimedia or other high bandwidth consuming applications. The operation defined in the Mobile IP Protocol [RFC-3344], allows a mobile node to continue to use its home address as it moves around the Internet. Based on the mode of operation, there will be a tunnel that will be set up between the home agent and the mobile node, or between the home agent and the foreign agent where the mobile node is attached. In both of these modes, there will only be one interface on the mobile node that is receiving the traffic from the home agent. However, this is not efficient and requires an approach where the mobile node can use more than one interfaces for reaching the home network. The objective being efficient use of all available links to obtain higher aggregated bandwidth for the tunneled traffic between the home agent and the mobile node. This document presents extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of those active interfaces and establish overlay network of tunnels to the home agent over those interface paths. These multiple paths can be used for load balancing the mobile nodes traffic across all those tunnels based on various traffic policies. The specifics on the definition of these traffic policies, or how they are negotiated is outside the scope of this document and future work can offer such dynamic negotiation capability. The focus of this document is only to extend the protocol to support multiple tunnel registration, expose information to the home agent about all of the mobile node's registered roaming interfaces and define a label for each of its registration through a given interface. Any static or dynamic traffic policies can leverage this information for IP forwarding decisions. In the absence of any applied traffic policies, these multiple tunnel paths appear to the home agent and the mobile node as alternate routing paths and the default IP forwarding behavior of per-flow load balancing will leverage all the available wireless links and will result in a larger aggregated egress traffic throughput and that is fundamentally the today's market requirement for mobile router deployments and so is the goal of this document. Gundavelli, et al. Expires June 11, 2009 [Page 3] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 2. Conventions & Terminology 2.1. Conventions 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 RFC 2119 [RFC-2119]. 2.2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the Mobile IP base specification [RFC- 3344]. In addition this document introduces the following terms. Binding Identifier (BID) It is an identifier for a specific binding of a mobile node. A mobile node when it registers multiple bindings with the home agent using different care-of addresses, each of those bindings are given a unique identifier and this identifier is called the binding identifier. The identifier is unique within all the bindings for a given mobile node. Bulk Re-registration It is a procedure by which a mobile can extend the lifetime of all its bindings on a home agent by sending a single re-registration request. Home Agent Address (HAA) The IP address of the home agent. Foreign Agent Care-of Address (FA-CoA) The care-of address of the foreign agent. Gundavelli, et al. Expires June 11, 2009 [Page 4] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 3. Solution Overview HOA HAA | | +------+ Interface_1 MIP Tunnel +-----+ | |----WIFI-----[FA]---=================== | | | M | FA_COA_1 | | H | | O | | | O | | B | Interface_2 MIP Tunnel | | M | | I |----EV-DO---===========================| | E | | L | COA_2 | | | | E | |------| A | | | Interface_3 MIP Tunnel | | G | | N |----WIMAX---===========================| | E | | O | COA_3 | | N | | D | | | T | | E | Interface_4 MIP Tunnel | | | | |-----LTE---============================ | | +------+ COA_4 +-----+ Figure 1: Mobile Node with multiple tunnels to the home agent Figure 1, illustrates a mobile node having established multiple tunnels with the home agent. Some of the tunnels are established directly and some through a foreign agent. Following is the operational behavior of the system with such configuration: The mobile node registers to the home agent through each of the available roaming interfaces. As part of the registration, the mobile node identifies the interface through which the specific registration is setup. The home agent will create multiple bindings for the mobile node. Each binding identifies the mobile node's registration over that interface. The binding specifically identifies the type of interface, care-of address, the Mobile IP tunnel associated with that binding and the binding identifier. The throughput capacity of each of these tunnels is dependent on the access technology over which the mobile node is attached. The mobile node notifies the interface properties for each attached interface and the home agent can user this as a metric for it traffic policies. The home agent sets up the routing for the mobile node's home address. The home address will be reachable over any of the Gundavelli, et al. Expires June 11, 2009 [Page 5] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 established tunnels for that mobile node. Based on the enabled traffic policies, the home agent can distribute the data traffic over any of those tunnels in any fashion. When there are no explicit traffic policies in place, the default routing policy of per-flow load balancing will be in affect. The care-of address associated with any of those interfaces may keep changing, as the mobile nodes moves in the network and changes its point of attachment through any of its interfaces. 4. Message Extensions 4.1. Multiple Tunnel Request Extension This extension is for requesting the home agent to register the current care-of address listed in this Registration Request as one of the care-addresses through which the mobile node can be reached. It is also for carrying the information specific to the interface through which the mobile node is currently performing the registration. This extension is a non-skippable extension and MAY be added to the Registration Request message by the mobile node. There MUST not be more than one instance of this extension present in the message. The Multiple Tunnel Request extension MAY be added to the Registration request only by the mobile node. This extension MUST NOT be added by the home agent or by the foreign agent either to the Registration Request or to the Registration Reply. This extension should be protected by Mobile Home Authentication extension [RFC-3344]. As per Section 3.2 and 3.6.1.3 of [RFC-3344], the mobile node MUST place this Extension before the Mobile-Home Authentication Extension in the registration messages, so that this extension is integrity protected. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | If-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding-Id |B|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gundavelli, et al. Expires June 11, 2009 [Page 6] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 Figure 2: Multiple Tunnel Request Extension Type IANA-1 Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to value of 6. Sub-Type This 8-bit field MUST be set to a value of 0. Interface-Type (If-Type) Type of interface through which the mobile node is connected. The permitted values for this are from the Access Technology Type registry. Binding-Id (BID) This 16-bit field is the binding identifier. It uniquely identifies a specific binding of the mobile node, with which this request can be associated with. Typically, this can be set to the interface index assigned by the operating system for that interface on the mobile node. Bulk Re-registration Flag (B) This flag, if set to a value of 1, is to notify the home agent to consider this request as a request to update all of the mobile node's bindings, upon accepting this specific request. This flag MUST NOT be set to a value of 1, if the value of the Registration Overwrite Flag (O) flag is set to a value of 1. Registration Overwrite (O) This flag, if set to a value of 1, is to notify the home agent that upon accepting this request, it should replace all of the mobile node's existing bindings with this binding. This flag MUST NOT be set to a value of 1, if the value of the Bulk Re- registration Flag (B) is set to a value of 1. This flag MUST be set to a value of 0, in de-registration requests. Gundavelli, et al. Expires June 11, 2009 [Page 7] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 Reserved (R) This 14-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Interface Bandwidth (If-BW) This 16-bit unsigned integer is used for conveying the available bandwidth of the interface associated with this request. The bandwidth is specified in kilo-bytes, fractions are to be rounded to the nearest integer. 4.2. New Registration Reply Codes This document defines the following new registration reply codes. MULTIPLE_TUNNEL_REQUEST_DENIED_BY_HA: IANA-2 Multiple tunnel support request rejected by HA MULTIPLE_TUNNEL_REQUEST_DENIED_BY_FA: IANA-3 Multiple tunnel support request rejected by FA. 5. Protocol Operation 5.1. Mobile Node Operation: Mobile node at home: o When the mobile node is at home, the communication with other nodes occurs normally without the use of Mobile IP functionality. The method used by a mobile node to determine that it is attached to the home link is per the base Mobile IP Specification [RFC- 3344]. If the mobile node moves into the home network from a foreign network and if it had previous bindings with the home agent, then it SHOULD deregister all of its registered care-of addresses with the home agent, as specified in Section 3.6.1.2 of [RFC-3344]. o If the mobile node for connecting to the home link, uses either a designated interface or any of the available interfaces to connect to the home link and if it detects its home link through any of Gundavelli, et al. Expires June 11, 2009 [Page 8] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 those interfaces, then it MUST consider its on the home link and SHOULD perform the deregistration procedure. o Simultaneous use of home link and foreign link at the same time for roaming is not supported by this specification. Mobile node in the foreign network o The mobile node SHOULD consider its away from home, if it is unable to attach to its home link through any of its active interfaces. o If the value of the configuration variable, EnableMultipleTunnelSupport is set to a value of 1, then the mobile node SHOULD register a care-of address for each of those interfaces, by sending a Registration Request. Each of the requests sent MUST contain the care-of address of the respective interface and the Multiple Tunnel Request extension reflecting the interface properties. The mobile node MUST ensure that the Registration Request is routed through the specific interface for which the registration is sough for. o If the value of the configuration variable, EnableMultipleTunnelSupport is set to a value of 0, then the mobile node SHOULD register without the Multiple Tunnel Request extension specified in this document. Considerations from [RFC- 3344] and [RFC-5177] SHOULD be applied. o The mobile node on receiving a registration reply with the code value set to either MULTIPLE_TUNNEL_REQUEST_DENIED_BY_HA (multiple tunnel support request rejected by HA), or MULTIPLE_TUNNEL_REQUEST_DENIED_BY_FA (multiple tunnel support request rejected by FA), MAY choose to register without the Multiple Tunnel Request extension specified in this document. Considerations from [RFC-3344] and [RFC-5177] SHOULD be applied. o The mobile node on receiving a Registration Reply for a Registration Request that it sent over a specific interface and using a co-located care-of address (with 'D' bit set), should check for the reply code in the reply message. If the Code field indicates that the request has been accepted, the mobile node SHOULD create a tunnel with the registered care-of address as the tunnel source address, the home agent address as the tunnel destination address and for the negotiated encapsulated mode. The mobile node can use this tunnel in addition to any other tunnels that it established with the home agent for reverse tunneling the mobile node's traffic. Gundavelli, et al. Expires June 11, 2009 [Page 9] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 o The mobile node on receiving a Registration Reply for a Registration Request that is sent over a specific interface and using a foreign agent care-of address, should check for the reply code in the reply message. If the code value in the reply set to value of 0 (registration accepted), the mobile node can use this interface (through the foreign agent), for forwarding the mobile node's traffic. This may be in addition to other paths associated with its other interfaces. 5.2. Foreign Agent Operation: The foreign agent upon receipt of a Registration Request with the Multiple Tunnel Request extension from a mobile node, SHOULD check the configuration variable, EnableMultipleTunnelSupport. If the value of this variable is set to 0, the foreign agent MUST reject the request with a registration reply and with the code set to MULTIPLE_TUNNEL_REQUEST_DENIED_BY_FA. As per the Mobile IP specification [RFC-3344], when a mobile node is using a foreign agent services and its care-of address, the routing between the mobile node and the foreign agent is based on layer-2 forwarding, using MAC address as the communication end point identifier. The foreign agent maintains an association between the home address of the mobile node, its MAC address and the bi- directional tunnel between the home agent and the foreign agent. Typically, the foreign agent forwards all the mobile node's home address traffic, to the mobile node after it removes the outer header. As per this specification, for the scenario where the mobile node attaches to the foreign agent through more than one interface, the foreign agent can use any of the paths for delivering the packets to the mobile node and it can make this decision based on the established traffic policies. 5.3. Home Agent Operation: As per the operation defined in the Mobile IP Protocol [RFC-3344], the home agent is required to maintain multiple bindings for a mobile node when it is supporting simultaneous bindings for that registration. When the home agent allows simultaneous bindings, it will tunnel a separate copy of each arriving datagram to each of those care-of addresses, and the mobile node will receive multiple copies of datagrams destined to it. The operation defined in this specification allows a mobile node to register from multiple interfaces using different care-of addresses and have multiple tunnels from the home agent to each of those care-of addresses and for distributing the traffic load across those tunnels. This is a different model than the simultaneous bindings when it comes to the datagram routing. However, the basic ability for the home agent to Gundavelli, et al. Expires June 11, 2009 [Page 10] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 associate a mobile node with multiple care-of addresses is the same. The home agent upon receipt of a Registration Request with the Multiple Tunnel Request extension from a mobile node, SHOULD check the configuration variable, EnableMultipleTunnelSupport. If the value of this variable is set to 0, the home agent MUST reject the request with a registration reply and with the code set to MULTIPLE_TUNNEL_REQUEST_DENIED_BY_HA. The home agent upon receipt of a registration request with the Multiple Tunnel Request extension and if the (B) flag in the request is set to a value of 1, the home agent upon accepting the request MUST extend the lifetime of all the mobile node's bindings. The home agent upon receipt of a registration request with the Multiple Tunnel Request extension and if the (O) flag in the request is set to a value of 1, the home agent upon accepting the request MUST consider this as a request to replace all other mobile node's bindings with just one binding and that is the binding associated with this request. 6. Supported Configuration Following are some of the configurations where the mobile node can register multiple care-of addresses and leverage all the available roaming interfaces. In this scenario, the home agent can forward the mobile node's traffic through any of the established tunnels. HOA | +--------+ Interface_1 Tunnel_1 +--------+ | |---===========================| | | | | CoA_1 | | | | Mobile | Interface_2 Tunnel_2 |HAA | Home | | Node |---===========================|----| Agent | | | CoA_2 | | | | | +----+ Tunnel_3 | | | | |-----| FA |---================| | | +--------+ +----+ FA_CoA +--------+ Figure 3: Mobile Node registering directly with the home agent Gundavelli, et al. Expires June 11, 2009 [Page 11] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 In this scenario, there is only one tunnel between the foreign agent and the home agent and both these entities have to send and receive the mobile node's traffic through that tunnel. However, the foreign agent can forward the mobile node's home address traffic that it received from the home agent to any of the mobile node's attached interfaces. The mobile node can also use any of its interfaces for sending and receiving it home address traffic. HOA | +--------+ If_1 +--------+ | |------- +---+ FA_CoA Tunnel_1 HAA | | | Mobile | |___|FA |---===================---| Home | | Node | If_2 | +---+ | Agent | | |------- | | +--------+ +--------+ Figure 4: Mobile node attached to the same foreign agent through more than one interface Mobile node registering through the same foreign agent. HOA | FA_CoA_1 +--------+ If_1 | Tunnel_1 +--------+ | |------------|=================== | | | Mobile | +--+ |HAA| Home | | Node | |FA| ----| Agent | | | If_2 +--+ | | | | |------------|=================== | | +--------+ | Tunnel_2 +--------+ FA_CoA_2 Figure 5: Mobile Node registering its multiple interfaces through the same foreign agent Mobile node behind a NAT and with multiple tunnels to the home agent. In this configuration, the tunnels between the home agent and the foreign agent or setup using UDP encapsulation mode [RFC-3519]. Gundavelli, et al. Expires June 11, 2009 [Page 12] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 HOA | +---+ +--------+ +--+ | | +--------+ | |------------|FA|---==========| |=========== | | | Mobile | +--+ | N | |HAA| Home | | Node |----=========================| A |===========----| Agent | | | If_2 | T | | | | | |----=========================| |=========== | | +--------+ +---+ +--------+ Figure 6: Mobile Node registering and some other interfaces through one or more foreign agents 7. Routing Considerations Most IP devices support the two alternative traffic load-balancing schemes, Per-flow and Per-packet load balancing. These load balancing schemes allow the forwarding device to evenly distribute traffic based on the criteria of per-packet or on a per-flow basis, across all the available equal-cost links through which a destination can be reached. The default forwarding behavior of Per-flow load balancing will ensure a given flow always takes the same path and will eliminate any packet re-ordering issues and that is critical for delay sensitive traffic. Whereas the per-destination load balancing scheme leverages all the paths much more affectively, but with the potential issue of packet re-ordering on the receiver end. A host can choose to enable any of these approaches. This document recommends the home agent, foreign agent and the mobile node to adopt the default forwarding behavior of per-flow load balancing for sending mobile node's home address traffic when in the presence of multiple paths. In the absence of more sophisticated traffic management schemes, this forwarding approach is sufficient and serves the basic purpose of this document. It is possible to install more complex, static or dynamically negotiated traffic management policies, but that is outside the scope of this work. This document provides the basic required hooks and future work can plug-in such capability and extend this feature. 8. Protocol Configuration Variables The following protocol configuration variables are required for system management and these variables MUST be configurable on all the mobility entities. The configured values for these protocol variables MUST survive service restarts. Gundavelli, et al. Expires June 11, 2009 [Page 13] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 EnableMultipleTunnelSupport. This flag indicates whether or not the mobility entity on which this protocol variable is configured needs to enable Multiple Tunnel support feature. This protocol variable is applicable to home agent, foreign agent and the mobile node. The default value for this flag is set to value of 1, indicating that the multiple tunnel support SHOULD be enabled. When the value for this flag is set to value of 0, multiple tunnel support SHOULD be disabled. 9. IANA Considerations This document proposes one new extension and two new error codes that require a type number and an error code values to be assigned by IANA. Section 4.1 defines a new Mobile IP extension, the Multiple Tunnel Request Extension. The type number for this extension is IANA-1 [TBD]. Section 4.2 defines a new error code, MULTIPLE_TUNNEL_REQUEST_DENIED_BY_HA (multiple tunnel support request rejected by home agent). The value of this error code is IANA-2 [TBD]. The value for this error code MUST be allocated from the Mobile IP Registration Reply message code values, specifically from the home agent error code group, as explained in Section 6.4 of [RFC- 3344]. Section 4.2 defines a new error code, MULTIPLE_TUNNEL_REQUEST_DENIED_BY_FA (multiple tunnel support request rejected by foreign agent). The value of this error code is IANA-3 [TBD]. The value for this error code MUST be allocated from the Mobile IP Registration Reply message code values, specifically from the foreign agent error code group, as explained in Section 6.4 of [RFC-3344]. 10. Security Considerations This specification allows a mobile node to establish multiple tunnels with the home agent, by registering a care-of address for each of its active roaming interfaces. This essentially allows the mobile node's home address to be reachable through all of its active and registered Gundavelli, et al. Expires June 11, 2009 [Page 14] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 roaming interfaces. This new capability has no impact on the protocol security, however it certainly improves the mobile node's reachability. The Multiple Tunnel Request extension, defined in this document is to be carried in Mobile IP Registration messages and these messages are authenticated and integrity protected as described in [RFC-3344]. Therefore, this specification does not weaken the security of Mobile IP Protocol, or, introduce any new vulnerabilities. 11. Acknowledgements We like to thank all those people who have reviewed this document and helped us improve this specification. 12. References 12.1. Normative References [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC-2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC-3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [RFC-3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC-3519] Levkowetz, H., Vaarala, S., "NAT Traversal for Mobile IP", RFC 3519, April 2003. Gundavelli, et al. Expires June 11, 2009 [Page 15] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 12.2. Informative References [RFC-5177] Leung, K., Dommety, G., Narayanan, V. and A. Petrescu, "Network Mobility (NEMO) Extensions for Mobile IPv4", April 2008. [ID-MCOA-MIPV6] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-10.txt, November 2008. Authors' Addresses Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: kleung@cisco.com Srinivasa K. Phone: Email: krsriniva@gmail.com Gundavelli, et al. Expires June 11, 2009 [Page 16] Internet-Draft Multiple Tunnel Support for Mobile IPv4 December 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Gundavelli, et al. Expires June 11, 2009 [Page 17]