idnits 2.17.1 draft-ietf-netext-pmipv6-sipto-option-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 24, 2013) is 4072 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG S. Gundavelli, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track X. Zhou 5 Expires: August 28, 2013 ZTE Corporation 6 J. Korhonen 7 Nokia Siemens Networks 8 G. Feige 9 R. Koodli 10 Cisco 11 February 24, 2013 13 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 14 draft-ietf-netext-pmipv6-sipto-option-12.txt 16 Abstract 18 This specification defines a new mobility option, IPv4 Traffic 19 Offload Selector option, for Proxy Mobile IPv6. This option can be 20 used by the local mobility anchor and the mobile access gateway for 21 negotiating IPv4 traffic offload policy for a mobility session. 22 Based on the negotiated IPv4 traffic offload policy, a mobile access 23 gateway can selectively offload some of the IPv4 traffic flows in the 24 access network instead of tunneling back to the local mobility anchor 25 in the home network. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 28, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 63 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. IPv4 Traffic Offload Selector Option . . . . . . . . . . . 7 67 3.2. MAG Considerations . . . . . . . . . . . . . . . . . . . . 9 68 3.3. LMA Considerations . . . . . . . . . . . . . . . . . . . . 10 69 4. Protocol Configuration Variables . . . . . . . . . . . . . . . 12 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Mobile Operators are expanding their network coverage by integrating 81 various access technology domains (Ex: Wireless LAN, CDMA, LTE) into 82 a common IP mobility core. The 3GPP S2a Proxy Mobile IPv6 [TS23402] 83 reference point, specified by the 3GPP system architecture defines 84 the protocol inter-working for building such integrated multi-access 85 network. In this scenario, the mobile node's IP traffic is always 86 tunneled back from the mobile access gateway [RFC5213] in the access 87 network to the local mobility anchor in the home network. Currently, 88 there is no mechanism for allowing some of the subscriber's IP flows 89 to be offloaded in the access network. 91 With the exponential growth in the mobile data traffic, mobile 92 operators are exploring new ways to offload some of the IP traffic 93 flows at the nearest access edge. The offload is intended either for 94 local service access in the access network, or for internet offload 95 through the access network when there is an internet peering point. 96 Not all IP traffic flows needs to be routed back to the home network, 97 some of the non-essential traffic which does not require IP mobility 98 support can be offloaded at the mobile access gateway in the access 99 network. This approach allows efficient usage of the mobile packet 100 core which helps in lowering transport costs. The local mobility 101 anchor in the home network can deliver the IP flow policy to the 102 mobile access gateway in the access network, for identifying the IP 103 flows that need to be offloaded. It's a policy decision as to which 104 traffic an operator deems as non-essential. One operator might 105 choose to offload everything except traffic (such as Voice over IP) 106 that requires QoS services. Another might choose to offload only 107 HTTP traffic. From the point of view of this specification, it is 108 only about IP traffic matching a given flow selector and 109 classification for offload. This approach has one limitation with 110 respect to identifying encrypted traffic: IPsec encrypted traffic 111 with no visibility into the application payload cannot be selected 112 for offload. 114 This document defines a new mobility option, IPv4 Traffic Offload 115 Selector option (Section 3.1) for Proxy Mobile IPv6 (PMIPv6). This 116 option can be used by the local mobility anchor for delivering the 117 IPv4 traffic offload policy associated with a mobility session to the 118 mobile access gateway. This IPv4 traffic offload policy identifies 119 the flow selectors that can used for selecting the flows for 120 offloading them at the access edge. Since, the mobile node's IP 121 address topologically belongs to the home network, the offloaded IPv4 122 traffic flows may need to be NAT [RFC2663] translated. These 123 offloaded flows will not have mobility support as the NAT becomes the 124 anchor point for those flows. However, when the traffic is offloaded 125 for local service access as opposed to internet offload, NAT 126 translation may not be needed, if the mobile access gateways is in 127 path for the return traffic. The decision on when to apply NAT 128 translation can be based on local configuration on the mobile access 129 gateway. There are better ways to address the offload problem for 130 IPv6 and with the goal not to create NAT66 requirement, this 131 specification therefore does not support traffic offload support for 132 IPv6 flows. 134 2. Conventions and Terminology 136 2.1. Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2.2. Terminology 144 All the mobility related terms used in this document are to be 145 interpreted as defined in the base Proxy Mobile IPv6 specifications 146 [RFC5213] and [RFC5844]. Additionally, this document uses the 147 following terms: 149 IP Flow 151 IP Flow [RFC5101] represents a set of IP packets that match a 152 traffic selector. The selector is typically based on the source 153 IP address, destination IP address, source port, destination port 154 and other fields in upper layer headers. 156 IP Traffic Offload 158 The approach of selecting specific IP flows and routing them 159 through the access network, instead of tunneling them to the home 160 network. Offload can also be between two access networks 161 (Example: moving some of the traffic from LTE access to WLAN 162 access). 164 3. Solution Overview 166 Figure 1 illustrates the scenario where the mobile access gateway in 167 an access network has enabled IPv4 traffic offload support for a 168 mobility session. The offload decision is based on the IPv4 traffic 169 offload policy that it negotiated with the local mobility anchor in 170 the home network. For example, all the HTTP flows may be offloaded 171 at the mobile access gateway and all the other flows for that 172 mobility session are tunneled back to the local mobility anchor. The 173 offloaded flows have to be typically NAT translated and this 174 specification does not impose any restrictions on the location of the 175 NAT function. It is possible for the NAT function to be co-located 176 with the mobile access gateway or located somewhere in the edge of 177 the access network. When the NAT function is not co-located with the 178 mobile access gateway, offloaded traffic flows must be delivered 179 through the local access network between the mobile access gateway 180 and the NAT function, for example through a VLAN or a point-to-point 181 link. The exact means for this delivery are outside the scope of 182 this document. If the offloaded IPv4 flows are for local service 183 access and reverse traffic from the local service device can be 184 routed to the mobile node through the mobile access gateway, the 185 offloaded flows may be delivered directly to local service device. 187 The traffic selectors in the IPv4 traffic offload policy are used to 188 classify the traffic, so it can be offloaded to the access network. 189 These parameters include Source IP address, Destination IP address, 190 TCP/UDP Port numbers, and other fields. The format of the IPv4 191 Binary Traffic Selector is specified in section 3.1 of [RFC6088]. 193 _----_ 194 _( )_ 195 :-----------------( Internet )---------------: 196 | (_ _) | 197 | '----' | 198 | | 199 : | 200 (IPv4 Traffic Offload Point) | 201 : | 202 | | 203 ........................................................|.... 204 | | | 205 +--------+ | +---------------------+ | 206 | Local | | | Services requiring | | 207 |Services| | | mobility, or service| | 208 +--------+ | | treatment | | 209 | | +---------------------+ | 210 | +---+ | | 211 | |NAT| | | 212 | +---+ | | 213 +-----| _----_ | | 214 +-----+ _( )_ +-----+ | 215 [MN]----| MAG |======( IP )======| LMA |---------- 216 +-----+ (_ _) +-----+ Internet 217 '----' 218 . 219 . 220 [Access Network] . [Home Network] 221 .......................................................... 223 Figure 1: IPv4 Traffic Offload Support at the MAG 225 Figure 2 explains the operational sequence of the Proxy Mobile IPv6 226 protocol signaling message exchange between the mobile access gateway 227 and the local mobility anchor for negotiating the IPv4 Traffic 228 Offload selectors. The details related to DHCP transactions, or 229 Router Advertisements on the access link are not shown here as that 230 is not the key focus of this specification. The use of IPv4 Traffic 231 Selector option in the Proxy Binding Update is for allowing the MAG 232 to request the LMA for the IPv4 Traffic Offload policy. 234 MN MAG(NAT) LMA 235 |------>| | 1. Mobile Node Attach 236 | |------->| 2. Proxy Binding Update (IPv4TS) 237 | |<-------| 3. Proxy Binding Acknowledgement (IPv4TS) 238 | |========| 4. Tunnel/Route Setup 239 | + | 5. Installing the traffic offload rules 240 |------>| | 6. IPv4 packet from mobile node 241 | + | 7. Offload rule applied (Tunnel/offload) 242 | | | 244 Figure 2: Exchange of IPv4 Traffic Offload Selectors 246 3.1. IPv4 Traffic Offload Selector Option 248 A new mobility option, IPv4 Traffic Offload Selector option, is 249 defined for using it in Proxy Binding Update (PBU) and Proxy Binding 250 Acknowledgement (PBA) messages exchanged between a mobile access 251 gateway and a local mobility anchor. This option is used for 252 carrying the IPv4 traffic offload policy. This policy identifies the 253 IPv4 traffic flow selectors that can be used by the mobile access 254 gateway for enforcing the offload policy. 256 The alignment requirement for this option is 4n. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |M| Reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Traffic Selector Sub-option ... 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 3: IPv4 Traffic Offload Selector Option 270 Type 271 273 Length 274 8-bit unsigned integer indicating the length in octets of the 275 option, excluding the type and length fields. 277 Offload Mode (M) Flag 278 This field indicates the offload mode. 280 If the (M) flag value is set to a value of (0), it is an 281 indication that the IPv4 flow(s) matching the traffic selectors 282 in the Traffic Selector sub-option [RFC6089] and that are 283 associated to that mobility session have to be offloaded at the 284 mobile access gateway. All the other IPv4 flows associated 285 with that mobility session and not matching the traffic 286 selectors have to be tunneled to the local mobility anchor. 288 If the (M) flag value is set to a value of (1), it is an 289 indication that all the IPv4 flows associated to that mobility 290 session except the IPv4 flow(s) matching the traffic selectors 291 in the Traffic Selector sub-option have to be offloaded at the 292 mobile access gateway. All the IPv4 flows associated with that 293 mobility session and matching the traffic selectors have to be 294 tunneled back to the local mobility anchor. 296 Reserved 297 This field is unused for now. The value MUST be initialized to 0 298 by the sender and MUST be ignored by the receiver. 300 Traffic Selector Sub-option 301 The traffic selector sub-option includes the parameters used to 302 match packets for a specific flow binding. This is an optional 303 sub-option when the IPv4 Traffic Selector option is carried in a 304 Proxy Binding Update message, but is a mandatory sub-option when 305 the IPv4 Traffic Selector option is carried in a Proxy Binding 306 Acknowledgement message. The format of the Traffic Selector sub- 307 option is defined in section 4.2.1.4 of [RFC6089]. This sub- 308 option includes a TS Format field, which identifies the format of 309 the flow specification included in that sub-option. The values 310 for that field are defined in section 3 of [RFC6088] and are 311 repeated here for completeness. When the value of TS Format field 312 is set to (1), the format that follows is the IPv4 Binary Traffic 313 Selector specified in section 3.1 of [RFC6088] and that support is 314 mandatory for this specification. The text specified in this 315 section takes precedence over what is specified in [RFC6088] and 316 [RFC6089]. 318 1: IPv4 binary traffic selector. 320 2: IPv6 binary traffic selector (Not used by this 321 specification) 323 3.2. MAG Considerations 325 o If the mobile access gateway is configured to support IPv4 Traffic 326 Offload support, then it includes the IPv4 Traffic Offload 327 Selector option (Section 3.1) in the Proxy Binding Update message 328 that it sends to the local mobility anchor. Optionally, the 329 mobile access gateway can also propose a specific offload policy. 331 * The mobile access gateway MAY choose not to propose any 332 specific IPv4 traffic offload policy but request the local 333 mobility anchor for the offload policy. In this scenario, the 334 IPv4 Traffic Offload Selector option that is carried in the 335 Proxy Binding Update message does not include the Traffic 336 Selector sub-option (Section 3.1) and the (M) flag Section 3.1 337 in the option MUST be set to value of (0). Including the IPv4 338 Traffic Offload Selector option in the Proxy Binding Update 339 without the Traffic Selector Sub-option serves as an indication 340 that the mobile access gateway is not proposing any specific 341 offload policy for that mobility session, but rather it makes a 342 request to the local mobility anchor to provide the offload 343 policy. 345 * The mobile access gateway MAY choose to propose a specific IPv4 346 traffic offload policy by including the Traffic Selector sub- 347 option in the IPv4 Traffic Offload Selector option Section 3.1. 348 The specific details on how the mobile access gateway obtains 349 the mobile node's IPv4 traffic offload policy, is outside the 350 scope of this document. When this offload policy is included 351 in the Proxy Binding Update message, it serves as a proposal to 352 the local mobility anchor, which the local mobility anchor can 353 override with its own offload policy, or agree to the proposed 354 policy. The offload policy has to be translated to a set of 355 selectors that can be used to match the mobile node's IP flows 356 and these selectors have to be carried in the Traffic Selector 357 Sub-option. The Traffic Selector sub-option MUST be 358 constructed as specified section 4.2.1.4 of [RFC6089]. This 359 sub-option includes a Traffic Selector Format field, which 360 identifies the format of the flow specification included in 361 that sub-option. The values for that field and the 362 corresponding message format are defined in section 3.0 of 363 [RFC6088]. Considerations from Section 3.1 apply with respect 364 to setting the Offload Mode (M) flag. 366 o When sending a Proxy Binding Update either for Binding lifetime 367 extension, or for Binding De-Registration, the mobile access 368 gateway SHOULD copy the IPv4 Traffic Offload Selector option from 369 the initial Proxy Binding Update message. Considerations from 370 section 6.9.1.3 [RFC5213] and section 6.9.1.4 [RFC5213] MUST be 371 applied. 373 o If the mobile access gateway is not configured to support IPv4 374 traffic offload support as specified in this specification, but if 375 the received Proxy Binding Acknowledgement message has the IPv4 376 Traffic Offload Selector option, then the mobile access gateway 377 MUST ignore the option and process the rest of the message as per 378 [RFC5213]. 380 o If there is no IPv4 Traffic Offload Selector option in the Proxy 381 Binding Acknowledgement message received from the local mobility 382 anchor, it is indication that the local mobility anchor did not 383 enable IPv4 Traffic Offload support for that mobility session. 384 The mobile access gateway upon accepting the Proxy Binding 385 Acknowledgement message SHOULD NOT enable IPv4 traffic offload 386 support for that mobility session. 388 o If there is an IPv4 Traffic Offload Selector option in the Proxy 389 Binding Acknowledgement message, then the mobile access gateway 390 SHOULD enable the IPv4 traffic offload support for that mobility 391 session. The mobility access gateway has to provision the data 392 plane using the flow selectors present in the Traffic Selector 393 Sub-option. The IPv4 flows matching the flow selectors have to be 394 offloaded, or tunneled back based to the local mobility anchor 395 based on the value of the Offload Mode (M) flag Section 3.1. 397 3.3. LMA Considerations 399 o If the received Proxy Binding Update message does not include the 400 IPv4 Traffic Offload Selector option (Section 3.1), then the local 401 mobility anchor MUST NOT enable IPv4 Traffic Offload support for 402 that mobility session and the Proxy Binding Acknowledgement 403 message that will be sent in response MUST NOT contain the IPv4 404 Traffic Offload Selector option. 406 o If the Proxy Binding Update message includes the IPv4 Traffic 407 Offload Selector option, but the local mobility anchor is not 408 configured to support IPv4 Traffic Offload support, then the local 409 mobility anchor will ignore the option and process the rest of the 410 message as per [RFC5213]. This would have no effect on the 411 operation of the rest of the protocol. 413 o If the Proxy Binding Update message has the IPv4 Traffic Offload 414 Selector option and if the local mobility anchor is configured to 415 support IPv4 Traffic Offload support, then the local mobility 416 anchor MUST enable IPv4 Traffic Offload support for that mobility 417 session. The Proxy Binding Acknowledgement message that will be 418 sent in response MUST include the IPv4 Traffic Offload Selector 419 option. The following considerations apply with respect to 420 constructing the IPv4 Traffic Offload Selector option. 422 * The local mobility anchor can obtain the offload policy from 423 the local configuration store, or from a network function such 424 as from AAA (Authentication, Authorization and Accounting), or 425 PCRF (Policy Charging and Rules Function)). The offload policy 426 has to be translated to a set of selectors that can be used to 427 match the mobile node's IP flows and these selectors have to be 428 carried in the Traffic Selector Sub-option. The Traffic 429 Selection Sub-option MUST be constructed as specified in 430 section 4.2.1.4 of [RFC6089]. Considerations from Section 3.1 431 apply with respect to Offload Mode Flag (M) setting. 433 * If the Proxy Binding Update message includes a specific IPv4 434 Traffic Offload policy proposal in the form of Traffic Selector 435 Sub-option [RFC6089], then the local mobility anchor MAY choose 436 to agree to that request by including the same IPv4 Traffic 437 Offload policy in the Proxy Binding Acknowledgement message. 438 This implies the local mobility anchor has agreed to the mobile 439 access gateway provided IPv4 Traffic Offload policy. The local 440 mobility anchor MAY also choose to override the request by 441 including a different IPv4 Traffic Offload policy that it wants 442 the mobile access gateway to enforce for that mobility session. 443 This is entirely based on the policy configuration on the local 444 mobility anchor. 446 * The IPv4 traffic offload policy that is sent to the mobile 447 access gateway has to be specific to the mobility session 448 identified using the Mobile Node Identifier option [RFC5213]. 449 The offload policy MUST be specific to a mobile node's 450 application traffic. The traffic selectors have to match only 451 the mobile node's application traffic and MUST NOT match any 452 other mobile node's IP traffic. Furthermore, control plane 453 traffic such as DHCP, ND or any other IP traffic that is used 454 for IP address configuration, mobility management or for other 455 control plane functions has to be excluded. 457 * The local mobility anchor MUST NOT make any changes to the 458 mobile node's offload policy during the middle of a mobility 459 session, as that might break some of the IP sessions. 460 Therefore the IPv4 Traffic Selector option with the Traffic 461 Selector sub-option that is delivered during the initial 462 mobility signaling signaling MUST be the same as the one that 463 is delivered as part of the mobility signaling related to 464 lifetime extension. 466 4. Protocol Configuration Variables 468 This specification defines the following configuration variable that 469 controls the IPv4 Traffic Offload support feature. This 470 configuration variable is internal to the system and has no bearing 471 on interoperability across different implementations. 473 The mobility entities, local mobility anchor and the mobile access 474 gateway have to allow these variables to be configured by the system 475 management. The configured values for these protocol variables have 476 to survive server reboots and service restarts. 478 EnableIPv4TrafficOffloadSupport 480 This flag indicates whether or not IPv4 Traffic Offload support 481 needs to be enabled. This configuration variable is available 482 at both in the mobile access gateway and at the local mobility 483 anchor. The default value for this flag is set to (0), 484 indicating that the support for IPv4 Traffic offload support is 485 disabled. 487 When this flag on the mobile access gateway is set to a value 488 of (1), the mobile access gateway has to enable the IPv4 489 Traffic offload support for all mobility sessions, specifically 490 request the IPv4 traffic offload policy from the local mobility 491 anchor by including the IPv4 Traffic Offload Selector option in 492 the Proxy Binding Update message. If the flag is set to a 493 value of (0), the mobile access gateway has to disable support 494 for IPv4 Traffic Offload support for all mobility sessions. 496 Similarly, when this flag on the local mobility anchor is set 497 to a value of (1), the local mobility anchor has to enable 498 support for IPv4 Traffic offload support. When the local 499 mobility anchor chooses to enable IPv4 Traffic offload support 500 and if there is offload policy specified for a mobile node, it 501 has to deliver the IPv4 traffic offload policy to the mobile 502 access gateway by including the IPv4 Traffic Offload Selector 503 option in the Proxy Binding Acknowledgement message. 505 5. IANA Considerations 507 This document requires the following IANA action. 509 o Action-1: This specification defines a new mobility option, IPv4 510 Traffic Offload Selector option. This option is described in 511 Section 3.1. The Type value for this option needs to be assigned 512 from the same numbering space as allocated for the other mobility 513 options [RFC6275]. 515 o RFC Editor: Please replace in Section 4 with the assigned 516 value, and update this section accordingly. 518 6. Security Considerations 520 The IPv4 Traffic Offload Selector option defined in this 521 specification is for use in Proxy Binding Update and Proxy Binding 522 Acknowledgement messages. This option is carried like any other 523 mobility header option as specified in [RFC5213]. Therefore it 524 inherits from [RFC5213] its security guidelines and does not require 525 any additional security considerations. Carrying IPv4 traffic 526 offload selectors does not introduce any new security 527 vulnerabilities. 529 When IPv4 traffic offload support is enabled for a mobile node, the 530 mobile access gateway selectively offloads some of the mobile node's 531 IPv4 traffic flows to the access network. Typically, these offloaded 532 flows get NAT translated and essentially that introduces certain 533 vulnerabilities which are common to any NAT deployment. These 534 vulnerabilities and the related considerations have been well 535 documented in the NAT specification [RFC2663]. There are no 536 additional considerations above and beyond what has already been 537 documented by the NAT specifications and which are unique to the 538 approach specified in this document. 540 The mobile node's home network may be equipped with firewall and 541 other security devices to guard against any security threats. When 542 IPv4 traffic offload support is enabled, it potentially exposes the 543 mobile node to some security risks in the access network. This 544 threat can be mitigated by deploying the security features in the 545 access network as in the home network. 547 When IPv4 traffic offload support is enabled for a mobile node, some 548 of the IP flows are sent through the home network and some other IP 549 flows are routed through the access network. This potentially 550 introduces some complexity with respect to enabling diagnostics or 551 monitoring on the user traffic. The tools that are used for such 552 diagnostics have to be aware of the offload policy that in enabled in 553 the network. 555 7. Acknowledgements 557 The authors would like to thank Ahmad Muhanna, Basavaraj Patil, 558 Carlos Bernardos, Eric Voit, Frank Brockners, Hidetoshi Yokota, Marco 559 Liebsch, Mark Grayson, Pierrick Seite, Ryuji Wakikawa, Steve Wood, 560 Barry Lieba, Sean Turner, Pete Resnick, Wesley Eddy, Mary Barnes, 561 Vincent Roca, Ralph Droms, Scott Bradner, Stephen Farrell, Adrian 562 Farrell, Benoit Claise and Brian Haberman for all the draft reviews 563 and discussions related to the topic of IPv4 traffic offload. 565 8. References 567 8.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 573 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 575 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 576 Mobile IPv6", RFC 5844, May 2010. 578 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 579 "Traffic Selectors for Flow Bindings", RFC 6088, 580 January 2011. 582 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 583 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 584 Network Mobility (NEMO) Basic Support", RFC 6089, 585 January 2011. 587 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 588 in IPv6", RFC 6275, July 2011. 590 8.2. Informative References 592 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 593 Translator (NAT) Terminology and Considerations", 594 RFC 2663, August 1999. 596 [RFC5101] Claise, B., "Specification of the IP Flow Information 597 Export (IPFIX) Protocol for the Exchange of IP Traffic 598 Flow Information", RFC 5101, January 2008. 600 [TS23402] 3GPP, "Architecture enhancements for non-3GPP accesses", 601 2010. 603 Authors' Addresses 605 Sri Gundavelli (editor) 606 Cisco 607 170 West Tasman Drive 608 San Jose, CA 95134 609 USA 611 Email: sgundave@cisco.com 613 Xingyue Zhou 614 ZTE Corporation 615 No.68 Zijinghua Rd 616 Nanjing 617 China 619 Email: zhou.xingyue@zte.com.cn 621 Jouni Korhonen 622 Nokia Siemens Networks 623 Linnoitustie 6 624 Espoo FIN-02600 625 Finland 627 Email: jouni.nospam@gmail.com 629 Gaetan 630 Cisco 631 France 633 Email: gfeige@cisco.com 635 Rajeev Koodli 636 Cisco 637 3650 Cisco Way 638 San Jose, CA 95134 639 USA 641 Email: rkoodli@cisco.com