Skip to main content

Flow Binding Support for Mobile IPv4
draft-ietf-mip4-multiple-tunnel-support-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7629.
Authors Sri Gundavelli , Kent Leung , George Tsirtsis , Hesham Soliman , Alexandre Petrescu
Last updated 2013-01-31
Replaces draft-gundavelli-mip4-multiple-tunnel-support
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7629 (Experimental)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-mip4-multiple-tunnel-support-05
Mobility for IPv4 Working Group                       S. Gundavelli, Ed.
Internet-Draft                                                  K. Leung
Intended status: Standards Track                                   Cisco
Expires: August 4, 2013                                      G. Tsirtsis
                                                                Qualcomm
                                                              H. Soliman
                                                    Elevate Technologies
                                                             A. Petrescu
                                                                CEA LIST
                                                        January 31, 2013

                  Flow Binding Support for Mobile IPv4
             draft-ietf-mip4-multiple-tunnel-support-05.txt

Abstract

   This specification defines extensions to Mobile IPv4 protocol for
   allowing a mobile node with multiple interfaces to register a care-of
   address for each of its network interfaces and to simultaneously
   establish multiple Mobile IP tunnels with its home agent.  This
   essentially allows the mobile node to utilize all the available
   network interfaces and build an higher aggregated data pipe with the
   home agent for its home address traffic.  Furthermore, these
   extensions also allow the mobile node and the home agent to negotiate
   flow policies for binding individual traffic flows with the
   registered care-of addresses.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 4, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the

Gundavelli, et al.       Expires August 4, 2013                 [Page 1]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions & Terminology  . . . . . . . . . . . . . . . . . .  3
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Message Extensions . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Alternate-CoA Extension  . . . . . . . . . . . . . . . . .  5
     4.2.  Flow Identification Extension  . . . . . . . . . . . . . .  7
   5.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  Mobile Node Considerations . . . . . . . . . . . . . . . . 17
       5.1.1.  Using the Alternate-CoA extension  . . . . . . . . . . 17
       5.1.2.  Using the Flow Identification Extension  . . . . . . . 18
     5.2.  Home Agent Considerations  . . . . . . . . . . . . . . . . 19
       5.2.1.  Handling Alternate-CoA extensions  . . . . . . . . . . 19
       5.2.2.  Handling Flow Identification Extensions  . . . . . . . 20
   6.  Routing Considerations . . . . . . . . . . . . . . . . . . . . 23
   7.  Protocol Configuration Variables . . . . . . . . . . . . . . . 23
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     12.2. Informative References . . . . . . . . . . . . . . . . . . 25

Gundavelli, et al.       Expires August 4, 2013                 [Page 2]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

1.  Introduction

   With the ubiquitous availability of wireless networks supporting
   different access technologies, 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 network.  It is
   desirable for the mobile node to leverage all the available network
   connections for accessing network services.

   The operation defined in the Mobile IP Protocol [RFC5944], 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 specification defines extensions to Mobile IPv4 protocol for
   allowing a mobile node with multiple interfaces to register a care-of
   address for each of its network interfaces and to simultaneously
   establish multiple Mobile IP tunnels with its home agent.
   Furthermore, this specification also defines extensions to allow the
   mobile node and the home agent to optionally negotiate flow policies
   for binding individual traffic flows with the registered care-of
   addresses.

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 [RFC2119].

2.2.  Terminology

   All the mobility related terms used in this document are to be
   interpreted as defined in [RFC5944] and [RFC3753].  In addition this
   document uses the following terms.

   Binding Identifier (BID)

Gundavelli, et al.       Expires August 4, 2013                 [Page 3]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

      It is an identifier for a specific binding of a mobile node.  A
      mobile node, when it registers multiple bindings with its 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.

   Flow Identifier (FID)

      It is an identifier for a given IP flow, uniquely identified by
      source address, destination address, protocol type, source port
      and destination port.

3.  Overview

   This document presents extensions to the Mobile IP protocol for
   allowing a mobile node to register multiple care-of addresses over
   which it can be reachable.  Each of the registered care-of address
   will be identified by a unique binding identifier (BID).  There will
   be multiple tunnels between the mobile node and the home agent, one
   tunnel for each of the registed bindings.  These multiple tunnel
   paths can be used for load balancing the mobile node's home address
   traffic based on the negotiated traffic policies.  The extensions
   specified in this document additionally allow the mobile node and the
   home agent negotiate flow policies for binding individual traffic
   flows to the registered care-of addresses.  In the absence of any
   negotiated 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.

   HoA-1
      |
   +=====+                                       +=====+
   |     | CoA-1              Tunnel-1           |     |
   |     |---===={ WIFI }=================\      |     |
   |     |                                 \     |     |
   |     | CoA-2              Tunnel-2      \    |     |
   | MN  |---===={ LTE }=====================----| HA  |
   |     |                                  /    |     |
   |     | FA-CoA-3           Tunnel-3     /     |     |
   |     |---{ CDMA }---[FA]==============/      |     |
   |     |                                       |     |
   +=====+                                       +=====+

