idnits 2.17.00 (12 Aug 2021) /tmp/idnits14395/draft-sarikaya-aplusp-pmip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 12, 2009) is 4597 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: 'RFC2119' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'I-D.boucadair-behave-ipv6-portrange' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC5121' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netlmm-grekey-option' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mip6-hiopt' is defined on line 558, but no explicit reference was found in the text == Unused Reference: '3GPP23402' is defined on line 563, but no explicit reference was found in the text == Unused Reference: '3GPP29275' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'WiMAXnwg' is defined on line 572, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: draft-ietf-softwire-dual-stack-lite has been published as RFC 6333 == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-01 == Outdated reference: A later version (-01) exists of draft-boucadair-dhcpv6-shared-address-option-00 ** Downref: Normative reference to an Informational draft: draft-boucadair-port-range (ref. 'I-D.boucadair-port-range') == Outdated reference: draft-ymbk-aplusp has been published as RFC 6346 ** Downref: Normative reference to an Experimental draft: draft-ymbk-aplusp (ref. 'I-D.ymbk-aplusp') == Outdated reference: A later version (-04) exists of draft-boucadair-behave-ipv6-portrange-03 ** Downref: Normative reference to an Informational draft: draft-boucadair-behave-ipv6-portrange (ref. 'I-D.boucadair-behave-ipv6-portrange') == Outdated reference: draft-ietf-netlmm-pmip6-ipv4-support has been published as RFC 5844 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-netlmm-grekey-option has been published as RFC 5845 == Outdated reference: draft-ietf-mip6-hiopt has been published as RFC 6610 Summary: 7 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft F. Xia 4 Expires: April 15, 2010 Huawei USA 5 M. Boucadair 6 France Telecom 7 October 12, 2009 9 A+P for Proxy Mobile IPv6 10 draft-sarikaya-aplusp-pmip-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 15, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This memo specifies how to use IPv6 a+p technique in mobile networks 49 for Proxy Mobile IPv6 (PMIPv6). Mobile node which is a dual-stack 50 node can receive a shared IPv4 Home Address together with a port 51 range from the Local Mobility Agent (LMA). LMA is co-located with 52 Port Range Router (PRR). Mobile Access Gateway (MAG) encapsulates 53 IPv4 datagrams in IPv6 which are decapsulated at the LMA. In the 54 binding mode, LMA as PRR receives incoming IPv4 datagrams, determines 55 the routing identifier, finds the binding cache entry for this MN and 56 then encapsulates the IPv4 datagram in an IPv6 one and forwards the 57 encapsulated datagram to MN. The stateless mode is also described. 58 Mobile network could be WiMAX network or 3GPP Long Term Evolution 59 (LTE) network. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Contribution of This Memo . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Basic Port-Range-based PMIPv6 Solution . . . . . . . . . . . . 4 68 3.1. Overall Procedure . . . . . . . . . . . . . . . . . . . . 4 69 3.2. IPv4 Data Flow . . . . . . . . . . . . . . . . . . . . . . 7 70 4. IPv6 Port-Range-based Mobile IPv6 Solution: stateless mode . . 8 71 5. Extensions to Proxy Mobile IPv6 . . . . . . . . . . . . . . . 9 72 5.1. Proxy Binding Update Extensions . . . . . . . . . . . . . 9 73 5.2. Proxy Binding Acknowledgement Extensions . . . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 9.2. Informative references . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 1.1. Overall Context 86 It is commonly agreed that IPv4 address depletion is a fact. Several 87 solutions have been proposed to cope with this sensitive issue. All 88 these solutions are based on IP address sharing and differ in where 89 the IP address sharing function is enforced. 91 The first category is denoted as Port Range 92 [I-D.boucadair-port-range] or A+P solutions [I-D.ymbk-aplusp]. The 93 spirit of this category is to assign the same public IP address to 94 several customers' devices together with a Port Range. 95 Communications issued/destined to a port-restricted device can be 96 established only if the ports belong to the provisioned Port Range. 98 The second category is known as CGN (for Carrier Grade NAT). Two 99 main CGN variants can be distinguished. Double NAT, in which two 100 levels of NAT are cascaded: one in the CPE and one in the network 101 (i.e. CGN) and DS-lite [I-D.ietf-softwire-dual-stack-lite] which 102 gets rid of the CPE NAT level. DS-lite requires a Dual-Stack CPE. 103 Thus, a given CPE is assigned with an IPv6 prefix to be used for its 104 native IPv6 communications and also to encapsulate the IPv4 packets 105 into IPv6 ones between the CPE and the DS-lite CGN. 107 The main advantage of the a+p solutions compared to the CGN-based 108 ones is to avoid maintaining any session-state in the service 109 provider's realm. Hurdles related to the deployment of NAT technique 110 in the service domain and constraints to maintain various ALGs are 111 avoided. For more information about the advantage of a+p, the reader 112 should refer to [I-D.ymbk-aplusp] and/or [I-D.boucadair-port-range]. 113 When deployed in the context of mobile networks, the same IPv4 114 address can be shared by many mobile nodes but the number of source 115 ports they can use are limited. In the binding mode, Port Range 116 Router in the network keeps a binding table containing the routing 117 identifier (IPv6 address), IPv4 address and port mask. Port Range 118 Router receives all incoming datagrams for the shared IPv4 addresses 119 and searches the binding table to retrieve the routing identifier and 120 forwards the IPv4 datagram to the correct host. In the stateless 121 mode, this binding cache is not required. 123 1.2. Contribution of This Memo 125 This document presents a mobility port-range solution combining the 126 port range for Proxy Mobile IPv6 (PMIPv6, [RFC5213]). For Proxy 127 Mobile IPv6, we use the router-based architecture of DS-lite. In 128 this case MAG is the softwire initiator and it encapsulates IPv4 129 datagrams in IPv6 and sends them to the port range router which is 130 co-located with the local mobility anchor. Port range router 131 functionality replaces DS-Lite Carrier Grade NAT (CGN). Inbound 132 datagrams are received by the Port Range Router whose binding table 133 is integrated with the binding cache of LMA. LMA then searches its 134 binding cache and finds IPv6 care-of address and then encapsulates 135 the datagram and sends it to the MAG which decapsulates it and sends 136 it to MN. 138 Proxy Mobile IPv6 defines other scenarios as well in 139 [I-D.ietf-netlmm-pmip6-ipv4-support]. Scenarios such as MAG behind a 140 NAT which requires NAT traversal mechanisms. Using port range and 141 DS-lite router-based architecture, the need for these more 142 complicated operations is eliminated. 144 Proxy Mobile IPv6 is defined to provide network-based mobility 145 support without any mobility signaling from the mobile nodes. Proxy 146 Mobile IPv6 is expected to work on unmodified hosts. The solution 147 proposed below in Section 3 however requires mobile nodes to be able 148 to request port range IPv4 addresses. Mobile node modification is 149 inherent in this solution. 151 2. Terminology 153 This document uses the terminology defined in 154 [I-D.ietf-softwire-dual-stack-lite], [I-D.boucadair-port-range] and 155 [I-D.bajko-pripaddrassign], [RFC5213] and 156 [I-D.ietf-netlmm-pmip6-ipv4-support]. 158 3. Basic Port-Range-based PMIPv6 Solution 160 This section assumes that the basic Port-Range architecture as 161 defined in [I-D.boucadair-port-range] is adopted. Particularly, a 162 binding entry is required to associate an IPv4 address + Port Range 163 with an IPv6 address (or IPv6 prefix). Section 4 describes an 164 alternative in which this binding is not required. 166 3.1. Overall Procedure 168 IPv4-enabled dual-stack MN can get an IPv4 Home Address. The 169 simplest scenario is as follows: to register MN with LMA, MAG sends 170 an IPv6 Binding Update to LMA. MAG MUST include IPv4 Home Address 171 option defined in [RFC5555] extended with port range value and mask 172 in the Proxy Binding Update (PBU) and set the address to 0.0.0.0. 173 LMA assigns an IPv4 Home Address and port range and returns it in a 174 Proxy Binding Acknowledgement (PBA) using an extended IPv4 Home 175 Address option called IPv4 Home Address and Port Range (HoA-PR) 176 defined in Section 5. MN sends IPv4 datagrams to MAG. then, MAG 177 tunnels (IPv4-in-IPv6) datagrams to LMA. 179 We will describe two more scenarios for IPv4 home address 180 configuration. 182 MN MAG(DHCP-S) LMA 183 |------>| | 1. DHCPDISCOVER(OPTION-IPv4-PRA) 184 | |------->| 2. Proxy Binding Update 185 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA-PR) 186 | |========| 4. Tunnel/Route Setup 187 |<------| | 5. DHCPOFFER (OPTION-IPv4-PRA) 188 |------>| | 6. DHCPREQUEST (OPTION-IPv4-PRA) 189 |<------| | 7. DHCPACK 191 Figure 1: Mobile Node IPv4 Address Configuration - 1 193 Figure 1 illustrates the overall flow exchange to retrieve a shared 194 IPv4 address. Concretely, the experienced behaviour is as follows: 196 1. MN enters the network. MN sends DHCPDISCOVER message to DHCP 197 Proxy/Server [I-D.ietf-netlmm-pmip6-ipv4-support]. The message 198 will contain OPTION-IPv4-PRA option with the sub-opt type 199 indicating port mask (value = 1) [I-D.bajko-pripaddrassign]. 200 2. MAG registers this MN by sending a Proxy Binding Update message 201 to LMA. MAG adds IPv4 Home Address Option with port range value 202 and range and sets IPv4 Home Address field in the option to 203 0.0.0.0. 204 3. LMA assigns a shared IPv4 Home Address and a port range address 205 for this MN. LMA sends Proxy Binding Acknowledgement with IPv4 206 Address Acknowledgement and Port Range option. If MN is dual- 207 stack, LMA assigns Home Network Prefix(es) for MN and includes 208 them in the PBA. LMA creates a binding in its binding cache for 209 IPv4 HoA (and MN HNP if MN is dual-stack). In the binding cache, 210 together with IPv4 HoA, the port range and port mask MUST also be 211 included. LMA acting as Port Range Router also assigns MAG's 212 IPv6 address (Proxy-CoA) (in the source address of PBU) as the 213 binding identifier for MN. HA adds an entry containing (IPv4 214 HoA, port mask, port range, Proxy-CoA) to the binding table for 215 this MN [I-D.boucadair-port-range]. 216 4. A tunnel is established between MAG and LMA. This is DS-Lite 217 tunnel between IPv6 address of the interface of MAG towards LMA 218 and IPv6 address of the interface of LMA towards MAG. 219 5. MN receives DHCP OFFER message with the 'yiaddr' (client IP 220 address) field set to 0.0.0.0 and with OPTION-IPv4-PRA option 221 with the sub-opt type indicating port mask (value = 1). The 222 option contains the shared IPv4 address and port range and mask. 223 DHCP Proxy/Server MUST assign the IPv4 address and port range 224 received in Step 3 to the MN. 225 6. MN sends DHCP REQUEST message. MN MUST NOT include a 'Requested 226 IP Address' DHCP option (code 50) into this DHCPREQUEST and also 227 MUST NOT insert the IP address received in OPTION-IPv4-PRA into 228 the 'Requested IP Address' DHCP option (code 50). 229 7. MN receives DHCP ACK message with OPTION-IPv4-PRA. MN uses this 230 address as its IPv4 address. 232 MN MAG(DHCP-R) LMA DHCP-S 233 | |------->| | 1. Proxy Binding Update 234 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA-PR) 235 | |========| | 3. Tunnel/Route Setup 236 |------>|-------------->| 4. DHCPDISCOVER (OPTION-IPv4-PRA) via DHCP-R 237 |<------|<--------------| 5. DHCPOFFER (OPTION-IPv4-PRA) via DHCP-R 238 |------>|-------------->| 6. DHCPREQUEST (OPTION-IPv4-PRA) via DHCP-R 239 |<------|<--------------| 7. DHCPACK via DHCP-R 241 Figure 2: Mobile Node IPv4 Address Configuration - 2 243 The mobile node address configuration in Figure 2 has the following 244 steps: 246 1. MN enters the network. MAG registers this MN by sending a Proxy 247 Binding Update message to LMA. MAG adds IPv4 Home Address Option 248 with port range value and range and sets IPv4 Home Address field 249 in the option to 0.0.0.0. 250 2. LMA assigns a shared IPv4 Home Address and a port range address 251 for this MN. LMA sends Proxy Binding Acknowledgement with IPv4 252 Address Acknowledgement and Port Range Option. If MN is dual- 253 stack, LMA assigns Home Network Prefix(es) for MN and includes 254 them in the PBA. LMA creates a binding in its binding cache for 255 IPv4 HoA (and MN HNP if MN is dual-stack). In the binding cache, 256 together with IPv4 HoA, the port range and port mask MUST also be 257 included. LMA acting as Port Range Router also assigns MAG's 258 IPv6 address (Proxy-CoA) (in the source address of PBU) as the 259 binding identifier for MN. HA adds an entry containing (IPv4 260 HoA, port mask, port range, Proxy-CoA) to the binding table for 261 this MN [I-D.boucadair-port-range]. 262 3. A tunnel is established between MAG and LMA. This is DS-Lite 263 tunnel between IPv6 address of the interface of MAG towards LMA 264 and IPv6 address of the interface of LMA towards MAG. 266 4. MN sends DHCPDISCOVER message to DHCP Relay Agent 267 [I-D.ietf-netlmm-pmip6-ipv4-support]. The message will contain 268 OPTION-IPv4-PRA Option with the sub-opt type indicating port mask 269 (value = 1) [I-D.bajko-pripaddrassign]. DHCPv4 Relay sends this 270 message to DHCP server. 271 5. MN receives DHCP OFFER message with the 'yiaddr' (client IP 272 address) field set to 0.0.0.0 and with OPTION-IPv4-PRA Option 273 with the sub-opt type indicating port mask (value = 1). The 274 option contains the shared IPv4 address and port range and mask. 275 DHCP Server MUST assign the IPv4 address and port range received 276 in Step 2 to the MN. 277 6. MN sends DHCP REQUEST message. MN MUST NOT include a 'Requested 278 IP Address' DHCP option (code 50) into this DHCPREQUEST and also 279 MUST NOT insert the IP address received in OPTION-IPv4-PRA into 280 the 'Requested IP Address' DHCP option (code 50). 281 7. MN receives DHCP ACK message with OPTION-IPv4-PRA. MN uses this 282 address as its IPv4 address. 284 MN sends IPv4 datagrams to MAG. LMA tunnels these datagrams are 285 tunneled to LMA using IPv4-in-IPv6 encapsulation scheme. Internal 286 IPv4 packet's source address is IPv4 HoA. Internal IPv4 packet's 287 source port MUST be within range defined by the port range and mask 288 sent by LMA. 290 MN handoffs and gets connected to a different network. MN sends DHCP 291 RENEW message to DHCP Proxy/Server or Relay Agent which is colocated 292 with the new MAG. The new MAG sends a PBU to LMA to register this 293 move. DHCP RENEW MUST include IPv4 Home Address and Port Range 294 Options. LMA modifies the binding cache with the new Proxy-CoA for 295 this MN. LMA MUST modify the binding table by changing the binding 296 identifier for this IPv4 address and port range. 298 3.2. IPv4 Data Flow 300 Port Range Router collocated in LMA has to receive the incoming IPv4 301 datagrams for all MNs that are assigned a shared IPv4 address. This 302 can be achieved in IGP by advertizing all port shared IPv4 addresses. 304 When Port Range Router receives an IPv4 datagram it searches the 305 binding table for destination IPv4 address and port for a matching 306 entry against IPv4 HoA, port mask and port range. If an entry is 307 found then the binding identifier (Proxy-CoA) is determined. Next 308 LMA searches the binding cache for IPv4 HoA and port range to verify 309 that there is a binding cache entry for this MN. HA tunnels the 310 received IPv4 datagram to the MAG at the destination address of 311 Proxy-CoA. 313 When MN has IPv4 data to send MN always sends the datagram in IPv4 to 314 the MAG it is currently connected. MAG encapsulates IPv4 datagrams 315 in IPv6 and sends them to LMA in the MAG-LMA tunnel. LMA 316 decapsulates the datagram. LMA MUST verify the source address and 317 source port in the inner header using the tunnel header's source 318 address to find the corresponding binding cache entry. 320 4. IPv6 Port-Range-based Mobile IPv6 Solution: stateless mode 322 If the network is configured as DS-lite network 323 [I-D.ietf-softwire-dual-stack-lite] the following two implications 324 should be taken into account: 326 In the scenario in Figure 2, it is not possible for DHCPv4 Relay 327 Agent to communicate with DHCPv4 Server in IPv4. Mobile Access 328 Gateway (collocated with DHCPv4 Relay) has to encapsulate DHCPv4 329 messages in IPv6 before sending them to DHCPv4 Server. 330 Alternatively, DHCPv6 can be used to provision the shared IPv4 331 address and the Port Range as defined in 332 [I-D.boucadair-dhcpv6-shared-address-option]. 334 IPv4-enabled mobile nodes make DNS requests in IPv4. For that 335 purpose they need to be configured with the address of an IPv4 DNS 336 resolver. The DNS resolver then forwards the DNS request from the 337 mobile nodes over IPv6 to the IPv6 DNS resolver address it has 338 received over DHCPv6. DNS resolver for IPv4 must be a DNS proxy as 339 described in [I-D.ietf-softwire-dual-stack-lite]. 341 When a stateless mode is adopted, MNs are assigned with an IPv6 342 prefix which enclose the shared IPv4 address and the significant bits 343 of the Port Range. 345 For outgoing communications, the same behaviour as described in 346 Section 3.2 applies. 348 For incoming communications, the PRR does not need to maintain any 349 binding table to map the shared IPv4 address, port range and an IPv6 350 address. The PRR builds an IPv6 address using the destination IPv4 351 address and source number. The PRR MUST be configured with the 352 Pref6. The IPv4 datagram is then encapsulated in an IPv6 one and 353 sent to the aforementioned IPv6 address. The encapsulated datagram 354 is received by the MN which proceeds to a de-capsulation operation. 355 Encapsulated IPv4 datagram is then treated according to normal 356 behaviour. 358 This mode is completely stateless (except for the mobility management 359 aspects), i.e. no binding table is needed. 361 5. Extensions to Proxy Mobile IPv6 363 5.1. Proxy Binding Update Extensions 365 IPv4 Home Address Option defined in [RFC5555] is extended to also 366 carry the port range value and mask and this new option is called 367 IPv4 Home Address and Port Range Option. 369 This option is included in the mobility header, including the proxy 370 binding update message sent from the mobile access gateway to the 371 local mobility anchor. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type | Length |Prefix-len |P| Reserved | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | IPv4 Home Address | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Port Range Value | Port Range Mask | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 3: IPv4 Home Address and Port Range Option 385 Type 387 TBA1 for Type 388 Length 390 10 391 Prefix-len 393 As defined in [RFC5555] 394 P 396 As defined in [RFC5555] 397 Reserved 399 As defined in [RFC5555] 400 IPv4 home address 402 As defined in [RFC5555]. Mobile access gateway MUST set this 403 field to 0.0.0.0. 405 Port Range Value 407 16-bit field that indicates the value of the mask to be applied. 408 Mobile access gateway must set this field to all zeros. 409 Port Range Mask 411 16-bit field that indicates the position of the bits which are 412 used to build the mask. Mobile access gateway must set this field 413 to all zeros. 415 5.2. Proxy Binding Acknowledgement Extensions 417 IPv4 Home Address Acknowledgement option defined in [RFC5555] is 418 extended to also carry the port range value and mask and this new 419 option is called IPv4 Home Address and Port Range Acknowledgement 420 Option. 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Type | Length | Status |Prefix-len |Res| 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | IPv4 Home Address | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Port Range Value | Port Range Mask | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 4: IPv4 Home Address and Port Range Acknowledgement Option 434 Type 436 TBA2 for Type 437 Length 439 10 440 Prefix-len 442 As defined in [RFC5555] 443 Res 445 As defined in [RFC5555] 446 IPv4 home address 448 As defined in [RFC5555]. Local mobility anchor sets this field to 449 the value that it will use in the binding cache entry. This 450 address is a public address. 452 Port Range Value 454 16-bit field that indicates the value of the mask to be applied. 455 Local mobility anchor must set this field to a valid port range 456 value. 457 Port Range Mask 459 16-bit field that indicates the position of the bits which are 460 used to build the mask. Local mobility anchor must set this field 461 to a valid port range mask. 462 Status 464 The following values are allocated in addition to the ones defined 465 in [RFC5555]. 466 o 140 Dynamic IPv4 home address assignment with port range feature 467 not available 468 o 141 No address/port left 470 6. Security Considerations 472 TBD. 474 7. IANA Considerations 476 TBD. 478 8. Acknowledgements 480 TBD. 482 9. References 484 9.1. Normative References 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 490 June 1999. 492 [I-D.ietf-softwire-dual-stack-lite] 493 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 494 Y., and R. Bush, "Dual-stack lite broadband deployments 495 post IPv4 exhaustion", 496 draft-ietf-softwire-dual-stack-lite-01 (work in progress), 497 July 2009. 499 [I-D.bajko-pripaddrassign] 500 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 501 "Port Restricted IP Address Assignment", 502 draft-bajko-pripaddrassign-01 (work in progress), 503 March 2009. 505 [I-D.boucadair-dhcpv6-shared-address-option] 506 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 507 and G. Bajko, "Dynamic Host Configuration Protocol 508 (DHCPv6) Options for Shared IP Addresses Solutions", 509 draft-boucadair-dhcpv6-shared-address-option-00 (work in 510 progress), May 2009. 512 [I-D.boucadair-port-range] 513 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 514 "IPv4 Connectivity Access in the Context of IPv4 Address 515 Exhaustion: Port Range based IP Architecture", 516 draft-boucadair-port-range-02 (work in progress), 517 July 2009. 519 [I-D.ymbk-aplusp] 520 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 521 draft-ymbk-aplusp-04 (work in progress), July 2009. 523 [I-D.boucadair-behave-ipv6-portrange] 524 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 525 Kassi-Lahlou, M., Bajko, G., Lee, Y., and T. Melia, 526 "Flexible IPv6 Migration Scenarios in the Context of IPv4 527 Address Shortage", 528 draft-boucadair-behave-ipv6-portrange-03 (work in 529 progress), October 2009. 531 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 532 Routers", RFC 5555, June 2009. 534 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 535 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 537 [I-D.ietf-netlmm-pmip6-ipv4-support] 538 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 539 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 540 (work in progress), September 2009. 542 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 543 in IPv6", RFC 3775, June 2004. 545 9.2. Informative references 547 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 548 Madanapalli, "Transmission of IPv6 via the IPv6 549 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 550 February 2008. 552 [I-D.ietf-netlmm-grekey-option] 553 Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 554 "GRE Key Option for Proxy Mobile IPv6", 555 draft-ietf-netlmm-grekey-option-09 (work in progress), 556 May 2009. 558 [I-D.ietf-mip6-hiopt] 559 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 560 Options for Home Information Discovery in MIPv6", 561 draft-ietf-mip6-hiopt-17 (work in progress), May 2008. 563 [3GPP23402] 564 "3GPP TS 23.402. Architecture enhancements for non-3GPP 565 accesses.", June 2009. 567 [3GPP29275] 568 "3GPP TS 29.275. Proxy Mobile IPv6 (PMIPv6) based 569 Mobility and Tunnelling protocols; Stage 3", 570 September 2009. 572 [WiMAXnwg] 573 "WiMAX Forum Networking Working Group Stage 3 574 Specification Release 1.5.", March 2009. 576 Authors' Addresses 578 Behcet Sarikaya 579 Huawei USA 580 1700 Alma Dr. Suite 500 581 Plano, TX 75075 583 Phone: +1 972-509-5599 584 Email: sarikaya@ieee.org 586 Frank Xia 587 Huawei USA 588 1700 Alma Dr. Suite 500 589 Plano, TX 75075 591 Phone: +1 972-509-5599 592 Email: xiayangsong@huawei.com 594 Mohamed Boucadair 595 France Telecom 596 3, Av Francois Chateau 597 Rennes, France 35000 599 Email: mohamed.boucadair@orange-ftgroup.com