idnits 2.17.00 (12 Aug 2021) /tmp/idnits28615/draft-sarikaya-aplusp-dsmip-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 is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 8, 2009) is 4601 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 487, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netlmm-pmip6-ipv4-support' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC5121' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netlmm-grekey-option' is defined on line 557, but no explicit reference was found in the text == Unused Reference: '3GPP23402' is defined on line 568, but no explicit reference was found in the text == Unused Reference: '3GPP24303' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'WiMAXnwg' is defined on line 576, 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: 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == 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: draft-ietf-netlmm-grekey-option has been published as RFC 5845 == Outdated reference: draft-ietf-mip6-hiopt has been published as RFC 6610 Summary: 8 errors (**), 0 flaws (~~), 22 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 11, 2010 Huawei USA 5 M. Boucadair 6 France Telecom 7 October 8, 2009 9 A+P for Dual-Stack Mobile IPv6 10 draft-sarikaya-aplusp-dsmip-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 11, 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 describes how to use IPv6 Port Range transition technique 49 in mobile networks for Dual-Stack Mobile IPv6 (DSMIPv6). Using the 50 client based DSMIPv6, a mobile node (MN) which is a dual-stack node 51 can be assigned with a shared IPv4 Home Address (HA) together with a 52 port range from the home agent. HA is co-located with Port Range 53 Router (PRR). IPv4-in-IPv6 encapsulation is used to convey IPv4 54 traffic between the network and the mobile node (MN). HA, acting as 55 PRR receives incoming IPv4 datagrams and determines the routing 56 identifier (IPv6 address) to use to forward the traffic to the 57 appropriate MN among those sharing the same IPv4 address. In the 58 binding mode, HA finds the binding cache entry for this MN and then 59 encapsulates the IPv4 datagram in an IPv6 one and forwards the 60 encapsulated datagram to MN. The stateless mode is also described. 61 Within this memo, Mobile network could be WiMAX network or 3GPP Long 62 Term Evolution (LTE) network. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Contribution of This Memo . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. On Port Range Value and Port Range Mask . . . . . . . . . . . 5 71 4. Basic Port-Range-based Mobile IPv6 Solution . . . . . . . . . 6 72 4.1. Overall Procedure . . . . . . . . . . . . . . . . . . . . 6 73 4.2. IPv4 Data Flow . . . . . . . . . . . . . . . . . . . . . . 8 74 5. IPv6 Port-Range-based Mobile IPv6 Solution . . . . . . . . . . 8 75 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Extensions to DSMIPv6 . . . . . . . . . . . . . . . . . . . . 10 78 6.1. Binding Update Extensions . . . . . . . . . . . . . . . . 10 79 6.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 11 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative references . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 1.1. Overall Context 92 It is commonly agreed that IPv4 address depletion is a fact. Several 93 solutions have been proposed to cope with this sensitive issue. All 94 these solutions are based on IP address sharing and differ in where 95 the IP address sharing function is enforced. 97 The first category is denoted as Port Range 98 [I-D.boucadair-port-range] or A+P solutions [I-D.ymbk-aplusp]. The 99 spirit of this category is to assign the same public IP address to 100 several customers' devices together with a Port Range. 101 Communications issued/destined to a port-restricted device can be 102 established only if the ports belong to the provisioned Port Range. 104 The second category is known as CGN (for Carrier Grade NAT). Two 105 main CGN variants can be distinguished. Double NAT, in which two 106 levels of NAT are cascaded: one in the CPE and one in the network 107 (i.e. CGN) and DS-lite [I-D.ietf-softwire-dual-stack-lite] which 108 gets rid of the CPE NAT level. DS-lite requires a Dual-Stack CPE. 109 Thus, a given CPE is assigned with an IPv6 prefix to be used for its 110 native IPv6 communications and also to encapsulate the IPv4 packets 111 into IPv6 ones between the CPE and the DS-lite CGN. 113 The main advantage of the a+p solutions compared to the CGN-based 114 ones is to avoid maintaining any session-state in the service 115 provider's realm. Hurdles related to the deployment of NAT technique 116 in the service domain and constraints to maintain various ALGs are 117 avoided. For more information about the advantage of a+p, the reader 118 should refer to [I-D.ymbk-aplusp] and/or [I-D.boucadair-port-range]. 119 When deployed in the context of mobile networks, the same IPv4 120 address can be shared by many mobile nodes but the number of source 121 ports they can use are limited. In the binding mode, Port Range 122 Router in the network keeps a binding table containing the routing 123 identifier (IPv6 address), IPv4 address and port mask. Port Range 124 Router receives all incoming datagrams for the shared IPv4 addresses 125 and searches the binding table to retrieve the routing identifier and 126 forwards the IPv4 datagram to the correct host. In the stateless 127 mode, this binding cache is not required. 129 1.2. Contribution of This Memo 131 This document aims at assessing the validity of the a+p approach in 132 the context of Dual-Stack Mobile IPv6 (DSMIPv6 [RFC5555]). This is 133 mainly motivated by the need to avoid maintaining NAT (and therefore, 134 no need to deploy ALGs, session states in the service realm, etc.) in 135 the path to enhance the overall experienced performance (e.g., 136 latency). Mobile Nodes may or may not embed a NAT function. 138 This document presents a mobility solution combining the Port Range- 139 based architecture and Client Mobile IPv6 [RFC5555]. Both a binding 140 mode and stateless mode are described. 142 Client Mobile IPv6 defines other scenarios as well in [RFC5555]. 143 IPv4-only scenario and its variations such as mobile node behind a 144 NAT which could be located at the home router and therefore requires 145 NAT traversal mechanisms and home agent behind NAT but home agent has 146 a globally unique IPv4 address. Using Port Range-based architecture 147 solution over an IPv6-enabled network, the need for these more 148 complicated operations is eliminated. 150 2. Terminology 152 This document uses the terminology defined in 153 [I-D.ietf-softwire-dual-stack-lite], [I-D.boucadair-port-range], 154 [I-D.bajko-pripaddrassign] and [RFC5555]. 156 3. On Port Range Value and Port Range Mask 158 Devices with shared IPv4 addresses are provisioned also with a port 159 range to be used, especially the Port Mask to be applied when 160 selecting a port value as a source port. A Port Mask defines a set 161 of ports that all have in common a subset of pre-positioned bits. 162 This set of ports is also called Port Range. Two port numbers are 163 said to belong to the same Port Range if and only if, they have the 164 same Port Mask. A Port Mask is composed of a Port Range Value and a 165 Port Range Mask: 167 o The Port Range Value indicates the value of the significant bits 168 of the Port Mask. The Port Range Value is coded as follows: 169 * The significant bits may take a value of 0 or 1. 170 * All the other bits (non significant ones) are set to 0. 171 o The Port Range Mask indicates, by the bit(s) set to 1, the 172 position of the significant bits of the Port Range Value. 174 An example of port range is provided in Figure 1. Ports belonging to 175 this port range must have the first 3 bits equal to 001. The Port 176 Mask is represented as: 001xxxxxxxxxxxxx. 178 0 1 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Mask 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | | 184 | | | (3 significant bits) 185 v v v 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Value 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |0 0 1 x x x x x x x x x x x x x| Usable ports (x may take a value of 0 or 1). 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1: Example of Port Range Mask and Port Range Value 196 For more details, refer to [I-D.bajko-pripaddrassign]. 198 4. Basic Port-Range-based Mobile IPv6 Solution 200 This section assumes that the basic Port-Range architecture as 201 defined in [I-D.boucadair-port-range] is adopted. Particularly, a 202 binding entry is required to associate an IPv4 address + Port Range 203 with an IPv6 address (or IPv6 prefix). Section 5 describes an 204 alternative in which this binding is not required. 206 4.1. Overall Procedure 208 Dual-stack MN can get an IPv4 home address by sending an IPv6 Binding 209 Update (BU) to the Home Agent (HA). MN MUST include IPv4 Home 210 Address Option defined in [RFC5555] in the BU and set the address to 211 0.0.0.0. HA assigns an IPv4 Home Address together with Port Range 212 and returns it in a BA using an extended IPv4 Home Address Option 213 called IPv4 Home Address and Port Range (HoA-PR) defined in 214 Section 6. MN encapsulates all its IPv4 datagrams into IPv6 ones and 215 forwards encapsulated datagrams to HA. MN does not need to configure 216 an IPv4 care-of address as MN uses the IPv6 connectivity. 218 MN DHCP HA DHCP 219 | | | 220 |------->| | DHCPv6 Information Request 221 |<-------| | DHCPv6 Information Reply 222 |---------------->| BU 223 | |------->| DHCP DISCOVER(OPTION-IPv4-PRA) 224 | |<-------| DHCP OFFER 225 | |------->| DHCP REQUEST 226 | |<-------| DHCP ACK 227 |<----------------| BA (IPv4 HoA-PR) 229 Figure 2: Mobile Node Address Configuration 231 Figure 2 illustrates the overall flow exchange to retrieve a shared 232 IPv4 address. Concretely, the experienced behaviour is as follows: 234 1. MN enters the network. MN autoconfigures IPv6 Care-of Address 235 (e.g., 2001:0:0:1::1). MN needs to be provided with an IPv6 236 address (e.g., 2001:0:0:2::1) of the HA and an IPv6 Home Address. 237 MN sends DHCPv6 Information Request message to DHCP Proxy/Server 238 as specified in [I-D.ietf-mip6-hiopt]. 239 2. DHCP Proxy/Server sends a Reply message with IPv6 and IPv4 240 address of IPv6 HA and Home Network Prefix values for MN. 241 3. MN registers then its IPv6 CoA by sending a BU to HA. MN adds 242 IPv4 Home Address Option and sets IPv4 Home Address field in 243 HoA-PR Option to 0.0.0.0. 244 4. HA MAY send DHCP DISCOVER message to DHCPv4 server. The message 245 will contain OPTION-IPv4-PRA Option with the sub-opt type 246 indicates port mask (value = 1) [I-D.bajko-pripaddrassign]. 247 5. HA receives DHCP OFFER message with the 'yiaddr' (client IP 248 address) field set to 0.0.0.0 and with OPTION-IPv4-PRA Option. 249 The option contains the shared IPv4 address and Port Range and 250 mask. 251 6. HA sends DHCP REQUEST message. HA MUST NOT include a 'Requested 252 IP Address' DHCP Option (code 50) into this DHCPREQUEST and also 253 MUST NOT insert the IP address received in OPTION-IPv4-PRA into 254 the 'Requested IP Address' DHCP Option (code 50). 255 7. HA receives DHCP ACK message with OPTION-IPv4-PRA. HA assigns 256 the address in IPv4 address field to MN as its Home Address. 257 8. HA sends BA with IPv4 Address Acknowledgement and Port Range 258 Option. 260 HA assigns a shared IPv4 HoA to MN (a.b.c.d) and sets this value in 261 IPv4 Home Address field of BA. HA also assigns Port Range Value and 262 Port Range Mask of BA. HA creates a binding in its binding cache for 263 both MN IPv6 HoA and IPv4 HoA. In the binding cache, together with 264 HoA, the port range value and port range mask MUST also be included. 266 HA acting as Port Range Router also assigns mobile node's IPv6 267 Care-of Address (CoA) (in the source address of BU) as the binding 268 identifier for MN. HA adds an entry containing (IPv4 HoA, port range 269 mask, port range value, IPv6 CoA) to the binding table for this MN 270 [I-D.boucadair-port-range]. 272 MN sends IPv4 datagrams encapsulated in IPv6. All datagrams are 273 forwarded to HA. Internal IPv4 packet's source address is IPv4 HoA. 274 Internal IPv4 packet's source port MUST be within the Port Range sent 275 by HA to the MN. 277 MN handoffs and gets connected to a different network. MN gets 278 another IPv6 Care-of-Address, possibly using stateless address 279 configuration or using DHCPv6 [RFC3315]. MN sends a BU to HA to 280 register its new Care-of-Address. MN with a shared IPv4 Home Address 281 MUST include IPv4 Home Address and Port Range Option. MN MUST NOT 282 start transmitting datagrams before it receives a BA. 284 4.2. IPv4 Data Flow 286 Port Range Router collocated in HA has to receive the incoming IPv4 287 datagrams for all MNs that are assigned a shared IPv4 address. This 288 can be achieved in IGP by advertizing all port shared IPv4 addresses. 290 When Port Range Router receives an IPv4 datagram it searches the 291 binding table for destination IPv4 address and port for a matching 292 entry against IPv4 HoA, port range mask and port range value. If an 293 entry is found then the binding identifier (IPv6 CoA) is determined. 294 Next HA searches the binding cache for IPv6 CoA to verify that there 295 is a binding cache entry for this MN. HA tunnels the received IPv4 296 datagram to MN. 298 When MN has IPv4 data to send MN always encapsulates the datagram in 299 IPv6 and sends it to HA. HA decapsulates the datagram. HA MUST 300 verify the source address and source port in the inner header using 301 the tunnel header's source address to find the corresponding binding 302 cache entry. 304 5. IPv6 Port-Range-based Mobile IPv6 Solution 306 5.1. Overview 308 If the network is configured as DS-lite network 309 [I-D.ietf-softwire-dual-stack-lite] or as specified in 310 [I-D.boucadair-behave-ipv6-portrange] the following two implications 311 should be taken into account: 313 DSMIPv6 Home Agent does not have a DHCPv4 server to get port range 314 IPv4 addresses as depicted in Figure 2 in Steps 4-7. In this case 315 Home Agent MUST locally manage IPv4 addresses it assigns to the 316 mobile nodes. DHCPv6 can be used to provision the shared IPv4 317 address and the Port Range as defined in 318 [I-D.boucadair-dhcpv6-shared-address-option]. 320 IPv4-enabled mobile nodes make DNS requests in IPv4. For that 321 purpose they need to be configured with the address of an IPv4 DNS 322 resolver. The DNS resolver then forwards the DNS request from the 323 mobile nodes over IPv6 to the IPv6 DNS resolver address it has 324 received over DHCPv6. DNS resolver for IPv4 must be a DNS proxy as 325 described in [I-D.ietf-softwire-dual-stack-lite]. 327 5.2. Procedure 329 When a stateless mode is adopted, MNs are assigned with an IPv6 330 prefix which enclose the shared IPv4 address and the significant bits 331 of the Port Range. The format of the IPv6 prefix is as follows: 333 +------------------------+----------+---------+ 334 | Pref6 | @IPv4 | PRM | 335 +------------------------+----------+---------+ 337 Figure 3: IPv6 prefix enclosing an IPv4 address and a port range 339 1. Pref6: is a sub-prefix belonging to the service provider or well- 340 known prefix allocated by IANA for this service. The length of 341 this field is variable (may be different from a service provider 342 to another if not allocated by IANA). 343 2. @IPv4 field encloses the shared IPv4 address. The length of this 344 field is 32 bits; 345 3. PRM field includes the value of the significant bits of the Port 346 Range. The maximum length of this field is 16 bits. 348 For outgoing communications, the same behaviour as described in 349 Section 4.2 applies. 351 For incoming communications, the PRR does not need to maintain any 352 binding table to map the shared IPv4 address, port range and an IPv6 353 address. The PRR builds an IPv6 address using the destination IPv4 354 address and source number. The PRR MUST be configured with the 355 Pref6. The IPv4 datagram is then encapsulated in an IPv6 one and 356 sent to the aforementioned IPv6 address. The encapsulated datagram 357 is received by the MN which proceeds to a de-capsulation operation. 358 Encapsulated IPv4 datagram is then treated according to normal 359 behaviour. 361 This mode is completely stateless (except for the mobility management 362 aspects), i.e. no binding table is needed. 364 6. Extensions to DSMIPv6 366 6.1. Binding Update Extensions 368 IPv4 Home Address Option defined in [RFC5555] is extended to carry 369 the port range value and mask. This new option is called IPv4 Home 370 Address and Port Range Option. 372 This option is included in the mobility header, including the binding 373 update message sent from the mobile node to a home agent. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type | Length |Prefix-len |P| Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | IPv4 Home Address | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Port Range Value | Port Range Mask | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 4: IPv4 Home Address and Port Range Option 387 Type 389 TBA1 for Type 390 Length 392 10 393 Prefix-len 395 As defined in [RFC5555] 396 P 398 As defined in [RFC5555] 399 Reserved 401 As defined in [RFC5555] 403 IPv4 Home Address 405 As defined in [RFC5555]. Mobile node MUST set this field to 406 0.0.0.0. 407 Port Range Value 409 16-bit field that indicates the value of the mask to be applied. 410 Mobile node must set this field to all zeros. 411 Port Range Mask 413 16-bit field that indicates the position of the bits which are 414 used to build the mask. Mobile node must set this field to all 415 zeros. 417 6.2. Binding Acknowledgement Extensions 419 IPv4 Home Address Acknowledgement Option defined in [RFC5555] is 420 extended to also carry the Port Range Value and Port Range Mask and 421 this new option is called IPv4 Home Address and Port Range 422 Acknowledgement Option. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | Status |Prefix-len |Res| 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | IPv4 Home Address | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Port Range Value | Port Range Mask | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 5: IPv4 Home Address and Port Range Acknowledgement Option 436 Type 438 TBA2 for Type 439 Length 441 10 442 Prefix-len 444 As defined in [RFC5555] 446 Res 448 As defined in [RFC5555] 449 IPv4 Home Address 451 As defined in [RFC5555]. Home agent sets this field to the value 452 that it will use in the binding cache entry. This address is a 453 public address. 454 Port Range Value 456 16-bit field that indicates the value of the mask to be applied. 457 Home agent must set this field to a valid Port Range Value. 458 Port Range Mask 460 16-bit field that indicates the position of the bits which are 461 used to build the mask. Home agent must set this field to a valid 462 Port Range mask. 463 Status 465 The following values are allocated in addition to the ones defined 466 in [RFC5555]. 467 o 140 Dynamic IPv4 Home Address assignment with port range feature 468 not available 469 o 141 No address/port left 471 7. Security Considerations 473 This document does not by itself introduce any security issues. 475 8. IANA Considerations 477 TBD. 479 9. Acknowledgements 481 TBD. 483 10. References 485 10.1. Normative References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 491 June 1999. 493 [I-D.ietf-softwire-dual-stack-lite] 494 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 495 Y., and R. Bush, "Dual-stack lite broadband deployments 496 post IPv4 exhaustion", 497 draft-ietf-softwire-dual-stack-lite-01 (work in progress), 498 July 2009. 500 [I-D.bajko-pripaddrassign] 501 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 502 "Port Restricted IP Address Assignment", 503 draft-bajko-pripaddrassign-01 (work in progress), 504 March 2009. 506 [I-D.boucadair-dhcpv6-shared-address-option] 507 Boucadair, M., Levis, P., Grimault, J., Savolainen, T., 508 and G. Bajko, "Dynamic Host Configuration Protocol 509 (DHCPv6) Options for Shared IP Addresses Solutions", 510 draft-boucadair-dhcpv6-shared-address-option-00 (work in 511 progress), May 2009. 513 [I-D.boucadair-port-range] 514 Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, 515 "IPv4 Connectivity Access in the Context of IPv4 Address 516 Exhaustion: Port Range based IP Architecture", 517 draft-boucadair-port-range-02 (work in progress), 518 July 2009. 520 [I-D.boucadair-behave-ipv6-portrange] 521 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 522 Kassi-Lahlou, M., Bajko, G., Lee, Y., and T. Melia, 523 "Flexible IPv6 Migration Scenarios in the Context of IPv4 524 Address Shortage", 525 draft-boucadair-behave-ipv6-portrange-03 (work in 526 progress), October 2009. 528 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 529 Routers", RFC 5555, June 2009. 531 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 532 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 534 [I-D.ietf-netlmm-pmip6-ipv4-support] 535 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 536 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 537 (work in progress), September 2009. 539 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 540 in IPv6", RFC 3775, June 2004. 542 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 543 and M. Carney, "Dynamic Host Configuration Protocol for 544 IPv6 (DHCPv6)", RFC 3315, July 2003. 546 [I-D.ymbk-aplusp] 547 Bush, R., "The A+P Approach to the IPv4 Address Shortage", 548 draft-ymbk-aplusp-04 (work in progress), July 2009. 550 10.2. Informative references 552 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 553 Madanapalli, "Transmission of IPv6 via the IPv6 554 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 555 February 2008. 557 [I-D.ietf-netlmm-grekey-option] 558 Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 559 "GRE Key Option for Proxy Mobile IPv6", 560 draft-ietf-netlmm-grekey-option-09 (work in progress), 561 May 2009. 563 [I-D.ietf-mip6-hiopt] 564 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 565 Options for Home Information Discovery in MIPv6", 566 draft-ietf-mip6-hiopt-17 (work in progress), May 2008. 568 [3GPP23402] 569 "3GPP TS 23.402. Architecture enhancements for non-3GPP 570 accesses.", June 2009. 572 [3GPP24303] 573 "3GPP TS 24.303. Mobility Management Using Dual-Stack 574 Mobile IPv6.", March 2009. 576 [WiMAXnwg] 577 "WiMAX Forum Networking Working Group Stage 3 578 Specification Release 1.5.", March 2009. 580 Authors' Addresses 582 Behcet Sarikaya 583 Huawei USA 584 1700 Alma Dr. Suite 500 585 Plano, TX 75075 587 Phone: +1 972-509-5599 588 Email: sarikaya@ieee.org 590 Frank Xia 591 Huawei USA 592 1700 Alma Dr. Suite 500 593 Plano, TX 75075 595 Phone: +1 972-509-5599 596 Email: xiayangsong@huawei.com 598 Mohamed Boucadair 599 France Telecom 600 3, Av Francois Chateau 601 Rennes, France 35000 603 Email: mohamed.boucadair@orange-ftgroup.com