Gundavelli, et al.       Expires August 4, 2013                 [Page 4]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

       Figure 1: Mobile Node with multiple tunnels to the home agent

   Figure 1, illustrates a mobile node attached to the network over
   three different access technologies, WiFI, LTE and CDMA.  The mobile
   node is assigned home address, HoA-1, has care-of addresses CoA-1,
   CoA-2 and CoA-3 and has established tunnels Tunnel-1, Tunnel-2 and
   Tunnel-3 with its home agent.

   +-------+----------------------+------------------------------------+
   | Flow  | CoA/Tunnel/BID       | Negotiated Flow Policy             |
   | Id    |                      |                                    |
   +-------+----------------------+------------------------------------+
   | 1.    | CoA-1/Tunnel-1/BID-1 | All SIP Flows over WiFI            |
   | 2.    | CoA-2/Tunnel-2/BID-2 | All HTTP Flows over LTE value      |
   | 3.    | CoA-3/Tunnel-3/BID-3 | All SSH Flows over CDMA            |
   +-------+----------------------+------------------------------------+

                        Table 1: Flow Binding Table

   The above table is an example of how the individual flows are bound
   to different care-of addresses registered with the home agent.

4.  Message Extensions

   This specification defines the following new extensions.

4.1.  Alternate-CoA Extension

   A new skippable extension to the Mobile IPv4 header in accordance to
   the short extension format of [RFC5944] is defined here.  This
   extension is for requesting the home agent to register the care-of
   address present in this extension as one of the alternate care-
   addresses through which the mobile node can be reached.

   This 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.  There can be more than one instance of this
   extension present in the message.

   This extension should be protected by Mobile Home Authentication
   extension [RFC5944].  As per Section 3.2 and 3.6.1.3 of [RFC5944],
   the mobile node MUST place this Extension before the Mobile-Home
   Authentication Extension in the registration messages, so that this
   extension is integrity protected.

Gundavelli, et al.       Expires August 4, 2013                 [Page 5]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

      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    |       BID     |Priority/Status|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Care-of Address (CoA)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Interface-Type|                  Reserved                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 2: Alternate-CoA Extension

   Type

      Alternate-CoA Extension (skippable type range to be assigned by
      IANA)

   Length

      Indicates the length (in bytes) of the extension.  The length does
      NOT include the Type and Length bytes.

   BID (Binding ID)

      The BID field in an 8-bit unsigned integer that identifies the
      binding to the CoA included in this extension and it can be used
      to point to an Alternate-CoA that was registered earlier.

   Priority/Status

      When this extension is in a Registration Request this field
      specifies the priority field assigned to the care-of address.  The
      Priority field is an 8-bit unsigned integer.  The receiver can
      utilize this priority to determine the preference of the CoA used
      to deliver packets.  The lower the value the higher priority.  A
      value of 255 indicates that the CoA indicated should be
      deregistered.

      When this extension is in a Registration Reply this field
      indicates the status of the CoA.  The Status field is an 8-bit
      unsigned integer.  The possible status codes are listed in
      Table 2.

      For the Status field values 0-127 indicate success and values
      between 128 and 255 indicate failure.  The following values are
      defined for the Status field:

Gundavelli, et al.       Expires August 4, 2013                 [Page 6]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   +-------------------+--------+--------------------------------------+
   | Status            | Value  | Comments                             |
   +-------------------+--------+--------------------------------------+
   | Accepted          | 0      | The CoA is registered                |
   | BID Changed       | 1      | The BID associated with an existing  |
   |                   |        | CoA was changed to the new value     |
   | Reject            | 128    | The CoA is rejected                  |
   | Unknown BID       | 129    | The BID was not recognized           |
   +-------------------+--------+--------------------------------------+

              Table 2: Values for the Alternate-CoA Status field

   Care-Of Address (CoA)

      The CoA field is an 32-bit ipaddr.  Set to an alternative care-of
      address to the one included in the Registration Request header.
      This field may not be included if the extension is included in a
      Registration Request and if the BID field is set to the BID of CoA
      registered earlier.  In addition this field may not be included if
      the extension is included in a Registration Reply message.

   Interface Type

      Type of interface through which the mobile node is connected.  The
      permitted values for this are from the Access Technology Type
      registry defined in [RFC5213].

   Reserved

      This field is unused for now.  The value MUST be initialized to 0
      by the sender and MUST be ignored by the receiver.

4.2.  Flow Identification Extension

   A new skippable extension to the Mobile IPv4 header in accordance to
   the short extension format of [RFC5944] is defined here.  This
   extension is included in the Registration Request and Registration
   Reply messages.  This extension contains information that allows the
   home agent to identify a traffic flow and route it to a given
   address.  There can be more than one instance of this extension
   present in the message.

   This extension should be protected by Mobile Home Authentication
   extension [RFC5944].  As per Section 3.2 and 3.6.1.3 of [RFC5944],
   the mobile node MUST place this Extension before the Mobile-Home
   Authentication Extension in the registration messages, so that this

