diff options
Diffstat (limited to 'doc/rfc/rfc6909.txt')
| -rw-r--r-- | doc/rfc/rfc6909.txt | 787 |
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] + |