idnits 2.17.1 draft-link-dhc-v6only-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2019) is 1599 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration L. Colitti 3 Internet-Draft J. Linkova 4 Intended status: Standards Track Google 5 Expires: June 11, 2020 M. Richardson 6 Sandelman 7 T. Mrugalski 8 ISC 9 December 9, 2019 11 IPv6-Only-Preferred Option for DHCP 12 draft-link-dhc-v6only-01 14 Abstract 16 This document specifies a DHCP option to indicate that a host 17 supports an IPv6-only mode and willing to forgo obtaining an IPv4 18 address if the network provides IPv6 connectivity. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 11, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Reasons to Signal IPv6-Only Support in DHCPv4 Packets . . . . 4 58 3. IPv6-Only Preferred Option . . . . . . . . . . . . . . . . . 5 59 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. DHCPv4 Client Behaviour . . . . . . . . . . . . . . . . . 5 61 3.3. DHCPv4 Server Behaviour . . . . . . . . . . . . . . . . . 7 62 3.4. Configuration Variables . . . . . . . . . . . . . . . . . 8 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 7.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 One of the biggest challenges of deploying IPv6-only LANs is that 74 such networks might contain rather heterogeneous collection of hosts. 75 Some of them are capable of operating in IPv6-only mode (either 76 because the OS and all applications are IPv6-only capable or because 77 the host has some form of 464XLAT [RFC6877] deployed). At the same 78 time some devices might still have IPv4 dependencies and need IPv4 79 connectivity to operate properly. To incrementally rollout 80 IPv6-only, network operators need to provide IPv4-as-a-service 81 whereby a host receives an IPv4 address if it needs it, while 82 IPv6-only capable devices (such as modern mobile devices) are not 83 allocated IPv4 addresses. Deploying separate LAN segments for 84 IPv6-only and for dual-stack hosts (such as two WiFi SSIDs or two 85 VLANs) is undesirable for a number of reasons, including but not 86 limited to: 88 o Doubling the number of network segments which leads to operational 89 complexity and performance impact, for instance due to TCAM 90 utilization increase from an increased number of ACL entries. 92 o Placing a host into the correct network segment is problematic. 93 For example, in the case of 802.11 Wi-Fi the user might select the 94 wrong SSID. In the case of wired 802.1x authentication the 95 authentication server might not have all the information required 96 to make the correct decision. 98 It would be beneficial for IPv6 deployment if operators could 99 implement IPv6-mostly (or IPv4-as-a-Service) segments where IPv6-only 100 hosts co-exist with legacy dual-stack devices. The trivial solution 101 of disabling IPv4 stack on IPv6-only capable hosts is not feasible as 102 those clients must be able to operate on IPv4-only networks as well. 103 While IPv6-only capable devices might use a heuristic approach to 104 learning if the network provides IPv6-only functionality and stop 105 using IPv4 if it does, it might be practically undesirable. One 106 important reason is that when a host connects to a network, it does 107 not know if the network is IPv4-only, dual-stack or IPv6-only. To 108 ensure that the connectivity over whatever protocol is present 109 becomes available as soon as possible the host usually starts 110 configuring both IPv4 and IPv6 immediately. If hosts were to delay 111 requesting IPv4 until IPv6 reachability is confirmed, that would 112 penalize IPv4-only and dual-stack networks, which does not seem 113 practical. Requesting IPv4 and then releasing it later, after IPv6 114 reachability is confirmed, might cause user-visible errors as it 115 would be disruptive for applications which have started using the 116 assigned IPv4 address already. Instead it would be useful to have a 117 mechanism which would allow a host to indicate that IPv4 is optional 118 and a network to signal that IPv6-only functionality (such as NAT64) 119 is available. The proposed solution is to introduce a new DHCP 120 option which a client uses to indicate that it does not need IPv4 if 121 the network provides IPv6-only connectivity (as NAT64 and DNS64). If 122 the particular network segment provides IPv4-as-a-service such 123 clients would not be supplied with IPv4 addresses, while on IPv4-only 124 or dual-stack segments without NAT64 services IPv4 addresses will be 125 provided. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 1.2. Terminology 137 IPv6-only capable host: a host which does not require IPv4 and can 138 operate on IPv6-only networks. Strictly speaking IPv6-only 139 capability is specific to a given interface of the host: if some 140 application on a host require IPv4 and 464XLAT CLAT [RFC6877] is only 141 enabled on one interface, the host is IPv6-only capable if connected 142 to a NAT64 network via that interface. 144 IPv4-as-a-Service: a deployment scenario when end hosts are expected 145 to operate in IPv6-only mode by default and IPv4 addresses can be 146 assigned to some hosts if those hosts explicitly opt-in to receiving 147 IPv4 addresses. 149 IPv6-mostly network: a network which provides NAT64 (possibly with 150 DNS64) service as well as IPv4 connectivity. Such deployment 151 scenario allows operators to incrementally turn off IPv4 on end 152 hosts, while still providing IPv4 to devices which require IPv4 to 153 operate. But, IPv6-only capable devices need not be assigned IPv4 154 addresses. 156 IPv6-Only network: a network which does not provide routing 157 functionality for IPv4 packets. Such networks may or may not allow 158 intra-LAN IPv4 connectivity. IPv6-Only network usually provides 159 access to IPv4-only resources via NAT64 [RFC6147]. 161 NAT64: Network Address and Protocol Translation from IPv6 Clients to 162 IPv4 Servers [RFC6146]; 164 RA: Router Advertisement, a message used by IPv6 routers to advertise 165 their presence together with various link and Internet parameters 166 [RFC4861]; 168 DNS64: a mechanism for synthesizing AAAA records from A records 169 [RFC6147]; 171 2. Reasons to Signal IPv6-Only Support in DHCPv4 Packets 173 For networks which contain both IPv6-capable and IPv4-requiring 174 devices and utilize DHCP for configuring IPv4 network stack on hosts, 175 it seems only natural to leverage the same protocol to signal that 176 IPv4 is discretional on a given segment. Such an approach limits the 177 attack surface to DHCP-related attacks without introducing new 178 vulnerable elements. 180 Another benefit of using DHCPv4 for signaling is that IPv4 will be 181 disabled only if both the client and the server indicate IPv6-only 182 capability. It allows IPv6-only capable hosts to turn off IPv4 only 183 upon receiving an explicit signal from the network and operate in 184 dual-stack or IPv4-only mode otherwise. 186 Coexistence of IPv6-only, dual-stack and even IPv4-only hosts on the 187 same LAN would not only allow network administrators to preserve 188 scarce IPv4 addresses but would also drastically simplify incremental 189 deployment of IPv6-only networks, positively impacting IPv6 adoption. 191 3. IPv6-Only Preferred Option 193 3.1. Option format 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type | Length | Value | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Value (contd) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1: IPv6-Only Preferred Option Format 205 Fields: 207 Type 8-bit identifier of the IPv6-Only Preferred option type as 208 assigned by IANA: TBD 209 Length 8-bit unsigned integer. The length of the option excluding 210 the Type and Length Fields. The server MUST set the length 211 field to 4. The receiver MUST ignore the IPv6-Only Preferred 212 option if the length field value is not 4. 213 Value 32-bit unsigned 214 integer. The number of 215 seconds the client should disable DHCPv4 for (V6ONLY_WAIT 216 configuration variable). 217 If the server pool is explicitly conifgured with V6ONLY_WAIT 218 timer the server MUST set the field to that configured value. 219 Otherwise the server MUST set it to zero. 220 The client MUST ignore V6ONLY_WAIT timer received from the 221 server if the value is less than 300 seconds. 223 3.2. DHCPv4 Client Behaviour 225 A DHCP client SHOULD allow a device administrator to configure 226 IPv6-only preferred mode either for a specific interface (to indicate 227 that the device is IPv6-only capable if connected to a NAT64 network 228 via that interface) or for all interfaces. If only a specific 229 interface is configured as IPv6-only capable the DHCP client MUST NOT 230 be considered as an IPv6-capable for the purpose of sending/receiving 231 DHCP packets over any other interfaces. 233 Clients not capable of operating in an IPv6-only NAT64 environment 234 MUST NOT include the IPv6-only Preferred option in the Parameter 235 Request List of any DHCP packets and MUST ignore that option in 236 packets received from DHCP servers. 238 IPv6-only capable clients SHOULD include the IPv6-only Preferred 239 option in the Parameter Request List in DHCPDISCOVER and DHCPREQUEST 240 messages for interfaces so enabled and follow the processing as 241 described below on a per interface enabled basis. 243 If the client did not include the IPv6-only Preferred option in the 244 DHCPDISCOVER or DHCPREQUEST message it MUST ignore the IPv6-only 245 Preferred option in any messages received from the server. 247 If the client includes the IPv6-only Preferred option in the 248 Parameter Request List and the DHCPOFFER message from the server 249 contains a valid IPv6-only Preferred option, the client MUST NOT 250 configure the IPv4 address provided in the DHCPOFFER. If the 251 IPv6-only Preferred option returned by the server contains non-zero 252 value the client SHOULD set the V6ONLY_WAIT timer to that value. If 253 the server returns zero value the client MUST use its own 254 configuration for V6ONLY_WAIT timer. The client SHOULD stop the DHCP 255 configuration process for at least V6ONLY_WAIT seconds or until a 256 network attachment event happens. The host MAY disable IPv4 stack 257 completely for V6ONLY_WAIT seconds or until the network disconnection 258 event happens. 260 The client SHOULD include the IPv6-only Preferred option in 261 DHCPREQUEST messages (after receiving a DHCPOFFER without this 262 option, for a INIT-REBOOT, or when renewing or rebinding a leased 263 address). If the DHCP server responds with a DHCPACK that includes 264 the IPv6-only Preferred option, the client MAY send a DHCPRELEASE 265 message and MAY either stop the DHCP configuration process or disable 266 IPv4 stack completely for V6ONLY_WAIT seconds or until the network 267 disconnection event happens. Alternatively the client MAY continue 268 to use the assigned IPv4 address until further DHCP reconfiguration 269 events. 271 If the client includes the IPv6-only Preferred option in the 272 Parameter Request List and the server responds with DHCPOFFER message 273 without a valid IPv6-only Preferred option, the client MUST proceed 274 as normal with a DHCPREQUEST. 276 If the client waits for multiple DHCPOFFER responses and selects one 277 of them, it MUST follow the processing for the IPv6-only Preferred 278 option based on the selected response. A client MAY use the presence 279 of the IPv6-only Preferred option as a selection criteria. 281 When an IPv6-only capable client receives the IPv6-Only Preferred 282 option from the server, the client MAY configure IPv4 link-local 283 address [RFC3927]. In that case IPv6-Only capable devices might 284 still be able to communicate over IPv4 to other devices on the link. 286 3.3. DHCPv4 Server Behaviour 288 The DHCP server SHOULD have a configuration option to configure the 289 given DHCP pool with an IPv6-only preferred option. The DHCP server 290 MAY have a configuration option to specify V6ONLY_WAIT timer for all 291 or individual IPv6-mostly pools. 293 The server MUST NOT include the IPv6-only Preferred option in the 294 DHCPOFFER or DHCPACK message if the YIADDR field in the message does 295 not belong to a pool configured as IPv6-mostly. The server MUST NOT 296 include the IPv6-only Preferred option in the DHCPOFFER or DHCPACK 297 message if the option was not present in the Parameter Request List 298 sent by the client. 300 If the IPv6-only Preferred option is present in the Parameter Request 301 List received from the client and the corresponding DHCP pool is 302 explicitly configured as belonging to an IPv6-mostly network segment, 303 the server MUST include the IPv6-only Preferred option when 304 responding with the DHCPOFFER or DHCPACK message. If the server 305 responds with the IPv6-only Preferred option and the V6ONLY_WAIT 306 timer is configured for the pool, the server MUST copy the configured 307 value to the IPv6-only Preferred option value field. Otherwise it 308 MUST set the field to zero. The server SHOULD include an available 309 IPv4 address from the pool into the DHCPOFFER as per recommendations 310 in [RFC2131] but SHOULD NOT reserve the address and SHOULD NOT verify 311 its uniqueness. The client is not expected to use that IPv4 address 312 so if the client responds with the DHCPREQUEST message for that 313 address the server SHOULD respond with DHCPNAK. 315 As an optional optimization an IPv6-mostly pool MAY be configured 316 with a dedicated IPv4 address to be returned to IPv6-only capable 317 clients. In that case the server SHOULD specify that address as the 318 client's network address and MUST NOT verify its uniqueness. 320 If a client includes both a Rapid-Commit option [RFC4039] and 321 IPv6-Only Preferred option in the DHCPDISCOVER message the server 322 SHOULD NOT honor the Rapid-Commit option if the response would 323 contain the IPv6-only Preferred option to the client. It SHOULD 324 instead respond with a DHCPOFFER so that the IP address does not need 325 to be reserved for the client until the lease expires. 327 3.4. Configuration Variables 329 V6ONLY_WAIT The minimum time the client SHOULD stop the DHCP 330 configuration process for. MUST be no less than 300 331 seconds. Default: 1800 seconds 333 4. IANA Considerations 335 The IANA is requested to assign a new DHCP Option code for the 336 IPv6-Only Preferred option from the BOOTP Vendor Extensions and DHCP 337 Options registry, located at https://www.iana.org/assignments/bootp- 338 dhcp-parameters/bootp-dhcp-parameters.xhtml#options . If possible, 339 please assign option code 108. 341 +----------------------------+-------+ 342 | Option Name | Type | 343 +----------------------------+-------+ 344 | IPv6-only Preferred option | (TBD) | 345 +----------------------------+-------+ 347 Table 1 349 5. Security Considerations 351 The proposed mechanism is not introducing any new security 352 implications. While clients using the IPv6-only Preferred option are 353 vulnerable to attacks related to a rogue DHCP server, enabling 354 IPv6-only Preferred option does not provide an attacker with any 355 additional mechanisms. 357 It should be noted that disabling IPv4 on a host upon receiving the 358 IPv6-only Preferred option from the DHCP server protects the host 359 from IPv4-related attacks and therefore could be considered a 360 security feature. 362 6. Acknowledgements 364 Thanks to the following people (in alphabetical order) for their 365 review and feedback: Mohamed Bboucadair, Bjorn Mork, Bernie Volz (AI: 366 add more names here). Authors would like to thank Bob Hinden and 367 Brian Carpenter for the initial idea of signaling IPv6-only 368 capability to hosts. 370 7. References 371 7.1. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 379 RFC 2131, DOI 10.17487/RFC2131, March 1997, 380 . 382 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 383 Configuration of IPv4 Link-Local Addresses", RFC 3927, 384 DOI 10.17487/RFC3927, May 2005, 385 . 387 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 388 the Dynamic Host Configuration Protocol version 4 389 (DHCPv4)", RFC 4039, DOI 10.17487/RFC4039, March 2005, 390 . 392 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 393 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 394 DOI 10.17487/RFC4861, September 2007, 395 . 397 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 398 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 399 May 2017, . 401 7.2. Informative References 403 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 404 NAT64: Network Address and Protocol Translation from IPv6 405 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 406 April 2011, . 408 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 409 Beijnum, "DNS64: DNS Extensions for Network Address 410 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 411 DOI 10.17487/RFC6147, April 2011, 412 . 414 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 415 Combination of Stateful and Stateless Translation", 416 RFC 6877, DOI 10.17487/RFC6877, April 2013, 417 . 419 Authors' Addresses 421 Lorenzo Colitti 422 Google 423 Shibuya 3-21-3 424 Shibuya, Tokyo 150-0002 425 JP 427 Email: lorenzo@google.com 429 Jen Linkova 430 Google 431 1 Darling Island Rd 432 Pyrmont, NSW 2009 433 AU 435 Email: furry@google.com 437 Michael C. Richardson 438 Sandelman Software Works 440 Email: mcr+ietf@sandelman.ca 441 URI: http://www.sandelman.ca/ 443 Tomek Mrugalski 444 Internet Systems Consortium, Inc. 445 950 Charter Street 446 Redwood City, CA 94063 447 USA 449 Email: tomasz.mrugalski@gmail.com