Gundavelli, et al.       Expires August 4, 2013                 [Page 7]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   extension is integrity protected.

   A Flow Identification extension is designed to populate and edit a
   mobile node classifier in the home agent.  A classifier selects
   packets based on the content of packet headers according to defined
   rules.  The Flow Identification extension defines a line in such a
   classifier.

   The Flow Identification extension has a flexible format that allows
   different fields to appear in the extension based on the way the
   mobile node chooses to represent the flow.  The flags following the
   length field indicate which of the fields used to identify the flow
   are present in the extension.  As a result, there is no fixed format
   for the flow identification extension.  This may result in slight
   complexity in the implementation; however, this extension will
   minimize the total length of the extension sent, which is
   particularly important for bandwidth-limited wireless links.

      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    |       FID     |Priority/Status|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Action     |    F-Type     |  Filter Descriptor...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      BIDs ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: Flow Identification Extension

   Type

      Flow Identification Extension (skippable type range.  Two values
      to be assigned for IPv4 and IPv6 by IANA)

   Length

      Indicates the length (in bytes) of the extension.  The length does
      NOT include the Type and Length bytes.

   FID

      The Flow Identifier field is an 8-bit unsigned integer identifying
      a flow.  This field is used to refer to an existing flow or to
      identify a new flow.

   Priority/Status

Gundavelli, et al.       Expires August 4, 2013                 [Page 8]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

      The Priority field is an 8-bit unsigned integer.  When this
      extension is in a Registration Request this field specifies the
      priority field assigned to the filter rule defined by this
      extension.  The receiver can utilize this priority to determine
      the order of application of the filter rules defined by the
      sender.  The lower the value the higher priority (i.e., it is
      checked earlier against each packet).  A value of 255 indicates
      that the filter rule indicated should be deregistered.

      The Status field is an 8-bit unsigned integer.  When this
      extension is in a registration reply this field indicates the
      status of the filter rule.  The possible status codes are listed
      in Table 3.

      For the Status field values 0-127 indicate success and values
      between 128 and 255 indicate failure.  The following values are
      defined for the Status field:

   +-------------------+--------+--------------------------------------+
   | Status            | Value  | Comments                             |
   +-------------------+--------+--------------------------------------+
   | Accepted          | 0      | Flow binding successful              |
   | Reject            | 128    | Flow binding rejected, reason        |
   |                   |        | unspecified.                         |
   | Poorly Formed     | 129    | Flow Identification extension poorly |
   |                   |        | formed                               |
   | Admin Prohibited  | 130    | Administratively prohibited          |
   | Unknown FID       | 131    | The FID is not recognized            |
   | Unknown BID       | 132    | A BID included in the extension is   |
   |                   |        | not registered.                      |
   +-------------------+--------+--------------------------------------+

         Table 3: Values for the Flow Identification Status field

   Action

      When this extension is in a Registration Request this field
      specifies the action that needs to be taken by the receiver.  The
      field SHOULD be set to zero by the home agent in the registration
      reply and SHOULD be ignored by the mobile node.  See defined
      values in Table 4.

      The following values are reserved for the Action field.

Gundavelli, et al.       Expires August 4, 2013                 [Page 9]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   +---------+-------+-------------------------------------------------+
   | Action  | Value | Comments                                        |
   +---------+-------+-------------------------------------------------+
   | Drop    | 0     | Drop matching packets.  A filter rule           |
   |         |       | indicating a drop action MUST include a single  |
   |         |       | BID byte, the value of which MAY be set to 255  |
   |         |       | by the sender and the value of which SHOULD be  |
   |         |       | ignored by the receiver.                        |
   | Forward | 1     | Forward matching packets to the 1st BID in the  |
   |         |       | list of BIDs the filter rule is pointing to.    |
   |         |       | If the 1st BID becomes invalid (i.e., the       |
   |         |       | corresponding CoA is deregistered) use the next |
   |         |       | BID in the list.                                |
   | X-Cast  | 2     | Forward one copy of each matching packet to the |
   |         |       | list of BIDs this filter rule is pointing to.   |
   +---------+-------+-------------------------------------------------+

    Table 4: Values for the IPv4 and IPv6 Flow Descriptor Action field

   F-Type

      The Filter Type (F-Type) field identifies the type of Filter
      Descriptor included in the extension.  Filter Descriptors in
      addition to the ones defined in this document can be defined in
      other documents but all Filter Descriptors MUST indicate their own
      length.

      The following values are defined.

   +-----------+-------+-----------------------------------------------+
   | F-Type    | Value | Comments                                      |
   +-----------+-------+-----------------------------------------------+
   | Do not    | 0     | The already registered filter for the FID of  |
   | Change    |       | the extension must be used                    |
   | IPv4      | 1     | An IPv4 Filter Descriptor follows, see        |
   | Filter    |       | Figure 4                                      |
   | IPv6      | 2     | An IPv6 Filter Descriptor follows, see        |
   | Filter    |       | Figure 5                                      |
   +-----------+-------+-----------------------------------------------+

                                  Table 5

   Filter Descriptor

      The Filter Descriptor field defines a filter.  This field is
      further defined in Figure 4 and in Figure 5 depending on the value
      of the F-Type field of this extension.

