doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc7629.txt b/doc/rfc/rfc7629.txt
new file mode 100644
index 0000000..d34072b
--- /dev/null
+++ b/doc/rfc/rfc7629.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                S. Gundavelli, Ed.
+Request for Comments: 7629                                      K. Leung
+Category: Experimental                                             Cisco
+ISSN: 2070-1721                                              G. Tsirtsis
+                                                                Qualcomm
+                                                             A. Petrescu
+                                                               CEA, LIST
+                                                             August 2015
+
+
+                   Flow-Binding Support for Mobile IP
+
+Abstract
+
+   This specification defines extensions to the Mobile IP 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 IP tunnels with its home agent.  This essentially
+   allows the mobile node to utilize all the available network
+   interfaces and build a higher aggregated logical pipe with its home
+   agent for its home address traffic.  Furthermore, these extensions
+   also allow the mobile node and the home agent to negotiate IP traffic
+   flow policies for binding individual flows with the registered care-
+   of addresses.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7629.
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                      [Page 1]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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
+   (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 and Terminology . . . . . . . . . . . . . . . . .   3
+     2.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   3
+     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     3.1.  Example Call Flow . . . . . . . . . . . . . . . . . . . .   6
+   4.  Message Extensions  . . . . . . . . . . . . . . . . . . . . .   7
+     4.1.  Multipath Extension . . . . . . . . . . . . . . . . . . .   7
+     4.2.  Flow-Binding Extension  . . . . . . . . . . . . . . . . .   9
+     4.3.  New Error Codes for Registration Reply  . . . . . . . . .  12
+   5.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .  12
+     5.1.  Mobile Node Considerations  . . . . . . . . . . . . . . .  12
+     5.2.  Home Agent Considerations . . . . . . . . . . . . . . . .  14
+   6.  Routing Considerations  . . . . . . . . . . . . . . . . . . .  14
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19
+
+
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                      [Page 2]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+1.  Introduction
+
+   With the ubiquitous availability of wireless networks based on
+   different access technology types, mobile devices are now equipped
+   with multiple wireless interfaces and have the ability to connect to
+   the network using any of those interfaces.  For example, most mobile
+   devices are equipped with Wi-Fi and LTE (Long Term Evolution)
+   interfaces.  In many deployments, it is desirable for a mobile node
+   to leverage all the available network interfaces and have IP mobility
+   support for its IP flows.
+
+   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 an IP
+   tunnel that will be established between the home agent and the mobile
+   node or between the home agent and the foreign agent where the mobile
+   node is attached; see [RFC5944].  In both of these modes, there will
+   only be one interface on the mobile node that is receiving the IP
+   traffic from the home agent.  This approach of using a single access
+   interface for routing all mobile node's traffic is not efficient and
+   so there is a need to extend Mobile IP to concurrently use multiple
+   access interfaces for routing the mobile node's IP traffic.  The goal
+   is for efficient use of all the available access 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
+   leverage all access links for the mobile node's IP traffic.
+   Furthermore, this specification also defines extensions to allow the
+   mobile node and the home agent to optionally negotiate IP flow
+   policies for binding individual IP flows with the registered care-of
+   addresses.
+
+2.  Conventions and 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.
+
+
+
+Gundavelli, et al.            Experimental                      [Page 3]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   Binding Identifier (BID)
+
+      It is an identifier assigned to a mobile node's binding.  A
+      binding defines an association between a mobile node's home
+      address and its registered care-of address.  When a mobile node
+      registers multiple bindings with its home agent, each using a
+      different care-of address, then each of those bindings are given a
+      unique identifier.  Each of the binding identifiers will have a
+      unique value that will be different from the identifiers assigned
+      to the mobile node's other bindings.
+
+   Flow Identifier (FID)
+
+      It is an identifier for a given IP flow, uniquely identified by
+      source address, destination address, protocol type, source port,
+      destination port, Security Parameter Index, and other parameters
+      as identified in [RFC6088].  In the context of this document, the
+      IP flows associated with a mobile node are the IP flows using its
+      home address.  For a mobile router, the IP flows also include the
+      IP flows using the mobile network prefix [RFC6626].
+
+3.  Overview
+
+   The illustration below in Figure 1 is an example scenario where a
+   mobile node is connected to WLAN, LTE, and CDMA access networks.  The
+   mobile node is configured with a home address, HoA_1, and has
+   obtained the following care-of addresses [RFC5944]: CoA_1, from the
+   WLAN network; CoA_2, from the LTE network; and CoA_3, from the CDMA
+   network.
+
+   The mobile node using the extensions specified in this document
+   registers all three care-of addresses with its home agent.  The
+   mobile node also establishes an IP tunnel with the home agent using
+   each of its IP addresses, which results in three IP tunnels
+   (Tunnel_1, Tunnel_2, and Tunnel_3) between the mobile node and the
+   home agent.  Each of the tunnels represents an overlay routing path
+   between the mobile node and the home agent and can be used for
+   forwarding the mobile node's IP traffic.
+
+   Furthermore, using the extensions specified in this document, the
+   mobile node and the home agent can negotiate an IP flow policy.  The
+   negotiated flow policy allows the mobile node and the home agent to
+   determine the access network path for each of the mobile node's IP
+   flows.
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                      [Page 4]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   Flow_1 (SIP)
+    |
+    |Flow_2 (SSH)
+    | |
+    | |Flow_3 (HTTP)       _----_
+    | | |         CoA_1  _(      )_ Tunnel_1
+    | | |    .---=======(   Wi-Fi  )========\ Flow_1
+    | | |    |           (_      _)          \
+    | | |    |             '----'             \
+    | | | +=====+          _----_              \  +=====+    _----_
+    | | '-|     | CoA_2  _(      )_ Tunnel_2    \ |     |  _(      )_ --
+    | '---| MN  |---====(   LTE    )=========-----| HA  |-( Internet )--
+    '-----|     |        (_      _)      Flow_3 / |     |  (_      _) --
+          +=====+          '----'              /  +=====+    '----'
+           | |             _----_             /
+    HoA_1--' |    CoA_3  _(      )_ Tunnel_3 /
+             .------====(   CDMA   )========/ Flow_2
+                         (_      _)
+                           '----'
+
+             Figure 1: Mobile Node (MN) with Multiple Tunnels
+                          to the Home Agent (HA)
+
+   The table below is an example of how the individual flows are bound
+   to different care-of addresses registered with the home agent.
+
+   +=========+===================+=====================================+
+   | Flow ID |   Access Network  |           Description               |
+   |  (FID)  |    Preferences    |                                     |
+   +=========+===================+=====================================+
+   | Flow_1  | Tunnel_1 / CoA_1  | All SIP flows over Wi-Fi (Preferred)|
+   |         | Tunnel_2 / CoA_2  | If Wi-Fi is not available, use LTE  |
+   |         |       <DROP>      | If Wi-Fi and LTE access networks are|
+   |         |                   | not available, drop the flow        |
+   +---------+-------------------+-------------------------------------+
+   | Flow_3  | Tunnel_2 / CoA_2  | All HTTP flows over LTE (Preferred) |
+   |         |       <DROP>      | If LTE not available, drop the flow |
+   +---------+-------------------+-------------------------------------+
+   | Flow_2  | Tunnel_3 / CoA_3  | All SSH flows over CDMA (Preferred) |
+   |         | Tunnel_2 / CoA_2  | If CDMA not available, use LTE      |
+   |         | Tunnel_1 / CoA_1  | If LTE not available, use Wi-Fi     |
+   +---------+-------------------+-------------------------------------+
+
+                 Figure 2: Example of an IP Traffic Policy
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                      [Page 5]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+3.1.  Example Call Flow
+
+   Figure 3 is the call flow for the example scenario where a mobile
+   node is connected to WLAN and LTE access networks.
+
+      +-------+          +-------+          +-------+          +-------+
+      |   MN  |          | WLAN  |          |  LTE  |          |  HA   |
+      |       |          |Network|          |Network|          |       |
+      +-------+          +-------+          +-------+          +-------+
+         |                   |                  |                  |
+
+   * MIP RRQ is sent using the IP address obtained from the WLAN Network
+
+         |<--- (1) --------->|                  |                  |
+         |                   |   RRQ (Multipath, Flow-Binding)     |
+         |---- (2) ----------------------------------------------->|
+         |                   |   RRP            |                  |
+         |<--- (3) ------------------------------------------------|
+         |              MIP Tunnel through WLAN Network            |
+         |=====(4)===========*=====================================|
+
+
+   * MIP RRQ is sent using the IP address obtained from the LTE Network
+
+         |<--- (5) ---------------------------->|                  |
+         |                   |  RRQ (Multipath, Flow-Binding)      |
+         |---- (6) ----------------------------------------------->|
+         |                   |  RRP             |                  |
+         |<--- (7) ------------------------------------------------|
+         |              MIP Tunnel through LTE Access Network      |
+         |=====(8)==============================*==================|
+         |                                                         |
+         *                                                         *
+   (Policy-based Routing Rule)               (Policy-based Routing Rule)
+
+            Figure 3: Multipath Negotiation - Example Call Flow
+
+   o  (1): The mobile node attaches to the WLAN network and obtains the
+      IP address configuration for its WLAN interface.
+
+   o  (2)-(3): The mobile node sends a Registration Request (RRQ)
+      [RFC5944] to the home agent through the WLAN network.  The message
+      includes the Multipath (Section 4.1) and the Flow-Binding
+      (Section 4.2) Extensions.  The home agent, upon accepting the
+      request, sends a Registration Reply (RRP) [RFC5944]  with a value
+      of (0) in the Code field of the Registration Reply.
+
+
+
+
+
+Gundavelli, et al.            Experimental                      [Page 6]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   o  (4): The mobile node and the home agent establish a bidirectional
+      IP tunnel over the WLAN network.
+
+   o  (5): The mobile node attaches to the LTE network and obtains the
+      IP address configuration from that network.
+
+   o  (6)-(7): The mobile node sends a Registration Request to the home
+      agent through the LTE network.  The message includes the Multipath
+      and the Flow-Binding Extensions.  The Flow-Binding Extension
+      indicates that all HTTP flows need to be routed over the WLAN
+      network and if the WLAN access network is not available, they need
+      be routed over other access networks.  The negotiated policy also
+      requires all voice-related traffic flows to be routed over the LTE
+      network.  The home agent, upon accepting the request, sends a
+      Registration Reply with a value of (0) in the Code field of the
+      Registration Reply.
+
+   o  (8): The mobile node and the home agent establish a bidirectional
+      IP tunnel over the LTE network.  The negotiated traffic flow
+      policy is applied.  Both the home agent and the mobile node route
+      all the voice flows over the tunnel established through the LTE
+      access network and the HTTP flows over the WLAN network.
+
+4.  Message Extensions
+
+   This specification defines the following new extensions to Mobile IP.
+
+4.1.  Multipath Extension
+
+   This extension is used for requesting multipath support.  It
+   indicates that the sender is requesting the home agent to register
+   the current care-of address listed in this Registration Request as
+   one of the many care-of addresses through which the mobile node can
+   be reached.  It is also for carrying the information specific to the
+   interface to which the care-of address that is being registered is
+   bound.
+
+   This extension is a non-skippable extension and MAY be added by the
+   mobile node to the Registration Request message.  There MUST NOT be
+   more than one instance of this extension present in the message.
+   This extension MUST NOT be added by the home agent to the
+   Registration Reply.
+
+   This extension should be protected using the Mobile-Home
+   Authentication Extension [RFC5944].  As specified in Sections 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.            Experimental                      [Page 7]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   The format of this extension is as shown below.  It adheres to the
+   long extension format described in [RFC5944].
+
+        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      |    Subtype    |           Length              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |    If-ATT     |   If-Label    |   Binding ID  |B|O|  Reserved |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 4: Multipath Extension
+
+   Type
+
+      Type: Multipath-Extension-Type (154)
+
+   Subtype
+
+      This field MUST be set to a value of 1 (Multipath Extension).
+
+   Length
+
+      The length of the extension in octets, excluding Type, Subtype,
+      and Length fields.  This field MUST be set to a value of 4.
+
+   Interface Access-Technology Type (If-ATT)
+
+      This 8-bit field identifies the Access Technology type of the
+      interface through which the mobile node is connected.  The
+      permitted values for this are from the Access Technology Type
+      registry defined in [RFC5213].
+
+   Interface Label (If-Label)
+
+      This 8-bit field represents the interface label represented as an
+      unsigned integer.  The mobile node identifies the label for each
+      of the interfaces through which it registers a CoA with the home
+      agent.  When using static traffic flow policies on the mobile node
+      and the home agent, the label can be used for indexing forwarding
+      policies.  For example, the operator may have a policy that binds
+      an IP flow "F1" to any interface with the label "Blue".  When a
+      registration through an interface matching the label "Blue" gets
+      activated, the home agent and the mobile node establish an IP
+      tunnel and the tunnel is marked with that label.  Both the home
+      agent and the mobile node generate traffic rules for forwarding IP
+      flow traffic "F1" through the mobile IP tunnel matching the label
+      "Blue".  The permitted values for If-Label are 1 through 255.
+
+
+
+Gundavelli, et al.            Experimental                      [Page 8]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   Binding Identifier (BID)
+
+      This 8-bit field is used for carrying the binding identifier.  It
+      uniquely identifies a specific binding of the mobile node
+      associated with this Registration Request.  Each binding
+      identifier is represented as an unsigned integer.  The permitted
+      values are 1 through 254.  The BID value of 0 and 255 are
+      reserved.
+
+   Bulk Re-registration Flag (B)
+
+      The (B) flag, if set to a value of (1), notifies the home agent to
+      update the binding lifetime of all the mobile node's bindings upon
+      accepting this request.  The (B) 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)
+
+      The (O) flag, if set to a value of (1), notifies the home agent
+      that upon accepting this request it should replace all of the
+      mobile node's existing bindings with the new binding that will be
+      created upon accepting this request.  The (O) 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.
+
+   Reserved (R)
+
+      This 6-bit 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-Binding Extension
+
+   This extension contains information that can be used by the mobile
+   node and the home agent for binding mobile node's IP flows to a
+   specific multipath registration.  There can be more than one instance
+   of this extension present in the message.
+
+   This extension is a non-skippable extension and MAY be added to the
+   Registration Request by the mobile node or by the home agent to the
+   Registration Reply.
+
+   This extension should be protected by Mobile-Home Authentication
+   Extension [RFC5944].  As specified in 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.            Experimental                      [Page 9]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   The format of this extension is as shown below.  It adheres to the
+   long extension format described in [RFC5944].
+
+        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      |    Subtype    |           Length              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |    Action     |  BID Count    |        ...   BID List   ...   ~
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |   TS Format   |             Traffic Selector                  ~
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 5: Flow-Binding Extension
+
+   Type
+
+      Type: Multipath-Extension-Type (154)
+
+   Subtype
+
+      This field MUST be set to a value of 2 (Flow-Binding Extension).
+
+   Length
+
+      The length of the extension in octets, excluding Type, Subtype,
+      and Length fields.
+
+   Action
+
+      The Action field identifies the traffic rule that needs to be
+      enforced.  Following are the possible values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 10]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   +---------+-------+-------------------------------------------------+
+   |  Action | Value | Description                                     |
+   +---------+-------+-------------------------------------------------+
+   |  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 first BID in the|
+   |         |       | list of BIDs the filter rule is pointing to.    |
+   |         |       | If the first BID becomes invalid (i.e., the     |
+   |         |       | corresponding CoA is de-registered), use the    |
+   |         |       | next BID in the list.                           |
+   +---------+-------+-------------------------------------------------+
+
+              Figure 6: Action Rules for the Traffic Selector
+
+   BID Count
+
+      Total number of binding identifiers that follow this field.  The
+      permitted values for this field are 1 through 8; each binding
+      identifier is represented as an unsigned integer in a single octet
+      field.  There is no delimiter between two binding identifier
+      values; they are spaced consecutively.
+
+   TS Format
+
+      An 8-bit unsigned integer indicating the Traffic Selector (TS)
+      Format.  The value (0) is reserved and MUST NOT be used.  When the
+      value of the TS Format field is set to (1), the format that
+      follows is the IPv4 Binary Traffic Selector specified in
+      Section 3.1 of [RFC6088], and when the value of the TS Format
+      field is set to (2), the format that follows is the IPv6 Binary
+      Traffic Selector specified in Section 3.2 of [RFC6088].  The IPv6
+      traffic selectors are only relevant when the mobile node registers
+      IPv6 prefixes per [RFC5454].
+
+   Traffic Selector
+
+      A variable-length opaque field for including the traffic
+      specification identified by the TS Format field.  It identifies
+      the traffic selectors for matching the IP traffic and binding them
+      to specific binding identifiers.
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 11]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+4.3.  New Error Codes for Registration Reply
+
+   This document defines the following error code values for use by the
+   home agent in the Code field of the Registration Reply.
+
+   MULTIPATH_NOT_ALLOWED (Multipath Support not allowed for this mobile
+   node): 152
+
+   INVALID_FB_IDENTIFIER (Invalid Flow-Binding Identifier): 153
+
+5.  Protocol Operation
+
+5.1.  Mobile Node Considerations
+
+   o  The mobile node should register a care-of address for each of the
+      connected interfaces that it wishes to register with the home
+      agent.  It can do so by sending a Registration Request to the home
+      agent through each of those interfaces.
+
+   o  Each of the Registration Requests that is sent includes the care-
+      of address of the respective interface.  The Registration Request
+      has to be routed through the specific interface for which the
+      registration is sought for.  Some of these interfaces may be
+      connected to networks with a configured foreign agent on the link,
+      and in such foreign-agent-based registrations, the care-of address
+      will be the IP address of the foreign agent.
+
+   o  A Multipath Extension (Section 4.1) reflecting the interface
+      parameters is present in each of the Registration Requests.  This
+      serves as an indication to the home agent that the Registration
+      Request is a Multipath registration and the home agent will have
+      to register this care-of address as one of the many care-of
+      addresses through which the mobile node's home address is
+      reachable.
+
+   o  If the mobile node is configured to exchange IP flow policy to the
+      home agent, then the Flow-Binding Extension (Section 4.2)
+      reflecting the flow policy can be included in the message.
+      Otherwise, the Flow-Binding Extension will not be included.
+
+   o  The mobile node, upon receiving a Registration Reply with the Code
+      value set to MULTIPATH_NOT_ALLOWED, MAY choose to register without
+      the Multipath Extension specified in this document.  This implies
+      the home agent has not enabled multipath support for this mobile
+      node and hence multipath support MUST be disabled on the mobile
+      node.
+
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 12]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   o  The mobile node, upon receiving a Registration Reply with the Code
+      value set to INVALID_FB_IDENTIFIER, MUST re-register that specific
+      binding with the home agent.
+
+   o  The mobile node at any time can extend the lifetime of a specific
+      care-of address registration by sending a Registration Request to
+      the home agent with a new lifetime value.  The message MUST be
+      sent as the initial multipath registration and must be routed
+      through that specific interface.  The message MUST include the
+      Multipath Extension (Section 4.1) with the value in the Binding ID
+      field set to the binding identifier assigned to that binding.
+      Alternatively, the home agent can send a single Registration
+      Request with the Bulk Re-registration Flag (B) set to a value of
+      (1).  This serves as a request to the home agent to update the
+      registration lifetime of all the mobile node's registrations.
+
+   o  The mobile node can, at any time, de-register a specific care-of
+      address by sending a Registration Request to the home agent with a
+      lifetime value of (0).  The message must include the Multipath
+      Extension (Section 4.1) with the value in the Binding ID field set
+      to the binding identifier assigned to that binding.
+      Alternatively, the home agent can send a single Registration
+      Request with the Bulk Re-registration Flag (B) set to a value of
+      (1) and a lifetime value of (0).  This serves as a request to the
+      home agent to consider this request as a request to de-register
+      all the mobile node's care-of addresses.
+
+   o  The mobile node can, at any time, update the parameters of a
+      specific registration by sending a Registration Request to the
+      home agent.  This includes a change of care-of address associated
+      with a previously registered interface.  The message must be sent
+      as the initial multipath registration and must be routed through
+      that specific interface.  The message must include the Multipath
+      Extension (Section 4.1) with the value in the Binding ID field set
+      to the binding identifier assigned to that binding, and the
+      Overwrite Flag (O) flag MUST be set to a value of (1).
+
+   o  The mobile node, upon receiving a Registration Reply with the Code
+      value set to 0 (registration accepted), will establish a Mobile IP
+      tunnel to the home agent using that care-of address.  When using a
+      foreign agent care-of address, the tunnel is between the home
+      agent and the foreign agent.  The tunnel encapsulation type and
+      any other parameters are based on the registration for that path.
+      If there is also an exchange of flow policy between the mobile
+      node and the home agent, with the use of Flow-Binding Extensions,
+      then the mobile node must set up the forwarding plane that matches
+      the flow policy.
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 13]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+5.2.  Home Agent Considerations
+
+   The home agent, upon receiving a Registration Request from a mobile
+   node with a Multipath Extension, should check if the mobile node is
+   authorized for multipath support.  If multipath support is not
+   enabled, the home agent MUST reject the request with a Registration
+   Reply and with the Code set to MULTIPATH_NOT_ALLOWED.
+
+   If the received Registration Request includes a Multipath Extension
+   and additionally has the Bulk Re-registration (B) flag set to a value
+   of (1), then the home agent MUST extend the lifetime of all the
+   bindings associated with that mobile node.
+
+   The home agent, upon receipt of a Registration Request with the Flow-
+   Binding Extension, must process the extension and, upon accepting the
+   flow policy, must set up the forwarding plane that matches the flow
+   policy.  If the home agent cannot identify any of the binding
+   identifiers, then it MUST reject the request with a Registration
+   Reply and with the Code set to INVALID_FB_IDENTIFIER.
+
+   If the received Registration Request includes a Multipath Extension
+   and additionally has the Registration Overwrite (O) flag set to a
+   value of (1), then the home agent 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.  Routing Considerations
+
+   When multipath registration is enabled for a mobility node, there
+   will be multiple Mobile IP tunnels established between a mobile node
+   and its home agent.  These Mobile IP tunnels appear to the forwarding
+   plane of the mobile node as equal-cost, point-to-point links.
+
+   If there is also an exchange of traffic flow policy between the
+   mobile node and the home agent, with the use of Flow-Binding
+   Extensions (Section 4.2), then the mobile node's IP traffic can be
+   routed by the mobility entities as per the negotiated flow policy.
+   However, if multipath is enabled for a mobility session without the
+   use of any flow policy exchange, then both the mobile node and the
+   home agent are required to have a pre-configured static flow policy.
+   The specific details on the semantics of this static flow policy are
+   outside the scope of this document.
+
+   In the absence of any established traffic flow policies, most IP
+   hosts support two alternative traffic load-balancing schemes, per-
+   flow and per-packet load balancing [RFC2991].  These load-balancing
+   schemes allow the forwarding plane to evenly distribute traffic on
+   either a per-packet or per-flow basis, across all the available
+
+
+
+Gundavelli, et al.            Experimental                     [Page 14]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+   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 effectively but with the potential issue of packet
+   re-ordering on the receiver end.  This issue will be specially
+   magnified when the access links have very different forwarding
+   characteristics.  A host can choose to enable any of these
+   approaches.  Therefore, this specification recommends the use of per-
+   flow load balancing.
+
+7.  IANA Considerations
+
+   Per this document, the following IANA actions have been completed.
+
+   o  Action 1: This specification defines two new Mobile IP extensions,
+      the Multipath Extension and the Flow-Binding Extension.  The
+      format of the Multipath Extension is described in Section 4.1, and
+      the format of the Flow-Binding Extension is described in
+      Section 4.2.  Both of these extensions are non-skippable
+      extensions to the Mobile IPv4 header in accordance to the long
+      extension format of [RFC5944].  Both of these extensions use a
+      common Type value, Multipath-Extension (154), but are identified
+      using different Subtype values.  The Type value 154 for these
+      extensions has been allocated from the "Extensions to Mobile IP
+      Registration Messages" registry at the URL
+      <http://www.iana.org/assignments/mobileip-numbers>.  The field
+      "Permitted for Notification Messages" for this extension MUST be
+      set to "N".
+
+   o  Action 2: This specification defines a new message subtype space,
+      Multipath Extension subtype.  This field is described in
+      Section 4.1.  The values for this subtype field are managed by
+      IANA under the "Multipath Extension subtypes (Value 154)"
+      registry.  This specification reserves the following Type values.
+      Approvals of new Multipath Extension subtype values are to be made
+      through IANA Expert Review [RFC5226].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 15]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+      +=========================================================+
+      |  0    | Reserved                                        |
+      +=========================================================+
+      |  1    | Multipath Extension                             |
+      +=========================================================+
+      |  2    | Flow-Binding Extension                          |
+      +=========================================================+
+      |       |                                                 |
+      ~ 3-254 | Unassigned                                      ~
+      |       |                                                 |
+      +=========================================================+
+      |  255  | Reserved                                        |
+      +=========================================================+
+
+   o  Action 3: This document defines new status code values,
+      MULTIPATH_NOT_ALLOWED (152) and INVALID_FB_IDENTIFIER (153), for
+      use by the home agent in the Code field of the Registration Reply,
+      as described in Section 4.3.  These values have been assigned from
+      the "Registration denied by the home agent" registry at
+      <http://www.iana.org/assignments/mobileip-numbers>.
+
+8.  Security Considerations
+
+   This specification allows a mobile node to establish multiple Mobile
+   IP tunnels with its home agent by registering a care-of address for
+   each of its active roaming interfaces.  This essentially allows the
+   mobile node's IP traffic to be routed through any of the tunnel paths
+   based on a static or a dynamically negotiated flow policy.  This new
+   capability has no impact on the protocol security.  Furthermore, this
+   specification defines two new Mobile IP extensions, the Multipath
+   Extension and the Flow-Binding Extension.  These extensions are
+   specified to be included in Mobile IP control messages, which are
+   authenticated and integrity protected as described in [RFC5944].
+   Therefore, this specification does not weaken the security of the
+   Mobile IP protocol and does not introduce any new security
+   vulnerabilities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 16]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
+              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
+              RFC 5213, DOI 10.17487/RFC5213, August 2008,
+              <http://www.rfc-editor.org/info/rfc5213>.
+
+   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
+              RFC 5944, DOI 10.17487/RFC5944, November 2010,
+              <http://www.rfc-editor.org/info/rfc5944>.
+
+   [RFC6088]  Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
+              "Traffic Selectors for Flow Bindings", RFC 6088,
+              DOI 10.17487/RFC6088, January 2011,
+              <http://www.rfc-editor.org/info/rfc6088>.
+
+9.2.  Informative References
+
+   [RFC2991]  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
+              Multicast Next-Hop Selection", RFC 2991,
+              DOI 10.17487/RFC2991, November 2000,
+              <http://www.rfc-editor.org/info/rfc2991>.
+
+   [RFC3753]  Manner, J., Ed. and M. Kojo, Ed., "Mobility Related
+              Terminology", RFC 3753, DOI 10.17487/RFC3753, June 2004,
+              <http://www.rfc-editor.org/info/rfc3753>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC5454]  Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile
+              IPv4", RFC 5454, DOI 10.17487/RFC5454, March 2009,
+              <http://www.rfc-editor.org/info/rfc5454>.
+
+   [RFC6626]  Tsirtsis, G., Park, V., Narayanan, V., and K. Leung,
+              "Dynamic Prefix Allocation for Network Mobility for Mobile
+              IPv4 (NEMOv4)", RFC 6626, DOI 10.17487/RFC6626, May 2012,
+              <http://www.rfc-editor.org/info/rfc6626>.
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 17]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+Acknowledgements
+
+   We would like to thank Qin Wu, Shahriar Rahman, Mohana Jeyatharan,
+   Yungui Wang, Hui Deng Behcet Sarikaya, Jouni Korhonen, Michaela
+   Vanderveen, Antti Makela, Charles Perkins, Pierrick Seite, Vijay
+   Gurbani, Barry Leiba, Henrik Levkowetz, Pete McCann, and Brian
+   Haberman for their review and comments on this document.
+
+Contributors
+
+   This document reflects discussions and contributions from the
+   following people:
+
+   Ahmad Muhanna
+   Email: asmuhanna@yahoo.com
+
+   Srinivasa Kanduru
+   Email: skanduru@gmail.com
+
+   Vince Park
+   Email: vpark@qualcomm.com
+
+   Hesham Soliman
+   Email: hesham@elevatemobile.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 18]
+
+RFC 7629           Flow-Binding Support for Mobile IP        August 2015
+
+
+Authors' Addresses
+
+   Sri Gundavelli (editor)
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA  95134
+   United States
+
+   Email: sgundave@cisco.com
+
+
+   Kent Leung
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA  95134
+   United States
+
+   Email: kleung@cisco.com
+
+
+   George Tsirtsis
+   Qualcomm
+
+   Email: tsirtsis@qualcomm.com
+
+
+   Alexandre Petrescu
+   CEA, LIST
+   CEA Saclay
+   Gif-sur-Yvette , Ile-de-France  91191
+   France
+
+   Phone: +33169089223
+   Email: alexandre.petrescu@cea.fr
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.            Experimental                     [Page 19]
+