[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-mip4-multiple-tunnel-support

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/