Gundavelli, et al.       Expires August 4, 2013                [Page 10]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   BIDs

      Indicates the BIDs to which the Filter Rule Descriptor points to,
      in order of appearance.  Note that if a filter rule does not point
      to any valid BIDs, the filter rule itself becomes invalid.

   +---------+-------+-------------------------------------------------+
   | BID     | Value | Comments                                        |
   +---------+-------+-------------------------------------------------+
   | Do not  | 0     | The already registered filter for the FID of    |
   | Change  |       | the extension must be used                      |
   | BID     | 1-254 | These values point to one of BIDs registered    |
   |         |       | with Alternate-CoA extension, in order of       |
   |         |       | appearance.  Multiple BID bytes can be included |
   |         |       | to point to more than one BIDs                  |
   | Default | 255   | the default set of BIDs, registered with        |
   | List    |       | Alternate-CoA extensions MUST be used           |
   +---------+-------+-------------------------------------------------+

                                  Table 6

   If the Type field of the Flow Identification extension indicates an
   IPv4 Flow then the Filter Rule Descriptor is as specified below.
   This fields in the message are identical to the format specified in
   Section 3.1 of [RFC6088].  Please refer to that document for
   parameter description.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|B|C|D|E|F|G|H|I|K|L|  Rsvd |Z|   (A)TOS      | (B)Protocol   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    (C)Source Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 (D)Destination Address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |(E)S. PrefLeng |(F)D. PrefLeng |   (G)Source port - Low        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   (H)Source port - High       |      (I)Dst port - Low        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   (K)Dst port - High          |          (L)SPI               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          (L)SPI               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: IPv4 Filter Rule Descriptor

   Flags (A-L)

Gundavelli, et al.       Expires August 4, 2013                [Page 11]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

      Each flag indicates whether the corresponding field is present in
      the message

   (A)TOS - Type of Service

      The TOS field in the data packet as seen by the home agent.

   (B)Protocol

      An 8-bit unsigned integer representing the value of the transport
      protocol number associated with the port numbers in data packets.

   (C)Source Address

      This field identifies the source address of data packets as seen
      by the home agent that is, the 32-bit IPv4 address of the
      correspondent node.

   (D)Destination Address

      This field identifies the destination address of data packets as
      seen by the home agent.  When included this field must be set to
      one of the registered home addresses of the mobile node.  It is a
      32-bit IPv4 address.

   (E)Source Prefix Length

      This field includes the prefix length for the source address.
      This field can only be included if the Source Address field is
      included.

   (F)Destination Prefix Length

      This field includes the prefix length for the destination address.
      If The Destination Address field is included then it refers to
      that field; otherwise it refers to the home address field of the
      Registration Request header.

   (G)Source Port - Low

      This field identifies the lowest source port number within a range
      of port numbers that will be used in data packets, as seen by the
      home agent.

   (H)Source Port - High

Gundavelli, et al.       Expires August 4, 2013                [Page 12]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

      This field identifies the highest source port number within a
      range of port numbers that will be used in data packets, as seen
      by the home agent.  If a single port is indicated then this field
      SHOULD NOT be included.  If it is included it SHOULD be set to the
      value of the Source Port ?  Low field.

   (I)Destination Port - Low

      This field identifies the lowest destination port number within a
      range of port numbers that will be used in data packets as seen by
      the home agent.

   (K)Destination Port - High

      This field identifies the highest destination port number within a
      range of port numbers that will be used in data packets as seen by
      the home agent.  If a single port is indicated then this field
      SHOULD NOT be included.  If it is included it SHOULD be set to the
      value of the Dst Port ?  Low field.

   (L)SPI - Security Parameter Index

      The SPI field in the data packet as seen by the home agent.

   If the Type field of the Flow Identification extension indicates an
   IPv6 Flow then the Filter Rule Descriptor is as as specified below.
   The fields in the message are identical to the format specified in
   Section 3.2 of [RFC6088].  The descriptor format is presented below
   for convenience.

Gundavelli, et al.       Expires August 4, 2013                [Page 13]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|B|C|D|E|F|G|H|I|K|L|M| Rsv |Z|   (A)CS       | (B)Protocol   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                    (C)Source Address                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                 (D)Destination Address                        +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |(E)S. PrefLeng |(F)D. PrefLeng |   (G)Source port - Low        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   (H)Source port - High       |      (I)Dst port - Low        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   (K)Dst port - High          |          (L)SPI               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          (L)SPI               |     (M)Flow Label             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | (M)Flow Label |
     +-+-+-+-+-+-+-+-+

                   Figure 5: IPv6 Filter Rule Descriptor

   Flags (A-M)

      Each flag indicates whether the corresponding field is present in
      the message

   CS - Class of Service

      The CS field in the data packet as seen by the home agent.

   (B)Protocol

      An 8-bit unsigned integer representing value of the transport
      protocol number associated with the port numbers in data packets.

