idnits 2.17.1 draft-sun-dhc-dhcpv6-opt-v4config-00.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 26 instances of too long lines in the document, the longest one being 1 character 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 (February 18, 2013) is 4078 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: 'RFC3046' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'RFC3527' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'RFC4925' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC5961' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC6056' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'I-D.bajko-pripaddrassign' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'I-D.sun-dhc-port-set-option' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'I-D.vixie-dnsext-dns0x20' is defined on line 328, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 4925 ** Downref: Normative reference to an Experimental RFC: RFC 6346 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-05 == Outdated reference: A later version (-02) exists of draft-sun-dhc-port-set-option-00 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Sun 3 Internet-Draft Y. Cui 4 Intended status: Standards Track Tsinghua University 5 Expires: August 22, 2013 February 18, 2013 7 Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for IPv4 8 Configuration 9 draft-sun-dhc-dhcpv6-opt-v4config-00 11 Abstract 13 This document defines a DHCPv6 option with two types of sub-options 14 for IPv4 configurations in the case of IPv4/IPv6 transition. One is 15 used for the assignment of IPv4 address and port set, the other is 16 used for configuring existing DHCPv4 options required by clients for 17 IPv4-over-IPv6 communications. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 22, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 55 3. DHCPv6 Option for IPv4 Configuration . . . . . . . . . . . . . 3 56 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Shared IPv4 address Sub-Option . . . . . . . . . . . . . . 4 58 3.3. Sub-Option for Conveying Existing DHCPv4 Options . . . . . 5 59 4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Denial-of-Service . . . . . . . . . . . . . . . . . . . . . 6 63 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 During the IPv4/IPv6 transition period, IPv4 and IPv6 will coexist 71 for a period of time. There are still requirements for visiting IPv4 72 services. In order to continue IPv4 communications across IPv6-only 73 access network, IPv4 information is needed to be configured across 74 IPv6 networks. On the one hand, IPv4 address has run out, which 75 raise requirements for address-sharing. On the other hand, some of 76 the existing DHCPv4 options are likely to be configured over IPv6 to 77 guarantee success of some IPv4 services. 79 To deal with the issues, [I-D.ietf-dhc-dhcpv4-over-ipv6] provides a 80 clean solution that extends DHCPv4 over IPv6 transport to support 81 IPv4 resources allocation and all DHCPv4 options natively. For 82 circumstances that there are only DHCPv6 servers deployed, this 83 document proposes a mechanism that introduces new DHCPv6 option for 84 IPv4 configurations. 86 This proposal describes a new DHCPv6 option and two types of sub- 87 options which allow the DHCPv6 server to assign a shared IPv4 address 88 and optionally some demanded DHCPv4 options during the IPv6 address 89 provisioning process. By assigning the same IPv4 address with non- 90 overlaped port sets to multiple clients, the clients can share the 91 IPv4 address and continue to deliver IPv4 services to subscribers. 93 The IPv4 Configuration Option described in this document can be used 94 in various deployment scenarios, some of which are described in 95 [RFC6346] 97 2. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 3. DHCPv6 Option for IPv4 Configuration 105 3.1. Option Format 107 The IPv4 Configuration DHCPv6 Option consists of two types of sub- 108 options, one for shared IPv4 address and the other for importing 109 existing DHCPv4 options. The SUB_OPT_SHARRED_ADDR MUST be conveyed 110 by the IPv4 Configuration Option while the SUB_OPT_v4OPT MAY be 111 conveyed if necessary. The format of IPv4 Configuration DHCPv6 112 Option is shown in Figure 1. 114 0 1 2 3 115 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | OPTION_V4CONFIG | option-length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | sub-option-code | sub-option-length | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | sub-option-content | 123 . . 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | . . . | 126 . . 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Figure 1 IPv4 Configuration Option Format 131 o option-code: OPTION_V4CONFIG (TBD) 133 o option-length: This field indicating the length of the option 134 excluding the 'Option Code' and the 'Option Length' fields. In 135 this option, the option-length is variable, with value of no less 136 than 12 octets. 138 o sub-option-code: Specify the code of sub-option, which should be 139 either SUB_OPT_SHARRED_ADDR or SUB_OPT_v4OPT. 141 o sub-option-length: Length of sub-option. 143 o sub-option-content: The content of enclosed sub-option. 145 3.2. Shared IPv4 address Sub-Option 147 This sub-option is defined for a shared IPv4 address assignment. The 148 sub-option format is shown in the following figure. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | SUB_OPT_SHARRED_ADDR | sub-option-length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | IPv4 Address | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Port Set Index | Port Set Mask | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 2 Shared-IPv4 Address Sub-Option Format 162 o sub-option-code: SUB_OPT_SHARRED_ADDR (TBD) 163 o sub-option-length: The length this option is 8. 165 o Port Set Index: Port Set Index identifies a set of ports assigned 166 to a device. The first k bits on the left of the 2-octet field is 167 the Port Set Index value, with the rest of the field right padding 168 zeros. 170 o Port Set Mask: Port Set Mask indicates the position of the bits 171 used to build the mask. The first k bits on the left is padding 172 ones while the remained (16-k) bits of the 2-octet field on the 173 right is padding zeros. 175 In the context of this sub-option, the port number should consist of 176 port set prefix and port number suffix. The port set prefix can be 177 got from Port Set Index and Port Set Mask, while port number suffix 178 can change continuously. The format of port number is shown in 179 Figure 2. 181 0 15 182 +-----------------------+-----------------------------+ 183 | port set prefix | port number suffix | 184 +-----------------------+-----------------------------+ 185 |<-------k bits-------->|<--------(16-k) bits-------->| 187 Figure 3 Bit Representation of a port number 189 In order to exclude the system ports ([I-D.ietf-tsvwg-iana-ports]) or 190 ports saved by SPs, the former port-sets that contains well-known 191 ports SHOULD NOT be assigned. 193 For example: If k is 10 (the left 10 bits of Port Set Mask is '1'), 194 the first 16 port sets is located in well-known port space, which 195 should not be allocated. Or, 197 For example: If k is 4 (the left 4 bits of Port Set Mask is '1'), the 198 first port set (0 - 4095) contains the well-know port space. It 199 should be perceived as well. 201 3.3. Sub-Option for Conveying Existing DHCPv4 Options 203 This sub-option is used for the cases that some of the existing 204 DHCPv4 options are needed to be provisioned to the end users. The 205 existing DHCPv4 options can be put in with original formats remained. 206 This sub-option MUST NOT appear in OPTION_V4CONFIG if 207 SUB_OPT_SHARED_ADDR is not conveyed. The sub-option format is as 208 follows. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | SUB_OPT_v4OPT | sub-option-length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Required DHCPv4 options | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | ... | 218 . . 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 4 Format of Sub-Option Containing DHCPv4 Options 223 o sub-option-code: SUB_OPT_v4OPT (TBD) 225 o sub-option-length: The length is variable. 227 o Required DHCPv4 options: Required DHCPv4 options can be put in 228 this field one by one. The format of DHCPv4 options will not 229 change. 231 4. Server Behavior 233 TBD. 235 5. Client Behavior 237 TBD 239 6. Security Consideration 241 6.1. Denial-of-Service 243 The solution is generally vulnerable to DoS when used in shared 244 medium or when access network authentication is not a prerequisite to 245 IP address assignment. The solution SHOULD only be used on point-to- 246 point links, tunnels, and/or in environments where authentication at 247 link layer is performed before IP address assignment, and not shared 248 medium. 250 7. IANA Consideration 252 IANA is kindly requested to allocate DHCPv6 option code to the 253 OPTION_V4CONFIG, DHCPv6 sub-option codes to the SUB_OPT_SHARRED_ADDR 254 and SUB_OPT_v4OPT. The code should be added to the DHCPv6 option 255 code space. 257 8. References 258 8.1. Normative References 260 [RFC2119] Bradner, S., "Key words for use in 261 RFCs to Indicate Requirement 262 Levels", BCP 14, RFC 2119, 263 March 1997. 265 [RFC3046] Patrick, M., "DHCP Relay Agent 266 Information Option", RFC 3046, 267 January 2001. 269 [RFC3315] Droms, R., Bound, J., Volz, B., 270 Lemon, T., Perkins, C., and M. 271 Carney, "Dynamic Host Configuration 272 Protocol for IPv6 (DHCPv6)", 273 RFC 3315, July 2003. 275 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., 276 and J. Kumarasamy, "Link Selection 277 sub-option for the Relay Agent 278 Information Option for DHCPv4", 279 RFC 3527, April 2003. 281 [RFC4925] Li, X., Dawkins, S., Ward, D., and 282 A. Durand, "Softwire Problem 283 Statement", RFC 4925, July 2007. 285 [RFC5961] Ramaiah, A., Stewart, R., and M. 286 Dalal, "Improving TCP's Robustness 287 to Blind In-Window Attacks", 288 RFC 5961, August 2010. 290 [RFC6056] Larsen, M. and F. Gont, 291 "Recommendations for Transport- 292 Protocol Port Randomization", 293 BCP 156, RFC 6056, January 2011. 295 [RFC6346] Bush, R., "The Address plus Port 296 (A+P) Approach to the IPv4 Address 297 Shortage", RFC 6346, August 2011. 299 8.2. Informative References 301 [I-D.bajko-pripaddrassign] Bajko, G., Savolainen, T., 302 Boucadair, M., and P. Levis, "Port 303 Restricted IP Address Assignment", 304 draft-bajko-pripaddrassign-04 (work 305 in progress), April 2012. 307 [I-D.ietf-dhc-dhcpv4-over-ipv6] Cui, Y., Wu, P., Wu, J., and T. 308 Lemon, "DHCPv4 over IPv6 Transport", 309 draft-ietf-dhc-dhcpv4-over-ipv6-05 310 (work in progress), September 2012. 312 [I-D.ietf-tsvwg-iana-ports] Cotton, M., Eggert, L., Touch, J., 313 Westerlund, M., and S. Cheshire, 314 "Internet Assigned Numbers Authority 315 (IANA) Procedures for the Management 316 of the Service Name and Transport 317 Protocol Port Number Registry", 318 draft-ietf-tsvwg-iana-ports-10 (work 319 in progress), February 2011. 321 [I-D.sun-dhc-port-set-option] Sun, Q., Lee, Y., Sun, Q., Bajko, 322 G., and M. Boucadair, "Dynamic Host 323 Configuration Protocol (DHCP) Option 324 for Port Set Assignment", 325 draft-sun-dhc-port-set-option-00 326 (work in progress), October 2012. 328 [I-D.vixie-dnsext-dns0x20] Vixie, P. and D. Dagon, "Use of Bit 329 0x20 in DNS Labels to Improve 330 Transaction Identity", 331 draft-vixie-dnsext-dns0x20-00 (work 332 in progress), March 2008. 334 Authors' Addresses 336 Qi Sun 337 Tsinghua University 338 Department of Computer Science, Tsinghua University 339 Beijing 100084 340 P.R.China 342 Phone: +86-10-6278-5822 343 EMail: sunqi@csnet1.cs.tsinghua.edu.cn 345 Yong Cui 346 Tsinghua University 347 Department of Computer Science, Tsinghua University 348 Beijing 100084 349 P.R.China 351 Phone: +86-10-62603059 352 EMail: yong@csnet1.cs.tsinghua.edu.cn