idnits 2.17.1 draft-rpcw-pcp-pmipv6-serv-discovery-03.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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 14, 2013) is 3880 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) == Unused Reference: 'I-D.penno-pcp-nested-nat' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 501, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-08 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-04 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track R. Chandrasekaran 5 Expires: February 15, 2014 D. Wing 6 Cisco 7 August 14, 2013 9 PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6 10 draft-rpcw-pcp-pmipv6-serv-discovery-03 12 Abstract 14 This document proposes a solution to PCP Server Discovery problems in 15 Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic 16 and traffic off-loaded to local access network require traversing a 17 gateway implementing NAT and/or Firewall. This draft proposes 18 enhancements to DHCPv4 Relay Agent by introducing a new sub-option 19 under DHCPv4 Relay Option and to PMIPv6 signaling through additional 20 options to Proxy Binding Update/Acknowledgement messages. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 15, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Solution overview . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . 6 60 5. DHCPv4 Relay Agent co-located with MAG . . . . . . . . . . . 7 61 5.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5.2. Relay Agent behavior . . . . . . . . . . . . . . . . . . 9 63 5.3. DHCPv4 Server behavior . . . . . . . . . . . . . . . . . 9 64 6. DHCPv4 Server co-located with MAG . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 68 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 11 69 10.1. Changes from draft-rpcw-pcp-pmipv6-serv-discovery-01 to 70 -02 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.2. Changes from draft-rpcw-pcp-pmipv6-serv-discovery-02 to 72 -03 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 11.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 Given the exponential growth in the mobile data traffic, Mobile 81 Operators are looking for ways to offload some of the IP traffic 82 flows at the nearest access edge that has an Internet peering point. 83 This approach results in efficient usage of the mobile packet core 84 and helps lower the transport cost. [RFC6909] defines a mechanism 85 for Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) 86 to negotiate Ipv4 traffic offload policy for mobility sessions in 87 Proxy Mobile IP Networks. There are scenarios in PMIPv6 Mobile 88 Networks where the traffic going through the Mobile Packet Core as 89 well as the traffic that is off-loaded to the Local Access Networks 90 end up going through a NAT or Firewall gateway. If the mobile node 91 applications desire to find or control the external addresses 92 assigned to the internal address used by the Mobile Node (MN), it 93 could be achieved by having a Port Control Protocol (PCP) Client on 94 the mobile node. 96 [I-D.ietf-pcp-dhcp] specifies DHCP (IPv4 and IPv6) options to 97 communicate Port Control Protocol (PCP) Server addresses to hosts. 98 However, PCP Client on the mobile node will not know whether a flow 99 will traverse the Mobile Packet Core or will get offloaded at the 100 local access network and hence will not know which PCP server to send 101 its queries to. Even if the mobile node tries to find its PCP server 102 using DHCP, it may only find out about the PCP server in the Home 103 Network since the source of information is the DHCP server in the 104 Home Network. The mobile node may never learn the presence of the 105 PCP server in the Local Access Network. This requires mobile access 106 gateway to act as a PCP Proxy for the PCP server in the mobile node's 107 home network and as a PCP server/PCP Proxy for the NAT that the 108 offloaded traffic at the Local Access Network have to traverse 109 through. However, this alone does not solve this problem since the 110 mobile node needs to be informed of the PCP proxy on the MAG. This 111 draft proposes an extension to DHCPv4 Relay Information Option and 112 PMIPv6 Options to achieve these objectives. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 All the mobility related terms used in this document are to be 121 interpreted as defined in the Proxy Mobile IPv6 specifications 122 [RFC5213], [RFC5844]. This note also uses terminology defined in 123 [RFC6887]. 125 Additionally, this document uses the following abbreviations: 127 o IP Flow - IP Flow represents a set of IP packets that match a 128 traffic selector. The selector is typically based on the source 129 IP address, destination IP address, source port, destination port 130 and other fields in upper layer headers. 132 o IP Traffic Offload - The approach of selecting specific IP flows 133 and routing them to the local network, as supposed to tunneling 134 them to the home network. 136 o NAT (Network Address Translation) - Network Address Translation 137 [RFC2663] is a method by which IP addresses are mapped from one 138 address realm to another, providing transparent routing to end 139 hosts. 141 o Firewall (FW) - A packet filtering device that matches packets 142 against a set of policy rules and applies the actions. 144 o peer-to-peer (P2P) - Applications and protocols, such as 145 teleconferencing, multiplayer online gaming, BitTorrent etc 147 o Internal Address - The address of Mobile Node assigned by the home 148 agent. 150 o Remote Peer IP Address - The address of a Remote Peer, as seen by 151 the Mobile Node. A Remote Address is generally a publicly 152 routable address. 154 o External Address - The address of the Mobile Node as seen by other 155 Remote Peers on the Internet with which the Mobile Node is 156 communicating, after translation by any NAT gateways on the path. 158 3. Solution overview 160 The following illustrates a scenario where the Mobile Node is a PCP 161 client, Mobile Access Gateway in the access network is a PCP server 162 with PCP proxy functionality [I-D.ietf-pcp-proxy], the home network 163 has a PCP server. 165 Mobile access gateway has the ability to offload some of the IPv4 166 traffic flows based on the traffic selectors it receives from the 167 local mobility anchor. Using IPv4 Traffic Offload Selector option 168 [RFC6909] mobile access gateway will negotiate IP Flows that can be 169 offloaded to the local access network or internet. For example, 170 consider a mobile node acting as both client and server for FTP, VoIP 171 and P2P. In this case FTP flows for that mobility session may be 172 offloaded at the mobile access gateway and P2P, Voice over IP (VoIP) 173 flows tunneled back to the local mobility anchor. Mobile node uses 174 PCP to create mappings between external IP address/port and internal 175 IP address/port. These mappings will be used for successful inbound 176 communication destined to the mobile node behind NAT and/or firewall. 178 The mobile node learns the PCP server IP addresses from DHCPv4 server 179 using DHCPv4 option OPTION_PCP_SERVER [I-D.ietf-pcp-dhcp]. If IP 180 Flows are offloaded at the mobile access gateway then the mobile node 181 needs to learn the IP address of the mobile access gateway acting as 182 PCP proxy. Mobile access gateway will compare the Remote Peer IP 183 Address and Port fields set in PCP PEER request from the mobile node 184 with the Traffic Selector fields and IP Traffic Offload Mode Flag in 185 IP Traffic Offload Selector Option to determine if the dynamic 186 outbound mapping is to be created in the local access network or home 187 network. In case of PCP MAP request mobile access gateway will 188 compare the Remote Peer IP Address and Port fields in FILTER Option 189 with the Traffic Selector fields and IP Traffic Offload Mode Flag in 190 IP Traffic Offload Selector Option to determine if dynamic outbound 191 mapping is to be created in the local access network or home network. 193 For PCP MAP request without FILTER option since the Remote Peer IP 194 Address is not available the mobile access gateway will function as a 195 PCP proxy and forward the PCP MAP request to the PCP server in the 196 home network. Mobile Nodes which require communication with well 197 known peers (For e.g. applications like SIP proxy, FTP server) will 198 use PCP MAP with FILTER option. When MNs act as servers (such as P2P 199 server, Web Server) i.e., when the remote peer IP address is not 200 known, PCP client will use PCP MAP request in which case the MAG 201 cannot make a decision as per the traffic selector fields and hence 202 will relay the request to a PCP server based on local configuration. 204 If the dynamic outbound mapping is for Internet Offload, then the 205 mobile access gateway will function as a PCP server for the mobile 206 node if the NAT is co-located on the MAG. If the NAT is not co- 207 located, then MAG will act as a proxy and forward the PCP requests to 208 the respective PCP server in the Local Access Network. 210 NAT may not always be required for traffic offloaded for local 211 access. If there is NAT required for traffic offloaded for Local 212 Access, then, the dynamic outbound mapping is for the Local Access 213 Network. In this case, the Mobile Access Gateway will function as a 214 PCP server if NAT device for the Local Access Network is co-located 215 on the MAG, otherwise, it will act as a PCP proxy forwarding the PCP 216 requests to the respective PCP server on the Local Access Network. 218 If dynamic outbound mapping is for the home network then mobile 219 access gateway will function as PCP proxy and forward the accepted 220 PCP requests to the PCP server in the home network. 222 _----_ 223 _( )_ 224 :-----------------( Internet )---------------: 225 | (_ _) | 226 | '----' | 227 | | 228 : | 229 (IPv4 Traffic Offload Point) | 230 : | 231 | | 232 ........................................................|.... 233 | | | 234 +--------+ | +---------------------+ | 235 | Local | | | Services requiring | | 236 |Services| | | mobility, or service| | 237 +--------+ | | treatment | | 238 | | +---------------------+ | 239 | +---+ | | 240 | |NAT| | | 241 | +---+ | | 242 +-----| _----_ | | 243 +-----+ _( )_ +-----+ | 244 [MN]----| MAG |======( IP )======| LMA |---------- 245 +-----+ (_ _) +-----+ Internet 246 '----' 247 . 248 . 249 [Access Network] . [Home Network] 250 .......................................................... 252 Figure 1: PCP-Enabled Proxy Mobile IPv6 254 4. Mobility Options 256 A new mobility option, Capability Exchange Option is defined for use 257 with Proxy Binding Update sent by the mobile access gateway to the 258 local mobility anchor. The option is used for conveying device 259 capabilities such as PCP Server, PCP Proxy. 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | Reserved (R) |S|P| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2: Capability Exchange Option 269 Type: 271 Length: An 8-bit unsigned integer indicating the length of the 272 option in octets, excluding the Type and Length fields. This 273 field MUST be set to 2. 275 Reserved (R): This 14-bit field is unused for now. The value MUST 276 be initialized to (0) by the sender and MUST be ignored by the 277 receiver. 279 PCP Server Support Mode (S): A 1-bit field that specifies the PCP 280 server support mode. The flag value of (1) indicates that mobile 281 access gateway is capable of functioning as PCP Server to the 282 Mobile node. 284 PCP Proxy Mode (P): A 1-bit field that specifies PCP proxy support 285 mode. The flag value of (1) indicates that mobile access gateway 286 is capable of functioning as PCP Proxy to the Mobile node. 288 A new mobility option, PCP Server Option is defined for use with 289 Proxy Binding Acknowledgement sent by the local mobility anchor to 290 the mobile access gateway . The option is used to provide the IP 291 address of PCP server in the home network to the mobile access 292 gateway. If there are more than one IP address associated with a PCP 293 server, all the IP addresses will be listed in the option. If there 294 are multiple PCP servers, there will be multiple instances of this 295 PCP server option each corresponding to a PCP server. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | Reserved (R) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | PCP Server IP address | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | PCP Server IP address | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 ... 308 Figure 3: PCP Server Option 310 Type: 312 Length: An 8-bit unsigned integer indicating the length of the 313 option in octets, excluding the Type, Length and Reserved fields. 314 This should be a multiple of 4. 316 Reserved (R): This 16-bit field is unused for now. 318 PCP Server IP address: The IP address of the PCP Server to be used 319 by the mobile access gateway. 321 5. DHCPv4 Relay Agent co-located with MAG 322 When DHCPv4 Relay Agent is co-located with the mobile access gateway, 323 the proposal is for the relay agent to influence the DHCPv4 Server to 324 opt for the PCP server address proposed by the Relay Agent over the 325 one configured on the DHCPv4 Server. The DHCPv4 Relay Agent will 326 insert a a new suboption under relay agent information option 327 indicating the IP address of the appropriate PCP server/proxy only 328 after successful Tunnel/Route setup. For this to happen, the MN MUST 329 ensure that it includes OPTION_PCP_SERVER in the Parameter Request 330 List Option in the DHCPv4 Discover/Request message. The mobile 331 access gateway will also have to act as a PCP-Proxy in this case so 332 that it can handle PCP Servers of both the local access network and 333 the home network. This will ensure that the right PCP Server is 334 picked by the proxy based on IP Flow. 336 MN MAG(DHCP-R) LMA DHCP-S 337 |------>| | | 1. Mobile Node Attach 338 | |------->| | 2. Proxy Binding Update 339 | |<-------| | 3. Proxy Binding Acknowledgement 340 | | | | (IPTS Option) 341 | |========| | 4. Tunnel/Route Setup 342 | + | | 5. Installing the traffic offload rules 343 |<----->|<----------->| 6. DHCP OFFER/REQUEST/ACK exchange 344 | | | | OPTION_PCP_SERVER inserted by DHCP-R 345 |------>| | | 7. IPv4 packet from mobile node 346 | + | | 8. Forwarding rule - Tunnel home/offload 347 | | | | 349 5.1. Format 351 To realize the mechanism described above, the document proposes a new 352 PCP Server suboption for the DHCPv4 relay agent information option 353 that carries the IP address of PCP Server/Proxy. If a PCP server is 354 associated with more than one IP address, all those IP addresses can 355 be listed as part of this option. If there is more than one PCP 356 server, there will be multiple instances of this option each 357 corresponding to a PCP server. 359 Code Length PCP IP address 360 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 361 | TBA | n | a1 | a2 | a3 | a4 | a1 | a2 | a3 | a4 | ... 362 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 364 Code: TBA 365 Length: Includes the length of the "PCP Server IP address" field in 366 octets; The maximum length is 255 octets. The length should be 367 multiple of 4. 369 PCP Server IP address: The IP address of the PCP Server to be used 370 by the PCP Client when issuing PCP messages. 372 5.2. Relay Agent behavior 374 DHCPv4 relay agents MAY be configured to include a PCP Server 375 suboption if they include a relay agent information option in relayed 376 DHCPv4 messages. The PCP Server IP address is determined through 377 mechanisms that are outside the scope of this memo. 379 5.3. DHCPv4 Server behavior 381 This suboption provides additional information to the DHCP server. 382 Upon receiving a DHCPv4 Discover/Request containing the suboption, 383 the DHCPv4 server, if configured to support this suboption, MUST 384 populate the DHCPv4 Offer/Ack with the suggested PCP server IP 385 address overriding any other PCP server IP address configuration that 386 it may already have. There is no special additional processing for 387 this suboption. 389 6. DHCPv4 Server co-located with MAG 391 When the DHCPv4 Server is co-located with the mobile access gateway, 392 the DHCPv4 Server will have to provide the appropriate PCP server IP 393 address in the DHCP Offer/Ack based on traffic offload negotiation 394 between the mobile access gateway and local mobility anchor. 396 If traffic offload is successfully negotiated between the mobile 397 access gateway and the local mobility anchor, the proposal is for the 398 DHCPv4 Server to include the IP address of the PCP Proxy (MAG) in the 399 DHCP Offer/Ack. The mobile access gateway will act as a PCP-Proxy in 400 this case to ensure that it can handle PCP Servers of both the local 401 access network and the home network. This will ensure that the right 402 PCP Server is picked by the proxy based on IP Flows. 404 If traffic offload is not negotiated between the mobile access 405 gateway and the local mobility anchor, the proposal is for the DHCPv4 406 Server to include the IP address of the home network PCP server in 407 the DHCPv4 Offer/Ack. The IP address of the PCP server in the home 408 network is obtained from Proxy Binding message exchange explained in 409 Section 4. Option OPTION_PCP_SERVER will be used as described in 410 [I-D.ietf-pcp-dhcp]. 412 MN MAG(DHCP-S) LMA 413 |------>| | 1. Mobile Node Attach 414 | |------->| 2. Proxy Binding Update 415 | |<-------| 3. Proxy Binding Acknowledgement 416 | | | (IPTS Option) 417 | |========| 4. Tunnel/Route Setup 418 | + | 5. Installing the traffic offload rules 419 |<----->| | 6. DHCP OFFER/REQUEST/ACK exchange 420 | | | OPTION_PCP_SERVER inserted by DHCP-S 421 |------>| | 7. IPv4 packet from mobile node 422 | + | 8. Forwarding rule - Tunnel home/offload 423 | | | 425 7. Security Considerations 427 The Capability Exchange option defined in this specification is for 428 use in Proxy Binding Update messages. The PCP server option defined 429 in this specification is for the Proxy Binding Acknowledgement 430 messages. These options are carried like any other mobility header 431 option as specified in [RFC5213] and does not require any special 432 security considerations. When IPv4 traffic offload support is 433 enabled for a mobile node, the mobile access gateway selectively 434 offloads some of the mobile node's traffic flows to the local access 435 network. Typically, these offloaded flows go through a NAT gateway 436 and that essentially introduces certain vulnerabilities which are 437 common to any NAT deployment. These vulnerabilities and the related 438 considerations have been well documented in the NAT specification 439 [RFC2663]. There are no additional considerations above and beyond 440 what is already documented by the NAT specifications and which are 441 unique to the approach specified in this document. 443 The security considerations in [RFC6887] , [I-D.ietf-pcp-proxy] and 444 section 5 of [RFC3046] also apply to this use. 446 8. IANA Considerations 448 This specification defines two new Mobility Header options - 449 Capability Exchange option, PCP server option. These options are 450 described in Section 4. The Type value for this option needs to be 451 assigned from the same numbering space as allocated for the other 452 mobility options [RFC6275]. 454 IANA is requested to assign a suboption number for the PCP Server 455 Suboption from the DHCP Relay Agent Information Option [RFC3046] 456 suboption number space. 458 9. Acknowledgements 460 The authors would like to thank Sri Gundavelli and Gang Chen for 461 their valuable comments. 463 10. Change History 465 [Note to RFC Editor: Please remove this section prior to 466 publication.] 468 10.1. Changes from draft-rpcw-pcp-pmipv6-serv-discovery-01 to -02 470 Updated Section 1, Section 3, Section4, Section 5, and Section 6. 472 10.2. Changes from draft-rpcw-pcp-pmipv6-serv-discovery-02 to -03 474 Updated Section 1, Section 3, Section4, Section 5, and Section 6. 476 11. References 478 11.1. Normative References 480 [I-D.ietf-pcp-dhcp] 481 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 482 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-08 483 (work in progress), August 2013. 485 [I-D.ietf-pcp-proxy] 486 Boucadair, M., Penno, R., and D. Wing, "Port Control 487 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-04 488 (work in progress), July 2013. 490 [I-D.penno-pcp-nested-nat] 491 Penno, R., Wing, D., and M. Boucadair, "PCP Support for 492 Nested NAT Environments", draft-penno-pcp-nested-nat-03 493 (work in progress), January 2013. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, March 1997. 498 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 499 3046, January 2001. 501 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 502 and M. Carney, "Dynamic Host Configuration Protocol for 503 IPv6 (DHCPv6)", RFC 3315, July 2003. 505 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 506 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 508 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 509 Mobile IPv6", RFC 5844, May 2010. 511 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 512 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 513 2013. 515 [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. 516 Koodli, "IPv4 Traffic Offload Selector Option for Proxy 517 Mobile IPv6", RFC 6909, April 2013. 519 11.2. Informative References 521 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 522 Translator (NAT) Terminology and Considerations", RFC 523 2663, August 1999. 525 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 526 in IPv6", RFC 6275, July 2011. 528 Authors' Addresses 530 Tirumaleswar Reddy 531 Cisco Systems, Inc. 532 Cessna Business Park, Varthur Hobli 533 Sarjapur Marathalli Outer Ring Road 534 Bangalore, Karnataka 560103 535 India 537 Email: tireddy@cisco.com 539 Prashanth Patil 540 Cisco Systems, Inc. 541 Cessna Business Park, Varthur Hobli 542 Sarjapur Marthalli Outer Ring Road 543 Bangalore, Karnataka 560103 544 India 546 Email: praspati@cisco.com 547 Ravikumar Chandrasekaran 548 Cisco Systems, Inc. 549 Cessna Business Park, Varthur Hobli 550 Sarjapur Marthalli Outer Ring Road 551 Bangalore, Karnataka 560103 552 India 554 Email: sravikum@cisco.com 556 Dan Wing 557 Cisco Systems, Inc. 558 170 West Tasman Drive 559 San Jose, California 95134 560 USA 562 Email: dwing@cisco.com