Gundavelli, et al.       Expires August 4, 2013                [Page 14]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   (C)Source Address

      This field identifies the source address of data packets as seen
      by the home agent.  That is, the address of the correspondent node
      and it is a 128-bit IPv6 address.

   (D)Destination Address

      This field identifies the destination address of the data packet
      as seen by the home agent.  When included this field must be set
      to one of the registered home addresses of the mobile node and it
      is a 128-bit IPv6 address.

   (E)Source Prefix Length

      This field includes the prefix for the source address.  This field
      can only be included if the Source Address field is included .

   (F)Destination Prefix Length

      This field includes the prefix for the destination address.  If
      The Destination Address field is included then it refers to that
      field otherwise it refers to the home address field of the
      registration request header.

   (G)Source Port - Low

      This field identifies the lowest source port number within a range
      of port numbers that will be used in data packets, as seen by the
      home agent.

   (H)Source Port - High

      This field identifies the highest source port number within a
      range of port numbers that will be used in data packets, as seen
      by the home agent.  If a single port is indicated then this field
      SHOULD NOT be included.  If it is included it SHOULD be set to the
      value of the Source Port ?  Low field.

   (I)Destination Port - Low

      This field identifies the lowest destination port number within a
      range of port numbers that will be used in data packets as seen by
      the home agent.

   (K)Destination Port - High

Gundavelli, et al.       Expires August 4, 2013                [Page 15]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

      This field identifies the highest destination port number within a
      range of port numbers that will be used in data packets as seen by
      the home agent.  If a single port is indicated then this field
      SHOULD NOT be included.  If it is included it SHOULD be set to the
      value of the Dst Port ?  Low field.

   (L)SPI - Security Parameter Index

      The SPI field in the data packet as seen by the home agent.

   (M)Flow Label

      The Flow Label field in the data packet as seen by the home agent.

5.  Protocol Operation

   This specification allows a mobile node to register multiple CoAs
   using the Alternate-CoA extension and associate different flows with
   different CoAs by using the Flow Identification extension.

   When multiple CoAs are registered without any specific flow
   associated with them, the registered CoAs are treated as alternative
   paths to the mobile's current location.  The CoAs are ranked by the
   Priority field in the Alternate-CoA extension and all traffic to the
   mobile's registered HoA(s) SHOULD be sent to the CoA with the lowest
   priority.  If a CoA is deregistered, the CoA with the next lowest
   priority SHOULD become the default path for the mobile's traffic.

   Note that, the HA MAY be configured with a local policy that takes
   advantage of multiple CoAs in a certain way.  For example, x-casting
   across the registered CoAs MAY be used by the HA without any further
   signaling from the mobile; this is a configuration issue and outside
   the scope of this document.

   When the Flow Identification extensions are also used, however, the
   mobile can indicate which flow is to be associated with which CoA.  A
   single flow MAY be associated with more than one CoAs, while many
   flows MAY be associated with the same CoA.  The effect of associating
   flows with CoA ofcourse depends on the action defined for that flow.

   The Flow Identification extension is variable length and several
   fields might be omitted as required.  When the extension is sent to
   deregister a filter rule (Priority set to 255) only the first line of
   Figure 3 needs to be sent (i.e., the first 4 bytes).  If the priority
   and/or action values need to be changed for an existing FID then the
   F-Type MUST be set to 0 and one BID byte set to 0 MUST be included,
   indicating no changes to the filter and the BIDs associated with it.
   The Filter Descriptor of a given FID can be changed by sending the

Gundavelli, et al.       Expires August 4, 2013                [Page 16]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   extension including the new Filter Desctriptor and a single BID byte
   set to 0.  The BIDs associated with a given FID can be changed by
   sending the extension with F-Type set to 0 (and not including a
   Filter Descriptor).  The F-Type (when not set to 0) indicates the
   type of Filter Descriptor used.  In this specification we define
   Filter Descriptors for IPv4 and IPv6; other Filter Descriptors MAY be
   defined in separate documents.

5.1.  Mobile Node Considerations

   A mobile MAY send an Alternate-CoA extension with the CoA field
   matching the CoA field in the Mobile IP message header to check
   whether the HA supports the extensions defined in this specification.
   Since the extensions defined here are skippable, if the registration
   reply does not include the Alternate-CoA extensions sent by the
   mobile, the mobile knows that the HA does not support this
   specification.  If, however, the HA returns the Alternate-CoA
   extensions in the reply, the HA does support this specification.

