doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc6909.txt b/doc/rfc/rfc6909.txt
new file mode 100644
index 0000000..df0ea84
--- /dev/null
+++ b/doc/rfc/rfc6909.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                S. Gundavelli, Ed.
+Request for Comments: 6909                                         Cisco
+Category: Standards Track                                        X. Zhou
+ISSN: 2070-1721                                          ZTE Corporation
+                                                             J. Korhonen
+                                                          Renesas Mobile
+                                                                G. Feige
+                                                               R. Koodli
+                                                                   Cisco
+                                                              April 2013
+
+
+       IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6
+
+Abstract
+
+   This specification defines a new mobility option, the IPv4 Traffic
+   Offload Selector option, for Proxy Mobile IPv6.  This option can be
+   used by the local mobility anchor and the mobile access gateway for
+   negotiating IPv4 traffic offload policy for a mobility session.
+   Based on the negotiated IPv4 traffic offload policy, a mobile access
+   gateway can selectively offload some of the IPv4 traffic flows in the
+   access network instead of tunneling back to the local mobility anchor
+   in the home network.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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/rfc6909.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 1]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 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 ....................................................2
+   2. Conventions and Terminology .....................................4
+      2.1. Conventions ................................................4
+      2.2. Terminology ................................................4
+   3. Solution Overview ...............................................4
+      3.1. IPv4 Traffic Offload Selector Option .......................6
+      3.2. MAG Considerations .........................................8
+      3.3. LMA Considerations .........................................9
+   4. Protocol Configuration Variables ...............................11
+   5. IANA Considerations ............................................11
+   6. Security Considerations ........................................12
+   7. Acknowledgements ...............................................12
+   8. References .....................................................13
+      8.1. Normative References ......................................13
+      8.2. Informative References ....................................13
+
+1.  Introduction
+
+   Mobile operators are expanding their network coverage by integrating
+   various access technology domains (e.g., Wireless LAN, CDMA, and
+   Long-Term Evolution (LTE)) into a common IP mobility core.  The Third
+   Generation Partnership Project (3GPP) S2a Proxy Mobile IPv6 [TS23402]
+   reference point, specified by the 3GPP system architecture, defines
+   the protocol interworking for building such integrated multi-access
+   networks.  In this scenario, the mobile node's IP traffic is always
+   tunneled back from the mobile access gateway [RFC5213] in the access
+   network to the local mobility anchor in the home network.  Currently,
+   there is no mechanism for allowing some of the subscriber's IP flows
+   to be offloaded in the access network.
+
+
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 2]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+   With the exponential growth in mobile data traffic, mobile operators
+   are exploring new ways to offload some of the IP traffic flows at the
+   nearest access edge.  The offload is intended either for local
+   service access in the access network or for Internet offload through
+   the access network when there is an Internet peering point.  Not all
+   IP traffic flows need to be routed back to the home network; the
+   traffic that does not require IP mobility support can be offloaded at
+   the mobile access gateway in the access network.  This approach
+   allows efficient usage of the mobile packet core, which helps in
+   lowering transport costs.  To identify the IP flows that need to be
+   offloaded, the local mobility anchor in the home network can deliver
+   the IP flow policy to the mobile access gateway in the access
+   network.  It is up to an operator's discretion to classify the
+   traffic for offload.  One operator might choose to offload everything
+   except traffic (such as Voice over IP) that requires QoS services.
+   Another might choose to offload only HTTP traffic.  This
+   specification is only concerned with matching IP traffic against a
+   given flow selector and classification of IP traffic for offloading
+   purposes.  This approach has one limitation with respect to
+   identifying encrypted traffic: IPsec-encrypted traffic with no
+   visibility into the application payload cannot be selected for
+   offload.
+
+   This document defines a new mobility option, the IPv4 Traffic Offload
+   Selector option (see Section 3.1), for Proxy Mobile IPv6 (PMIPv6).
+   This option can be used by the local mobility anchor and the mobile
+   access gateway for negotiating IPv4 traffic offload policy for a
+   mobility session.  This IPv4 traffic offload policy identifies the
+   flow selectors that can be used for selecting the flows that can be
+   offloaded at the access edge.  Since the mobile node's IP address
+   topologically belongs to the home network, the offloaded IPv4 traffic
+   flows may need to be NAT [RFC2663] translated.  These offloaded flows
+   will not have mobility support as the NAT becomes the anchor point
+   for those flows.  However, when the traffic is offloaded for local
+   service access as opposed to Internet offload, NAT translation may
+   not be needed if the mobile access gateway is in the path for the
+   return traffic.  The decision on when to apply NAT translation can be
+   based on local configuration on the mobile access gateway.  There are
+   better ways to address the offload problem for IPv6, and with the
+   goal not to create a NAT66 requirement, this specification therefore
+   does not address traffic offload support for IPv6 flows.
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 3]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+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 the base Proxy Mobile IPv6 specifications
+   [RFC5213] [RFC5844].  Additionally, this document uses the following
+   terms:
+
+   IP Flow
+
+      IP flow [RFC5101] represents a set of IP packets that match a
+      traffic selector (TS).  The selector is typically based on the
+      source IP address, destination IP address, source port,
+      destination port, and other fields in upper-layer headers.
+
+   IP Traffic Offload
+
+      IP traffic offload is the approach of selecting specific IP flows
+      and routing them through the access network instead of tunneling
+      them to the home network.  Offload can also be between two access
+      networks (e.g., moving some of the traffic from LTE access to WLAN
+      access).
+
+3.  Solution Overview
+
+   Figure 1 illustrates the scenario where the mobile access gateway in
+   an access network has enabled IPv4 traffic offload support for a
+   mobility session.  The offload decision is based on the IPv4 traffic
+   offload policy that it negotiated with the local mobility anchor in
+   the home network.  For example, all the HTTP flows may be offloaded
+   at the mobile access gateway, and all the other flows for that
+   mobility session are tunneled back to the local mobility anchor.  The
+   offloaded flows typically have to be NAT translated, and this
+   specification does not impose any restrictions on the location of the
+   NAT function.  It is possible for the NAT function to be co-located
+   with the mobile access gateway or located somewhere at the edge of
+   the access network.  When the NAT function is not co-located with the
+   mobile access gateway, offloaded traffic flows must be delivered
+   through the local access network between the mobile access gateway
+   and the NAT function, for example, through a VLAN or a point-to-point
+   link.  The exact means for this delivery are outside the scope of
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 4]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+   this document.  If the offloaded IPv4 flows are for local service
+   access and reverse traffic from the local service device can be
+   routed to the mobile node through the mobile access gateway, the
+   offloaded flows may be delivered directly to a local service device.
+
+   The traffic selectors in the IPv4 traffic offload policy are used to
+   classify the traffic, so it can be offloaded at the access network.
+   These parameters include source IP address, destination IP address,
+   TCP/UDP port numbers, and other fields.  The format of the IPv4
+   binary traffic selector is specified in Section 3.1 of [RFC6088].
+
+                                      _----_
+                                    _(      )_
+                 :-----------------( Internet )---------------:
+                 |                  (_      _)                |
+                 |                    '----'                  |
+                 |                                            |
+                 :                                            |
+      (IPv4 Traffic Offload Point)                            |
+                 :                                            |
+                 |                                            |
+      ........................................................|....
+                 |                              |             |
+      +--------+ |                   +---------------------+  |
+      |  Local | |                   | Services requiring  |  |
+      |Services| |                   | mobility, or service|  |
+      +--------+ |                   | treatment           |  |
+           |     |                   +---------------------+  |
+           |   +---+                            |             |
+           |   |NAT|                            |             |
+           |   +---+                            |             |
+           +-----|            _----_            |             |
+              +-----+       _(      )_       +-----+          |
+      [MN]----| MAG |======(    IP    )======| LMA |----------
+              +-----+       (_      _)       +-----+  Internet
+                              '----'
+                                 .
+                                 .
+          [Access Network]       .        [Home Network]
+      ..........................................................
+
+             Figure 1: IPv4 Traffic Offload Support at the MAG
+
+   Figure 2 explains the operational sequence of the Proxy Mobile IPv6
+   protocol signaling message exchange between the mobile access gateway
+   (MAG) and the local mobility anchor (LMA) for negotiating the IPv4
+   traffic offload selectors.  The details related to DHCP transactions
+   or Router Advertisements on the access link are not shown here as
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 5]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+   that is not the key focus of this specification.  The use of IPv4
+   Traffic Selector option in the Proxy Binding Update is for allowing
+   the MAG to request the LMA for the IPv4 traffic offload policy.
+
+      MN    MAG(NAT)   LMA
+      |------>|        |    1.  Mobile Node Attach
+      |       |------->|    2.  Proxy Binding Update (IPv4TS)
+      |       |<-------|    3.  Proxy Binding Acknowledgement (IPv4TS)
+      |       |========|    4.  Tunnel/Route Setup
+      |       +        |    5.  Installing the traffic offload rules
+      |------>|        |    6.  IPv4 packet from mobile node
+      |       +        |    7.  Offload rule applied (Tunnel/offload)
+      |       |        |
+
+           Figure 2: Exchange of IPv4 Traffic Offload Selectors
+
+3.1.  IPv4 Traffic Offload Selector Option
+
+   A new mobility option, the IPv4 Traffic Offload Selector option (53),
+   is defined for use in Proxy Binding Update (PBU) and Proxy Binding
+   Acknowledgement (PBA) messages exchanged between a mobile access
+   gateway and a local mobility anchor.  This option is used for
+   carrying the IPv4 traffic offload policy.  This policy identifies the
+   IPv4 traffic flow selectors that can be used by the mobile access
+   gateway for enforcing the offload policy.
+
+   The alignment requirement for this option is 4n.
+
+   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      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |M|                         Reserved                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Traffic Selector Sub-option   ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 3: IPv4 Traffic Offload Selector Option
+
+   Type
+      53
+
+   Length
+      8-bit unsigned integer indicating the length in octets of the
+      option, excluding the type and length fields.
+
+
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 6]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+   Offload Mode (M) Flag
+      This field indicates the offload mode.
+
+         If the (M) flag value is set to a value of (0), it is an
+         indication that the IPv4 flow(s) that match the traffic
+         selectors in the Traffic Selector sub-option [RFC6089] and that
+         are associated to that mobility session have to be offloaded at
+         the mobile access gateway.  All the other IPv4 flows associated
+         with that mobility session and not matching the traffic
+         selectors have to be tunneled to the local mobility anchor.
+
+         If the (M) flag value is set to a value of (1), it is an
+         indication that all the IPv4 flows associated to that mobility
+         session except the IPv4 flow(s) matching the traffic selectors
+         in the Traffic Selector sub-option have to be offloaded at the
+         mobile access gateway.  All the IPv4 flows associated with that
+         mobility session and matching the traffic selectors have to be
+         tunneled back to the local mobility anchor.
+
+   Reserved
+      This field is unused for now.  The value MUST be initialized to 0
+      by the sender and MUST be ignored by the receiver.
+
+   Traffic Selector Sub-option
+      The Traffic Selector sub-option includes the parameters used to
+      match packets for a specific flow binding.  This is an optional
+      sub-option when the IPv4 Traffic Selector option is carried in a
+      Proxy Binding Update message but is a mandatory sub-option when
+      the IPv4 Traffic Selector option is carried in a Proxy Binding
+      Acknowledgement message.  The format of the Traffic Selector sub-
+      option is defined in Section 4.2.1.4 of [RFC6089].  This sub-
+      option includes a TS Format field, which identifies the format of
+      the flow specification included in that sub-option.  The values
+      for that field are defined in Section 3 of [RFC6088] and are
+      repeated here for completeness.  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 that
+      support is mandatory for this specification.  The text specified
+      in this section takes precedence over what is specified in
+      [RFC6088] and [RFC6089].
+
+         1: IPv4 binary traffic selector
+
+         2: IPv6 binary traffic selector (not used by this
+         specification)
+
+
+
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 7]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+3.2.  MAG Considerations
+
+   o  If the mobile access gateway is configured to enable IPv4 traffic
+      offload support, then it includes the IPv4 Traffic Offload
+      Selector option (Section 3.1) in the Proxy Binding Update message
+      that it sends to the local mobility anchor.  Optionally, the
+      mobile access gateway can also propose a specific offload policy.
+
+      *  The mobile access gateway MAY choose not to propose any
+         specific IPv4 traffic offload policy but request the local
+         mobility anchor for the offload policy.  In this scenario, the
+         IPv4 Traffic Offload Selector option that is carried in the
+         Proxy Binding Update message does not include the Traffic
+         Selector sub-option (see Section 3.1), and the (M) flag (see
+         Section 3.1) in the option MUST be set to a value of (0).
+         Including the IPv4 Traffic Offload Selector option in the Proxy
+         Binding Update without the Traffic Selector sub-option serves
+         as an indication that the mobile access gateway is not
+         proposing any specific offload policy for that mobility
+         session, but rather it makes a request to the local mobility
+         anchor to provide the offload policy.
+
+      *  The mobile access gateway MAY choose to propose a specific IPv4
+         traffic offload policy by including the Traffic Selector sub-
+         option in the IPv4 Traffic Offload Selector option (see
+         Section 3.1).  The specific details on how the mobile access
+         gateway obtains the mobile node's IPv4 traffic offload policy
+         are outside the scope of this document.  When this offload
+         policy is included in the Proxy Binding Update message, it
+         serves as a proposal to the local mobility anchor.  The local
+         mobility anchor can override with its own offload policy, or it
+         can agree to the proposed policy.  The offload policy has to be
+         translated to a set of selectors that can be used to match the
+         mobile node's IP flows, and these selectors have to be carried
+         in the Traffic Selector sub-option.  The Traffic Selector sub-
+         option MUST be constructed as specified in Section 4.2.1.4 of
+         [RFC6089].  This sub-option includes a TS Format field, which
+         identifies the format of the flow specification included in the
+         sub-option.  The values for that field and the corresponding
+         message format are defined in Section 3.1 of [RFC6088].
+         Considerations from Section 3.1 apply with respect to setting
+         the Offload Mode (M) flag.
+
+   o  When sending a Proxy Binding Update either for Binding Lifetime
+      Extension or for Binding De-Registration, the mobile access
+      gateway SHOULD copy the IPv4 Traffic Offload Selector option from
+      the initial Proxy Binding Update message.  Considerations from
+      Sections 6.9.1.3 and 6.9.1.4 of [RFC5213] MUST be applied.
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 8]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+   o  If the mobile access gateway is not configured to support IPv4
+      traffic offload support as specified in this specification, but if
+      the received Proxy Binding Acknowledgement message has the IPv4
+      Traffic Offload Selector option, then the mobile access gateway
+      MUST ignore the option and process the rest of the message as per
+      [RFC5213].
+
+   o  If there is no IPv4 Traffic Offload Selector option in the Proxy
+      Binding Acknowledgement message received from the local mobility
+      anchor, it is an indication that the local mobility anchor did not
+      enable IPv4 traffic offload support for that mobility session.
+      Upon accepting the Proxy Binding Acknowledgement message, the
+      mobile access gateway SHOULD NOT enable IPv4 traffic offload
+      support for that mobility session.
+
+   o  If there is an IPv4 Traffic Offload Selector option in the Proxy
+      Binding Acknowledgement message, then the mobile access gateway
+      SHOULD enable IPv4 traffic offload support for that mobility
+      session.  The mobility access gateway has to provision the data
+      plane using the flow selectors present in the Traffic Selector
+      sub-option.  The IPv4 flows matching the flow selectors have to be
+      offloaded or tunneled back based to the local mobility anchor
+      based on the value of the Offload Mode (M) flag (see Section 3.1).
+
+3.3.  LMA Considerations
+
+   o  If the received Proxy Binding Update message does not include the
+      IPv4 Traffic Offload Selector option (Section 3.1), then the local
+      mobility anchor MUST NOT enable IPv4 traffic offload support for
+      that mobility session, and the Proxy Binding Acknowledgement
+      message that will be sent in response MUST NOT contain the IPv4
+      Traffic Offload Selector option.
+
+   o  If the Proxy Binding Update message includes the IPv4 Traffic
+      Offload Selector option, but the local mobility anchor is not
+      configured to support IPv4 traffic offload support, then the local
+      mobility anchor will ignore the option and process the rest of the
+      message as per [RFC5213].  This would have no effect on the
+      operation of the rest of the protocol.
+
+   o  If the Proxy Binding Update message has the IPv4 Traffic Offload
+      Selector option and if the local mobility anchor is configured to
+      support IPv4 traffic offload support, then the local mobility
+      anchor MUST enable IPv4 traffic offload support for that mobility
+      session.  The Proxy Binding Acknowledgement message that will be
+      sent in response MUST include the IPv4 Traffic Offload Selector
+      option.  The following considerations apply with respect to
+      constructing the IPv4 Traffic Offload Selector option.
+
+
+
+Gundavelli, et al.           Standards Track                    [Page 9]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+      *  The local mobility anchor can obtain the offload policy from
+         the local configuration store or from a network function such
+         as AAA (Authentication, Authorization, and Accounting) or PCRF
+         (Policy and Charging Rule Function).  The offload policy has to
+         be translated to a set of selectors that can be used to match
+         the mobile node's IP flows, and these selectors have to be
+         carried in the Traffic Selector sub-option.  The Traffic
+         Selector sub-option MUST be constructed as specified in Section
+         4.2.1.4 of [RFC6089].  Considerations from Section 3.1 apply
+         with respect to the Offload Mode (M) flag setting.
+
+      *  If the Proxy Binding Update message includes a specific IPv4
+         traffic offload policy proposal in the form of the Traffic
+         Selector sub-option [RFC6089], then the local mobility anchor
+         MAY choose to agree to that request by including the same IPv4
+         traffic offload policy in the Proxy Binding Acknowledgement
+         message.  This implies the local mobility anchor has agreed to
+         the IPv4 traffic offload policy provided by the mobile access
+         gateway.  The local mobility anchor MAY also choose to override
+         the request by including a different IPv4 traffic offload
+         policy that it wants the mobile access gateway to enforce for
+         that mobility session.  This is entirely based on the policy
+         configuration on the local mobility anchor.
+
+      *  The IPv4 traffic offload policy that is sent to the mobile
+         access gateway has to be specific to the mobility session
+         identified using the Mobile Node Identifier option [RFC5213].
+         The offload policy MUST be specific to a mobile node's
+         application traffic.  The traffic selectors have to match only
+         the mobile node's application traffic and MUST NOT match any
+         other mobile node's IP traffic.  Furthermore, control-plane
+         traffic such as DHCP, Neighbor Discovery (ND), or any other IP
+         traffic that is used for IP address configuration, mobility
+         management, or other control-plane functions MUST NOT be
+         subject to offload.
+
+      *  The local mobility anchor MUST NOT make any changes to the
+         mobile node's offload policy during the middle of a mobility
+         session, as long as the mobile node continues to attach to the
+         mobile access gateway that negotiated the offload policy.
+         However, when the mobile node performs an inter-MAG handover,
+         the new mobile access gateway may not be capable of supporting
+         IP Traffic offload and in this scenario, the offload policy may
+         change.  Therefore, the IPv4 Traffic Selector option with the
+         Traffic Selector sub-option that is delivered during the
+         initial mobility signaling MUST be the same as the one that is
+         delivered as part of the mobility signaling related to lifetime
+         extension from the same mobile access gateway.
+
+
+
+Gundavelli, et al.           Standards Track                   [Page 10]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+4.  Protocol Configuration Variables
+
+   This specification defines the following configuration variable that
+   controls the IPv4 traffic offload support feature.  This
+   configuration variable is internal to the system and has no bearing
+   on interoperability across different implementations.
+
+   The mobility entities, local mobility anchor, and the mobile access
+   gateway have to allow these variables to be configured by the system
+   management.  The configured values for these protocol variables have
+   to survive server reboots and service restarts.
+
+   EnableIPv4TrafficOffloadSupport
+
+         This flag indicates whether or not IPv4 traffic offload support
+         needs to be enabled.  This configuration variable is available
+         at both the mobile access gateway and the local mobility
+         anchor.  The default value for this flag is set to (0),
+         indicating that IPv4 traffic offload support is disabled.
+
+         When this flag on the mobile access gateway is set to a value
+         of (1), the mobile access gateway has to enable IPv4 traffic
+         offload support for all mobility sessions, by specifically
+         requesting the IPv4 traffic offload policy from the local
+         mobility anchor by including the IPv4 Traffic Offload Selector
+         option in the Proxy Binding Update message.  If the flag is set
+         to a value of (0), the mobile access gateway has to disable
+         IPv4 traffic offload support for all mobility sessions.
+
+         Similarly, when this flag on the local mobility anchor is set
+         to a value of (1), the local mobility anchor has to enable IPv4
+         traffic offload support.  If the local mobility anchor chooses
+         to enable IPv4 traffic offload support when there is an offload
+         policy specified for a mobile node, it has to deliver the IPv4
+         traffic offload policy to the mobile access gateway by
+         including the IPv4 Traffic Offload Selector option in the Proxy
+         Binding Acknowledgement message.
+
+5.  IANA Considerations
+
+   Per this specification, IANA has assigned a new mobility option: the
+   IPv4 Traffic Offload Selector option (53).  This option is described
+   in Section 3.1.  The Type value for this option has been assigned
+   from the same numbering space as allocated for the other mobility
+   options [RFC6275].
+
+
+
+
+
+
+Gundavelli, et al.           Standards Track                   [Page 11]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+6.  Security Considerations
+
+   The IPv4 Traffic Offload Selector option defined in this
+   specification is for use in Proxy Binding Update and Proxy Binding
+   Acknowledgement messages.  This option is carried like any other
+   mobility header option as specified in [RFC5213].  Therefore, it
+   inherits from [RFC5213] its security guidelines and does not require
+   any additional security considerations.  Carrying IPv4 traffic
+   offload selectors does not introduce any new security
+   vulnerabilities.
+
+   When IPv4 traffic offload support is enabled for a mobile node, the
+   mobile access gateway selectively offloads some of the mobile node's
+   IPv4 traffic flows to the access network.  Typically, these offloaded
+   flows get NAT translated, which essentially introduces certain
+   vulnerabilities that are common to any NAT deployment.  These
+   vulnerabilities and the related considerations have been well
+   documented in the NAT specification [RFC2663].  There are no
+   additional considerations above and beyond what has already been
+   documented by the NAT specifications and that are unique to the
+   approach specified in this document.
+
+   The mobile node's home network may be equipped with firewall and
+   other security devices to guard against any security threats.  When
+   IPv4 traffic offload support is enabled, it potentially exposes the
+   mobile node to some security risks in the access network.  This
+   threat can be mitigated by deploying the security features both in
+   the access network and in the home network.
+
+   When IPv4 traffic offload support is enabled for a mobile node, some
+   of the IP flows are sent through the home network, and some other IP
+   flows are routed through the access network.  This potentially
+   introduces some complexity with respect to enabling diagnostics or
+   monitoring on the user traffic.  The tools that are used for such
+   diagnostics have to be aware of the offload policy that in enabled in
+   the network.
+
+7.  Acknowledgements
+
+   The authors would like to thank Ahmad Muhanna, Basavaraj Patil,
+   Carlos Bernardos, Eric Voit, Frank Brockners, Hidetoshi Yokota, Marco
+   Liebsch, Mark Grayson, Pierrick Seite, Ryuji Wakikawa, Steve Wood,
+   Barry Leiba, Sean Turner, Pete Resnick, Wesley Eddy, Mary Barnes,
+   Vincent Roca, Ralph Droms, Scott Bradner, Stephen Farrell, Adrian
+   Farrel, Benoit Claise, and Brian Haberman for all the reviews and
+   discussions related to the topic of IPv4 traffic offload.
+
+
+
+
+
+Gundavelli, et al.           Standards Track                   [Page 12]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
+              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
+
+   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
+              Mobile IPv6", RFC 5844, May 2010.
+
+   [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.,
+              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
+              Network Mobility (NEMO) Basic Support", RFC 6089,
+              January 2011.
+
+   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
+              in IPv6", RFC 6275, July 2011.
+
+8.2.  Informative References
+
+   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
+              Translator (NAT) Terminology and Considerations",
+              RFC 2663, August 1999.
+
+   [RFC5101]  Claise, B., "Specification of the IP Flow Information
+              Export (IPFIX) Protocol for the Exchange of IP Traffic
+              Flow Information", RFC 5101, January 2008.
+
+   [TS23402]  3GPP, "Architecture enhancements for non-3GPP accesses",
+              2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gundavelli, et al.           Standards Track                   [Page 13]
+
+RFC 6909          IPv4 Traffic Offload Selector Option        April 2013
+
+
+Authors' Addresses
+
+   Sri Gundavelli (editor)
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   EMail: sgundave@cisco.com
+
+
+   Xingyue Zhou
+   ZTE Corporation
+   No.68 Zijinghua Rd
+   Nanjing
+   China
+
+   EMail: zhou.xingyue@zte.com.cn
+
+
+   Jouni Korhonen
+   Renesas Mobile
+   Porkkalankatu 24
+   Helsinki  FIN-00180
+   Finland
+
+   EMail: jouni.nospam@gmail.com
+
+
+   Gaetan Feige
+   Cisco
+   France
+
+   EMail: gfeige@cisco.com
+
+
+   Rajeev Koodli
+   Cisco
+   3650 Cisco Way
+   San Jose, CA  95134
+   USA
+
+   EMail: rkoodli@cisco.com
+
+
+
+
+
+
+
+
+Gundavelli, et al.           Standards Track                   [Page 14]
+