idnits 2.17.1 draft-boucadair-dhcpv6-shared-address-option-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 17 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-behave-address-format]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 21, 2009) is 5239 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 normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-04) exists of draft-bajko-pripaddrassign-02 == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-03 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-02 == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-03 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft P. Levis 4 Intended status: Standards Track J-L. Grimault 5 Expires: June 24, 2010 France Telecom 6 T. Savolainen 7 G. Bajko 8 Nokia 9 December 21, 2009 11 Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP 12 Addresses Solutions 13 draft-boucadair-dhcpv6-shared-address-option-01 15 Abstract 17 This memo defines Dynamic Host Configuration Protocol version 6 18 (DHCPv6) Options to be used in the context of shared IP address 19 solutions. In some deployment scenarios, DHCP (IPv4) cannot be used 20 to configure customer devices because only IPv6 capabilities are 21 deployed (e.g., DS-lite context or IPv6 Port Range). Therefore, 22 DHCPv6 may be used to convey IPv4-related configuration information 23 such as Port Range and/or Port Extended IPv4 addresses. This 24 document defines also a DHCPv6 Option aiming to convey the IPv6 25 prefix to be used to build IPv4 Embedded IPv6 addresses 26 [I-D.ietf-behave-address-format]. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on June 24, 2010. 56 Copyright Notice 58 Copyright (c) 2009 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 2. IPv4 Address Option . . . . . . . . . . . . . . . . . . . . . 5 87 3. Port Extended IPv4 Address DHCPv6 Option . . . . . . . . . . . 5 88 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6 89 3.2. Port Range Sub-Option . . . . . . . . . . . . . . . . . . 7 90 3.3. Delegated Random Port Range Sub-Option . . . . . . . . . . 8 91 4. IPv4-Embedded IPv6 Address Format Option . . . . . . . . . . . 9 92 5. Supported IPv4-Embedded IPv6 Address Formats Option . . . . . 12 93 6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 100 Appendix A. Port Mask Example . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 103 1. Introduction 105 Within the context of IPv4 address depletion, several solutions have 106 been submitted to the IETF to propose viable alternatives to double 107 NAT [I-D.nishitani-cgn]. Examples of these solutions are 108 [I-D.ietf-softwire-dual-stack-lite] and 109 [I-D.boucadair-behave-ipv6-portrange]. These solutions propose to 110 share a given global IPv4 address between several customers. These 111 solutions differ in the way they behave and particularly on the 112 location of the NAT function. In 113 [I-D.boucadair-behave-ipv6-portrange] the NAT function stays at the 114 CPE level and none lies in the network whilst in 115 [I-D.ietf-softwire-dual-stack-lite] the NAT function is located in 116 the network -in the DS-lite node- while the NAT in the CPE can be 117 deactivated. Nevertheless, [I-D.ietf-softwire-dual-stack-lite] 118 supports the Extended Port IP address logic mainly for the 119 enforcement of port forwarding service for instance. Therefore, 120 dedicated means such as [I-D.bajko-pripaddrassign] are required for 121 the provisioning of pertinent information to constrain the source 122 port number. [I-D.bajko-pripaddrassign] specifications may be used 123 when IPv4-enabled DHCP servers are deployed and corresponding DHCP 124 clients enabled in customer devices, such as the CPE. 126 Furthermore, both [I-D.ietf-softwire-dual-stack-lite] and 127 [I-D.boucadair-behave-ipv6-portrange] assume that only IPv6 transfer 128 capabilities are activated on the link connecting the customer's 129 device to the access network. IPv4-in-IPv6 tunneling capabilities 130 can be put in place to allow DHCP exchanges and therefore 131 [I-D.bajko-pripaddrassign] can be used to provision the customer 132 device. Nevertheless, in environments where no IPv4-enabled DHCP 133 servers are maintained or no tunneling means are deployed to reach 134 DHCP servers, alternative means to provision the customer's device 135 are required. This memo is an effort to meet this requirement. 137 Note that [I-D.dhankins-softwire-tunnel-option] can be used to 138 provide the customer device with the IPv6 address of a DS-lite CGN or 139 a PRR (Port Range Router) node. 141 Concretely, this document defines the following new DHCPv6 Options 142 [RFC3315]: 144 1. IPv4 address: This option is used to convey a "full" IPv4 145 address. 147 2. Port Extended IPv4 Address: This option carries an IPv4 address 148 to be used in conjunction with an allocated Port Range. In case 149 of Port Range allocation, several customers are assigned with the 150 same IPv4 Address. This option defines the allowed port values 151 to be used as source port number. This option is completely 152 independent of the IPv4 address Option above. 154 3. IPv4-embedded IPv6 address Format: This option is used to provide 155 the device with the prefix to be used to build an IPv4-embedded 156 IPv6 address, see for intance [I-D.ietf-behave-address-format]. 158 4. Supported IPv4-embedded IPv6 address Formats: This option allows 159 a DHCPv6 client to indicate the type of IPv4-embedded IPv6 160 address format(s) it can handle. 162 2. IPv4 Address Option 164 This DHCPv6 Option carries an IPv4 address. The DHCPv6 Option has 165 the format shown in Figure 1 : 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | OPTION_IPV4_A | option-length | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | IP Address (IPv4 Address) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | preferred-lifetime | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | valid-lifetime | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 1: IPv4 Address DHCPv6 Option 180 - option-code: OPTION_IPV4_A (To be assigned by IANA) 182 - option-length: 12. 184 - preferred-lifetime: The preferred lifetime for the IPv4 address 185 in the option, expressed in units of seconds. 187 - valid-lifetime: The valid lifetime for the IPv4 address in the 188 option, expressed in units of seconds. 190 3. Port Extended IPv4 Address DHCPv6 Option 191 3.1. Option Format 193 The Port Extended IPv4 address DHCPv6 Option is used to specify a 194 shared IPv4 address together with one range of ports (contiguous or 195 not). 197 The format of the Port Extended IPv4 address Option is provided in 198 Figure 2. 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | OPTION_PORT_EXTENDED_A | option-length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | sub-option-code | sub-option-len | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | sub-option-content | 207 . . 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | ... | 210 . . 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | ... | 213 . . 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | preferred-lifetime | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | valid-lifetime | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 2: Port Extended IPv4 Address DHCPv6 Option 222 - option-code: OPTION_PORT_EXTENDED_A (To be assigned by IANA) 224 - option-length: the length of enclosed sub-option(s) + 4. 226 - sub-option code: specifies the code of the included sub-options. 227 Two sub-codes are defined in this document: SUB_OPTION_PORT_MASK 228 and SUB_OPTION_DELG_RAND. 230 - sub-option-len: length of the sub-option. 232 - sub-option-content: content of the sub-option 233 - preferred-lifetime: The preferred lifetime for the Port Extended 234 IPv4 address in the option, expressed in units of seconds. 236 - valid-lifetime: The valid lifetime for the Port Extended IPv4 237 address in the option, expressed in units of seconds. 239 3.2. Port Range Sub-Option 241 Figure 3 provides an overview of the Port Range sub-option. 243 This sub-option is used to notify a remote peer about an IPv4 address 244 to be used in conjunction with an allocated Port Range. The Port 245 Range is allocated on the form of a Port Mask to be applied when 246 selecting a port value as a source port. The Port Range Sub Option 247 is used to infer a set of allowed port values. A Port Mask defines a 248 set of ports that all have in common a subset of pre-positioned bits. 249 This set of ports is also called Port Range. 251 A Port Mask is composed of a Port Range Value and a Port Range Mask. 253 o The Port Range Value indicates the value of the significant bits 254 of the Port Mask. The Port Range Value is encoded as follows: 256 * The significant bits may take a value of 0 or 1. 258 * All the other bits (non significant ones) are set to 0. 260 o The Port Range Mask indicates, by the bit(s) set to 1, the 261 position of the significant bits of the Port Range Value. 263 This DHCPv6 Sub Option provides a way to negotiate the port range to 264 be allocated to the peer. 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | SUB_OPTION_PORT_MASK | sub-option-len | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Port Extended IP Address (IPv4 Address) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Port Range Value | Port Range Mask | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 3: Port Range Sub Option 277 - sub-option-code: SUB_OPTION_PORT_MASK (To be assigned by IANA) 279 - sub-option-len: 8. 281 - Port Extended IP Address: specifies the shared IPv4 address 283 - Port Range Value (PRV) (16 bits): PRV indicates the value of the 284 significant bits of the Port Mask. 286 - Port Range Mask (PRM) (16 bits): The Port Range Mask indicates, 287 by the bit(s) set to 1, the position of the significant bits of 288 the Port Range Value. 290 An example of Port Range Mask is provided in Appendix A. 292 3.3. Delegated Random Port Range Sub-Option 294 Figure 4 provides an overview of the delegated random Port Range: 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | SUB_OPTION_DELG_RAND | sub-option-len | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Port Extended IP Address (IPv4 Address) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | function | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | starting point | number of delegated ports | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | key K (128 bits) | 307 | | 308 | | 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Figure 4: Delegated Random Port Option 314 - sub-option-code: SUB_OPTION_DELG_RAND (To be assigned by IANA) 316 - sub-option-len: 28. 318 - Port Extended IP Address: specifies the shared IPv4 address 320 - Function: A 32 bit field whose value is associated with 321 predefined encryption functions. For more information about this 322 function, refer to [I-D.bajko-pripaddrassign]. 324 - starting point: A 16 bit value used as an input to the specified 325 function. 327 - Number of delegated ports: A 16bit value specifying the number 328 of ports delegated to the client for use as source port values. 330 - Key K: A 128 bit key used as input to the predefined function 331 for delegated port calculation. 333 4. IPv4-Embedded IPv6 Address Format Option 335 [I-D.boucadair-behave-ipv6-portrange] defines a Port Range solution 336 which assumes IPv6-only network for the delivery of both IPv4 and 337 IPv6 connectivity services. The solution is based on IPv4-in-IPv6 338 encapsulation for the transport of IPv4 datagrams inside an IPv6-only 339 network. For these reasons, an IPv6 prefix is required to build 340 destination IPv4-embedded IPv6 addresses of IPv4-in-IPv6 encapsulated 341 datagrams issued by a port-restricted device. 342 [I-D.ietf-behave-address-format] specifies the format of IPv4 343 Embedded IPv6 address. 345 Figure 5 provides an example of a structure of an IPv4-embedded IPv6 346 address where "Pref6" is a well-known IPv6 prefix: 348 +----------------------------------------------------------------------...+ 349 | Pref6 |Dest. IPv4 |Dest. | 0:0:0:0 | 350 | |address |port | | 351 +----------------------------------------------------------------------...+ 353 Figure 5: Example of IPv4-Embedded IPv6 Address 355 The IPv4-embedded IPv6 address format used by a device depends on 356 several parameters such as the ability of the device to use a port 357 number or not when building an IPv4-embedded IPv6 address. Hence 358 there is a need to identify several formats. This need is covered by 359 the IPv4-embedded IPv6 address Format Option. 361 The IPv4-embedded IPv6 address Format Option is structured as shown 362 in Figure 6. 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | OPTION_INFER_V4V6 | option-length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | format-type | IPv6 Prefix length | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 | | 372 | IPv6 Prefix (Variable) | 373 | | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | preferred-lifetime | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | valid-lifetime | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 6: IPv4-inferred IPv6 addresses Format Option 382 - option-code: OPTION_INFER_V4V6 (To be assigned by IANA) 384 - option-length: Variable. 386 - format-type: Indicates the format type of the IPv4-embedded IPv6 387 address. The values so far defined are the following ones: 389 - "1": When the format-type value is set to 1, the destination 390 addresses of IPv4-in-IPv6 datagrams issued by the device have 391 the following structure: 393 +-----------------------------------------------------------------------------+ 394 | IPv6 Prefix (128 bits) | 395 | | 396 +-----------------------------------------------------------------------------+ 398 Figure 7: Format Type (1) 400 As a matter of fact, the IPv6 Prefix (128 bits long) is an IPv6 401 address here. The IPv4-in-IPv6 encapsulation scheme is the 402 simple IPv4-in-IPv6 encapsulation. 404 - "2": When the format-type value is equal to 2, the 405 destination IPv6 addresses of IPv4-in-IPv6 datagrams issued by 406 the device follow the following structure. This format type is 407 defined in [I-D.boucadair-behave-ipv6-portrange]. 409 +------------------------------------------------------------------------------+ 410 |IPv6 Prefix (32 bits)| Dest. IPv4 | 0::0 | 411 | | address (32 bits)| | 412 +------------------------------------------------------------------------------+ 414 Figure 8: Format Type (2) 416 The IPv4-in-IPv6 encapsulation scheme is the simple IPv4-in- 417 IPv6 encapsulation. 419 - "3": When the format-type value is set to 3, 421 a. if the IPv4 packet to be sent encapsulated bears a protocol 422 with port information (case of TCP and UDP, for example), 423 the destination IPv6 address of the IPv4-in-IPv6 datagram 424 transmitted by the device follows the following structure : 425 +------------------------------------------------------------------------------+ 426 |IPv6 Prefix (32 bits)| Dest. IPv4 |Dest. Port| 0::0 | 427 | | address (32 bits)|(16 bits) | | 428 +------------------------------------------------------------------------------+ 430 Figure 9: Format Type (3) 432 b. if the IPv4 datagram to be encapsulated bears a protocol 433 without port number (e.g. ICMP), the destination IPv6 434 address of the IPv4-in-IPv6 datagram issued by the device 435 SHOULD be sent to another IPv6 destination address than the 436 destination address depicted in Figure 9. For example, 437 such packet without port number MAY be transmitted to a DS- 438 lite CGN node. Another alternative is to send such packet 439 following the Format Type (2) even if Format Type (3) has 440 been mandated by the DHCPv6 server to the client, but this 441 behavior is NOT RECOMMENDED. 443 The IPv4-in-IPv6 encapsulation scheme is the simple IPv4-in- 444 IPv6 encapsulation. 446 - Other format-type values can be defined later. The format- 447 type values from the value 32768 are not reserved. They can be 448 used in a ISP scope to encode a proprietary format-type. 450 - IPv6 Prefix: Encloses the IPv6 prefix to be used to build IPv4- 451 embedded IPv6 addresses. When format-type 1 is used, this prefix 452 is an IPv6 address. 454 - preferred-lifetime: The preferred lifetime for the IPv6 Prefix 455 in the option, expressed in units of seconds. 457 - valid-lifetime: The valid lifetime for the IPv6 Prefix in the 458 option, expressed in units of seconds. 460 5. Supported IPv4-Embedded IPv6 Address Formats Option 462 A client MAY indicate the format-type values it can support (related 463 to IPv4- embedded IPv6 address Formats Option) by including the 464 Supported IPv4-embedded IPv6 address Formats Option in a DHCPv6 465 Solicit, Request, Renew, Rebind, Confirm or Information-request 466 message. 468 The order in the list MAY indicate preference in format-types, the 469 first value being the preferred one. 471 The Supported IPv4-embedded IPv6 address Format Option is structured 472 as shown in Figure 10. 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | OPTION_SUPPORT_INFER_V4V6 | option-length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | format-type-1 | ... | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | ... | format-type-n | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 10: Supported IPv4-inferred IPv6 Address Formats Option 484 - option-code: OPTION_SUPPORT_INFER_V4V6 (To be assigned by IANA) 486 - option-length: permits to numerate the supported format-type 487 values. 489 option-length = 2 * number of format-type values. In case of an 490 odd number of format-type values, a padding of two "x00" octets is 491 to be placed in the ending 16 bits. 493 - format-type-i: the values of the format-type supported by the 494 client. 496 6. Behaviour 498 A client MAY request IPv4 Address and/or Port Extended IPv4 Address 499 and/or IPv4-embedded IPv6 address Format Option(s) by including the 500 corresponding Option codes into an Option Request Option (as per 501 [RFC3315]). This latter being itself included into a Solicit, 502 Request, Renew, Rebind, Confirm or Information-request message. 503 Doing so, the client can inform the server about options the client 504 wishes to receive. 506 The client MAY include IPv4 Address and/or Port Extended IPv4 Address 507 and/or IPv4-embedded IPv6 address Format in Solicit, Request, Renew, 508 Rebind, Confirm or Information request message as hints to the server 509 about parameter values the client would like to be returned. In such 510 case, the Option Request Option MUST be sent in the message and 511 includes the corresponding Option codes. If the client sends the 512 IPv4-embedded IPv6 address Formats as a hint to the server, the value 513 of the format-type in the Option is the value of the format-type 514 preferred by the client. 516 A client MAY indicate the format-type values it can support (related 517 to IPv4-embedded IPv6 address Format Option) by including the 518 Supported IPv4-embedded IPv6 address Formats Option in a Solicit, 519 Request, Renew, Rebind, Confirm or Information-request message. If 520 in the same message the client has also included the IPv4-embedded 521 IPv6 address Format Option as a hint to the server, then the format- 522 type values listed in the Supported IPv4-embedded IPv6 address 523 Formats Option has to be taken by the server as complementary 524 information. In that case, for consistency reasons, the first 525 format-type value indicated in the Supported IPv4-embedded IPv6 526 address Formats Option MUST be the same value (i.e. the preferred 527 one) as the one in the IPv4-embedded IPv6 address Format Option. 529 If a client receives the IPv4 Address Option in conjunction with an 530 IPv4-embedded IPv6 address Format Option, all IPv4 datagrams MUST be 531 encapsulated in IPv6 according to the features indicated in this 532 latter Option, meaning that the destination IPv6 addresses MUST be 533 IPv4-embedded addresses as specified in the Option. 535 If a client receives the Port Extended IPv4 Address Option, the 536 client MUST constrain the source port number of included Port 537 Extended IPv4 Address to be within the provisioned Port Range. If a 538 client receives the IPv4 Address Port Extended IPv4 Address Option in 539 conjunction with the IPv4-embedded IPv6 address Format Option, all 540 IPv4 datagrams MUST be encapsulated in IPv6 according to the features 541 indicated in this latter Option, meaning that the destination IPv6 542 addresses MUST be IPv4-embedded address as specified in the Option. 544 If a client receives a Port Extended IPv4 Address Option but no Port 545 Range Sub-Option included, it MUST use the conveyed IPv4 address as 546 non restricted one. If in addition, it has received an IPv4-embedded 547 IPv6 address Format Option, all IPv4 datagrams MUST be encapsulated 548 in IPv6 according to the features indicated in this latter Option, 549 meaning that the destination IPv6 addresses MUST be IPv4-embedded 550 addresses as specified in the Option. 552 If a client receives a Port Extended IPv4 Address Option with the 553 Port Range Sub-Option enclosed but with the IPv4 address set to 554 "0.0.0.0", the client MUST constrain all IPv4 communications to be 555 within the allocated Port Range. In such case, the IPv4 address the 556 client will use is allocated by other means than by DHCPv6 Port 557 Extended IPv4 Address Option (e.g. through DHCP (IPv4), IPv4 address 558 derived from an IPv6 address, ... ). It is NOT RECOMMENDED that the 559 client or the server use the IPv4 Address Option in conjunction with 560 a Port Extended IPv4 Address option with Port Range Sub-Option 561 present and IPv4 address set to "0.0.0.0", because the use of the 562 Port Extended IPv4 Address Option with a correct IPv4 address is more 563 efficient. 565 When a peer issues a request enclosing one or more options (defined 566 in this document), if the server does not support this (ese) 567 option(s), the DHCPv6 server ignores the corresponding option. 569 7. IANA Considerations 571 This document requests IANA to assign numbers for these DHCPv6 572 options: 574 - OPTION_IPV4_A 576 - OPTION_PORT_EXTENDED_A 578 - OPTION_INFER_V4V6 580 - OPTION_SUPPORT_INFER_V4V6 582 And the following sub-options: 584 - SUB_OPTION_PORT_MASK 586 - SUB_OPTION_DELG_RAND 588 8. Security Considerations 590 All security considerations described in [RFC3315] apply for this 591 specification. 593 9. Acknowledgements 595 The authors would like to thank Christian JACQUENET for his review. 597 10. References 599 10.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 605 and M. Carney, "Dynamic Host Configuration Protocol for 606 IPv6 (DHCPv6)", RFC 3315, July 2003. 608 10.2. Informative References 610 [I-D.bajko-pripaddrassign] 611 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 612 "Port Restricted IP Address Assignment", 613 draft-bajko-pripaddrassign-02 (work in progress), 614 October 2009. 616 [I-D.boucadair-behave-ipv6-portrange] 617 Boucadair, M., Levis, P., Grimault, J., Villefranque, A., 618 Kassi-Lahlou, M., Bajko, G., Lee, Y., Melia, T., and O. 619 Vautrin, "Flexible IPv6 Migration Scenarios in the Context 620 of IPv4 Address Shortage", 621 draft-boucadair-behave-ipv6-portrange-04 (work in 622 progress), October 2009. 624 [I-D.dhankins-softwire-tunnel-option] 625 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 626 Protocol (DHCPv6) Option for Dual-Stack Lite", 627 draft-dhankins-softwire-tunnel-option-05 (work in 628 progress), November 2009. 630 [I-D.ietf-behave-address-format] 631 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 632 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 633 draft-ietf-behave-address-format-03 (work in progress), 634 December 2009. 636 [I-D.ietf-softwire-dual-stack-lite] 637 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 638 Y., and R. Bush, "Dual-stack lite broadband deployments 639 post IPv4 exhaustion", 640 draft-ietf-softwire-dual-stack-lite-02 (work in progress), 641 October 2009. 643 [I-D.nishitani-cgn] 644 Nishitani, T., Yamagata, I., Miyakawa, S., Nakagawa, A., 645 and H. Ashida, "Common Functions of Large Scale NAT 646 (LSN)", draft-nishitani-cgn-03 (work in progress), 647 November 2009. 649 Appendix A. Port Mask Example 651 The following figure (Figure 11) provides an example of the resulting 652 Port Range when: 654 - Port Range Mask is set to 0001010000000000 (5120) and 656 - Port Range Value is set to 0000010000000000 (1024). 658 Ports belonging to this port range must have the 4th bit (resp. the 659 sixth one), from the left, set to 0 (resp. 1). Only these ports will 660 be used by the peer when enforcing the configuration conveyed by 661 DHCPv6. 663 0 1 664 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Mask 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | 669 | | (two significant bits) 670 v v 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 |0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| Port Range Value 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 |x x x 0 x 1 x x x x x x x x x x| Usable ports (x may take a value of 0 or 1). 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Figure 11: Example of Port Range Mask and Port Range Value 681 Authors' Addresses 683 Mohamed Boucadair (editor) 684 France Telecom 685 3, Av Francois Chateaux 686 Rennes 35000 687 France 689 Email: mohamed.boucadair@orange-ftgroup.com 691 Pierre Levis 692 France Telecom 694 Email: pierre.levis@orange-ftgroup.com 696 Jean-Luc Grimault 697 France Telecom 699 Email: jeanluc.grimault@orange-ftgroup.com 701 Teemu Savolainen 702 Nokia 704 Email: teemu.savolainen@nokia.com 706 Gabor Bajko 707 Nokia 709 Email: Gabor.Bajko@nokia.com