5.1.1.  Using the Alternate-CoA extension

   A mobile MAY include one or more Alternate-CoA extensions in each
   Registration Request message.  If the mobile has already registered a
   CoA without using the Alternate-CoA extension and the mobile wants to
   registered an additional CoA, the original and the new CoAs MUST be
   sent in the new registration as Alternate-CoA extensions so that they
   can be ranked with priorities and be associated with BIDs.  In other
   words the new message will include an Alternate-CoA with the CoA
   field set to the CoA registered in the earlier message.

   Unless multiple Alternate-CoA extensions are included in the same
   Registration Request message, the different CoAs will have different
   lifetimes associated with them.  Each CoA MAY be refreshed
   individually by sending a Registration Request with that CoA in an
   Alternate-CoA extension.  Alternatively, multiple CoAs can be
   refreshed at the same time by sending a Registration Request with
   multiple Alternate-CoA extensions.

   If an earlier registered CoA is not included in a Registration
   Request it does not mean that the CoA is deregistered.  Instead CoAs
   are deregistered when their lifetimes expire or when they are
   explicitly deregistered by the mobile node.

   A mobile MAY deregister any CoA by setting its priority to 255.  Note
   that the mobile can change the priority of a given CoA by sending an
   Alternate-CoA extension with the BID field set to the BID of the CoA
   in question, the priority field to the new value (or 255 for
   deregistration), and without including the CoA field.

Gundavelli, et al.       Expires August 4, 2013                [Page 17]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   A mobile MAY replace the CoA associated with a given BID by sending
   an Alternate-CoA with the BID field set to the BID of an existing CoA
   and the priority and CoA fields to their new values.

5.1.2.  Using the Flow Identification Extension

   The Flow Identification extensions allow a mobile to control a mobile
   specific classifier table present in the Home Agent memory.  Each
   Flow Identification extension defines one filter rule line in that
   classifier, the output of which is one or more BIDs pointing to one
   or more of the registered CoAs.

   Each filter rule in the classifier table can be referenced by the FID
   of the Flow Identification extension that created it.  If the mobile
   wants to change the priority of a filter rule it can send a Flow
   Identification extension including the FID of the filter rule and
   setting the Priority field to the new value (or 255 for
   deregistration), and without including the Filter Rule Definition or
   any BIDs.

   Filter rules do not need to be refreshed explicitly.  A filter rule
   is valid as long as it points to a valid BID, i.e., a registered CoA.
   If a filter rule does not point to any valid BIDs it will be removed.

   Any filter rule in the classifier table can be replaced by a new
   filter rule by sending a Flow Identification extension with the FID
   field set to the FID of the filter rule to be replaced and the rest
   of the extension defining the new filter rule, priority and the BIDs
   it points to.

   Each Flow Identification extension is ranked according to its
   priority field.  The lower the value of the priority field the higher
   its priority (i.e., it is checked earlier against each packet).  As
   in most classifiers, filter rules with the same priority SHOULD be
   non-overlapping, otherwise the result is undefined.  Overlapping
   filter rules SHOULD have different priorities.

   Mobiles SHOULD define a default filter rule for traffic that does not
   match any other rule.  The default filter rule MAY be defined with a
   Filter Identification extension with a high priority value (so it is
   checked last) and with the Filter Descriptor with all the flags set
   to 0 and the action field set to an appropriate value (e.g.,
   forward).  Note that such a Filter Descriptor will match all packets.

   A mobile node can use the Flow Identification extension to associate
   a given flow with one or more of the registered CoAs.  The mobile
   MUST register its CoAs with the Alternate-CoA extension in order to
   associate flows with them, using the BID as a handle.  One or more

Gundavelli, et al.       Expires August 4, 2013                [Page 18]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   Flow Identification extensions and one or more Alternate-CoA
   extensions MAY be present in the same message.

   If a Flow Identification extension includes a BID field set to the
   value 155 then the filter rule points to all the registered CoAs.
   The order of the CoAs for such a filter rule is dictated by the
   priority level of each BID, taken by the Priority field of the
   Alternate-CoA used to register them.  If one or more BIDs are present
   in the Flow Identification extension then the filter rule points to
   the specific BIDs included in the extension.  Note that the list of
   BIDs in the Flow Identification extension is ordered and its
   significance depends on the action indicated by the action field in
   the same extension.

5.2.  Home Agent Considerations

5.2.1.  Handling Alternate-CoA extensions

   A Home Agent that supports this specification SHOULD ignore the "S"
   flag (Simultaneous Bindings) in the Registration Request message
   header when the same message includes Alternate-CoA extensions.  In
   other words, the mechanisms defined in this specification override
   the mechanism defined by the "S" flag in [RFC5944].

   If an Alternate-CoA extension is received by an HA in a Registration
   Request message, the HA SHOULD include a corresponding Alternate-CoA
   extension in the registration reply message.  The BID of Alternate-
   CoA extension MUST be copied from the BID of the Alternate-CoA
   extension in the corresponding Registration Request and the Status
   field SHOULD be set to an appropriate value (e.g., indicating accept,
   reject etc).

   When a valid Registration Request message includes one or more
   accepted Alternate-CoA extensions the HA MUST include the accepted
   CoAs in the mobility bindings table which binds the registered home
   address(es) with the registered CoAs together with their BIDs,
   priorities and lifetimes.  The BID and priority of a CoA is indicated
   in the Alternate-CoA extension, while the lifetime is inherited from
   the lifetime of the registration reply message that accepted them as
   registered CoAs.  Thus, different Alternate-CoAs will have different
   lifetimes if they are registered with different registration request
   messages, but they will have the same lifetime if they are included
   in the same Registration Request.

   The CoAs are ranked according to their priority; the lowest the value
   of the priority field the higher their ranking.  If an Alternate-CoA
   is rejected then the HA MUST NOT include it in the mobility bindings
   table.  If the lifetime of an Alternate-CoA expires, the

