Mobility for IPv4 Working Group S. Gundavelli
Internet-Draft K. Leung
Intended status: Standards Track Cisco
Expires: January 4, 2010 K. Srinivasa
July 03, 2009
Multiple Tunnel Support for Mobile IPv4
draft-gundavelli-mip4-multiple-tunnel-support-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 January 4, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document defines extensions to Mobile IPv4 protocol for allowing
a mobile node or a mobile router with multiple interfaces to register
Gundavelli, et al. Expires January 4, 2010 [Page 1]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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
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
Gundavelli, et al. Expires January 4, 2010 [Page 2]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 3]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 4]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 5]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 6]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 7]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 8]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 9]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 10]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 11]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 12]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 13]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 14]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 15]
Internet-Draft Multiple Tunnel Support for Mobile IPv4 July 2009
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 January 4, 2010 [Page 16]