Gundavelli, et al.       Expires August 4, 2013                [Page 19]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   corresponding CoA MUST be removed from the mobility bindings table.

   If an Alternate-CoA extension is received with a BID that matches an
   existing BID then:

      The HA MUST check the priority field of the extension in quesiton.
      If the priority field is set to 255 (indicating deregistration)
      the CoA MUST be removed from the mobility bindings table and from
      any filter rules that point to it.

      If the priority is set to any other value, the HA MUST check the
      CoA field of the same extension.  If the CoA field is not
      included, the priority of the CoA, identified by the BID included
      in the extension, MUST be updated with the indicated value.

      If the CoA field exists and matches the CoA that the BID field
      points to in the HA mobility bindings table, the priority of that
      CoA is again updated.

      If the CoA field exists and is different from the CoA the BID
      field points to in the HA mobility bindins table, the HA SHOULD
      update its table with the new CoA and priority for that BID.

   If an Alternate-CoA extension is received with a BID that does not
   match an existing BID then:

      The HA MUST check the CoA field of the extension.  If the CoA
      field is not included, the HA SHOULD include an Alternate-CoA
      extension in the registration reply with a BID copied from the
      corresponding extension in the request message and the Status
      field set to "Unknown BID."

      If the CoA field exists, the HA MUST store the BID, CoA and
      priority values in the mobility bindings table for the mobile.
      The CoA MUST be ranked with the other registered CoAs according to
      the value of the priority field.

      If the CoA field exists but it matches a CoA that is already
      registered with a different BID the HA MAY replace the old BID
      with the new BID and indicate a "BID changed" in the Status field
      of the corresponding Alternate-CoA extension included in the
      registration reply message.

5.2.2.  Handling Flow Identification Extensions

   If a Flow Identification extension is received by an HA in a
   Registration Request message, the HA SHOULD include a corresponding
   Flow Identification extension in the registration reply message.  The

Gundavelli, et al.       Expires August 4, 2013                [Page 20]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

   FID of the Flow Identification extension in the reply message MUST be
   copied from the FID of the Flow Identification extension in the
   corresponding Registration Request and the Status field SHOULD be set
   to an appropriate value (e.g., indicating accept, reject etc).

   When a valid Registration Request message includes one or more
   accepted Filter Identification extensions the HA MUST include the
   accepted filter rules in the mobile specific classifier table which
   associates the order list of filter rules with the BIDs they point
   to.  The priority of a filter rule, the description of the filter
   rule, the action and the BID(s) the filter rule is associated with
   are indicated in the Flow Identification extension.

   The filter rules are ranked according to their priority.  Filter
   rules MUST be ranked from lowest to higher priority.  If a filter
   rule is rejected then it MUST NOT included in the mobile specific
   classifier.

   Each filter rules in the mobile specific classifier is valid as long
   as points to a valid BID, i.e., a registered CoA.  If a filter rule
   does not point to any valid BIDs the HA MUST remove it from the
   mobile specific classifier.

   If the HA receives a Flow Identification extension, it SHOULD first
   check the FID field of that extension.

      If the value of the FID field does not match any of the FIDs in
      the mobile specific classifier, the HA SHOULD include the filter
      rule described in the extension in the mobile specific classifier
      table.  The new filter rule MUST be ranked according to the
      priority field indicated in the Flow Identification extension.

         If a one or more BIDs are included then the filter rule MUST
         point to the list of BIDs in the order they appear.

         If any of the including BIDs do not match one of the registered
         BIDs in the mobile bindings table for this mobile the HA MUST
         disregard the Flow Identification extension and MUST return a
         reply message with a Flow Identification extension that
         includes the FID of the corresponding extension in the request
         message and the Status field set to an appropriate value e.g.,
         "Unknown BID."

         If a BID of value 255 is included, the filter rule MUST point
         to the default list of BIDs.  This is the list of BIDs in the
         mobility bindings table for this mobile.

Gundavelli, et al.       Expires August 4, 2013                [Page 21]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

         If a BID of value 0 is included the HA MUST disregard the Flow
         Identification extension and MUST return a reply message with a
         Flow Identification extension that includes the FID of the
         corresponding extension in the request message and the Status
         field set to an appropriate value e.g., "Unknown BID."

      If the value of the FID field matches any of the FIDs in the
      mobile specific classifier the HA SHOULD then check the priority
      field of the Flow Identification extension.  If the priority field
      is set to 255 then the filter rule associated with the FID in the
      Flow Identification extensions MUST be removed from the mobile
      specific classifier table.

         If the priority field, however, is set to a value other than
         255 the HA SHOULD check the Filter Description field of the
         Flow Identification extension.

         If the Filter Description is not included (F-Type field set to
         0) and the BID field is set to 0, the HA MUST adjust the
         ranking of the filter rule corresponding to the FID according
         to the priority field in the Flow Identification extension.

         If any BIDs are also included in the Flow Identification
         extensions then the list of BIDs associated with that filter
         rule MUST also be replaced by the list provided in the Flow
         Identification extension.  If a BID field set to 255 is
         included then the filter rules MUST be re-pointed to the
         default list of BIDs registered with Alternate-CoA extensions.

         Note a BID field set to 0 is included the BIDs list for this
         filter rule in the mobility specific classifier table MUST NOT
         be changed.

      If the priority field, however, is set to a value other than 255
      and the Filter Description field is included then the HA MUST
      replace the corresponding filter rule in the mobile specific
      classifier table with the filter rule in the Flow Identification
      extension.

         If any BIDs are also included in the Flow Identification
         extensions then the list of BIDs associated with that filter
         rule MUST also be replaced by the list provided in the Flow
         Identification extension.  If a BID field set to 255 is
         included then the filter rules MUST be re-pointed to the

Gundavelli, et al.       Expires August 4, 2013                [Page 22]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

         default list of BIDs registered with Alternate-CoA extensions.

         Note that if a BID field set to 0 is included the BIDs field,
         the list of BIDs this filter rule points to MUST NOT be changed
         from its previous configuration.

6.  Routing Considerations

   This document allows the mobility entities to optionally exchange
   flow policies.  In the absence of negotiated traffic flow policies,
   this document recommends the use of per-flow load balancing.

   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.

7.  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.

   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.

Gundavelli, et al.       Expires August 4, 2013                [Page 23]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

8.  IANA Considerations

   This document proposes two new extensions that require a type number
   to be assigned by IANA.

   Section 4.1 defines a new Mobile IP extension, the Alternate-CoA
   Extension.  Its a skippable extension to the Mobile IPv4 header in
   accordance to the short extension format of [RFC5944].  The type
   number for this extension needs to be assigned by IANA.

   Section 4.2 defines a new Mobile IP extension, the Flow
   Identification Extension.  Its a skippable extension to the Mobile
   IPv4 header in accordance to the short extension format of [RFC5944].
   The type number for this extension needs to be assigned by IANA.

9.  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
   roaming interfaces.  This specification also allows the mobile node
   to bind traffic flows to the registered care-of addresses.  This new
   capability has no impact on the protocol security.

   The Mobile IP message extensions, defined in this document are to be
   carried in Mobile IP Registration messages and these messages are
   authenticated and integrity protected as described in [RFC5944].

   Therefore, this specification does not weaken the security of Mobile
   IP Protocol, or, introduce any new vulnerabilities.

10.  Contributors

   This document reflects discussions and contributions from the
   following people:

   Srinivasa Kanduru

      skanduru@gmail.com

   Vince Park

      vpark@qualcomm.com

Gundavelli, et al.       Expires August 4, 2013                [Page 24]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

11.  Acknowledgements

   We like to thank Qin Wu, Shahriar Rahman, Mohana Jeyatharan, Yungui
   Wang, Hui Deng Behcet Sarikaya, Jouni Korhonen, Michaela Vanderveen
   and Antti Makela for their review and comments on this draft.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
              revised", RFC 3024, January 2001.

   [RFC3519]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
              Network Address Translation (NAT) Devices", RFC 3519,
              April 2003.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",
              RFC 5944, November 2010.

12.2.  Informative References

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC5177]  Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
              "Network Mobility (NEMO) Extensions for Mobile IPv4",
              RFC 5177, April 2008.

   [RFC5648]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
              and K. Nagami, "Multiple Care-of Addresses Registration",
              RFC 5648, October 2009.

   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
              "Traffic Selectors for Flow Bindings", RFC 6088,
              January 2011.

   [RFC6089]  Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,

Gundavelli, et al.       Expires August 4, 2013                [Page 25]
Internet-Draft    Flow Binding Support for Mobile IPv4      January 2013

              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
              Network Mobility (NEMO) Basic Support", RFC 6089,
              January 2011.

Authors' Addresses

   Sri Gundavelli (editor)
   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

   George Tsirtsis
   Qualcomm

   EMail: tsirtsis@qualcomm.com

   Hesham Soliman
   Elevate Technologies

   EMail: hesham@elevatemobile.com

   Alexandru Petrescu
   CEA LIST
   Communicating Systems Laboratory, Point Courrier 94
   Gif-sur-Yvette  F-91191
   France

   Phone: +33 169089223
   EMail: alexandru.petrescu@cea.fr

Gundavelli, et al.       Expires August 4, 2013                [Page 26]