idnits 2.17.1 draft-ietf-dhc-dhcp4o6-saddr-opt-08.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7598, but the abstract doesn't seem to directly say this. It does mention RFC7598 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2018) is 1993 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: 'RFC2827' is defined on line 707, but no explicit reference was found in the text -- Duplicate reference: RFC2827, mentioned in 'RFC2827', was also mentioned in 'BCP38'. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHCWG I. Farrer 3 Internet-Draft Deutsche Telekom AG 4 Updates: 7598 (if approved) Q. Sun 5 Intended status: Standards Track Y. Cui 6 Expires: May 16, 2019 L. Sun 7 Tsinghua University 8 November 12, 2018 10 Softwire Provisioning using DHCPv4 Over DHCPv6 11 draft-ietf-dhc-dhcp4o6-saddr-opt-08 13 Abstract 15 DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically 16 configuring IPv4 for use as an over-the-top service in a IPv6-only 17 network. Softwires are an example of such a service. For DHCPv4 18 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire 19 mechanisms and deployment scenarios (e.g., RFC7596 or RFC7597), the 20 operator needs to know the IPv6 address that the client will use as 21 the source of IPv4-in-IPv6 softwire tunnel. This address, in 22 conjunction with the client's IPv4 address, and (in some deployments) 23 the Port Set ID are used to create a binding table entry in the 24 operator's softwire tunnel concentrator. This memo defines a DHCPv6 25 option to convey IPv6 parameters for establishing the softwire tunnel 26 and a DHCPv4 option (to be used only with DHCP 4o6) to communicate 27 the source tunnel IPv6 address between the DHCP 4o6 client and 28 server. It is designed to work in conjunction with the IPv4 address 29 allocation process. 31 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped 32 Clients (RFC7598) describes a deterministic DHCPv6 based mechanism 33 for provisioning softwires. This document updates "DHCPv6 Options 34 for Configuration of Softwire Address and Port-Mapped Clients" 35 (RFC7598), allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 36 client's Option Request Option (ORO) request and appear directly 37 within subsequent messages sent by the DHCPv6 server. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 16, 2019. 56 Copyright Notice 58 Copyright (c) 2018 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 (https://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 Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 76 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 77 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 4 78 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 5 79 6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7 80 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7 81 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option . . . . 8 82 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 83 7.1. Client Initialization . . . . . . . . . . . . . . . . . . 9 84 7.2. Renewing or Rebinding the IPv4 Address Lease and 85 Softwire Source Address . . . . . . . . . . . . . . . . . 10 86 7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10 87 7.3. Releasing the IPv4 Address Lease and Softwire 88 Source Address . . . . . . . . . . . . . . . . . . . . . 10 89 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 10 90 7.5. Client and Server Softwire Source Address Mismatch . . . 11 91 7.6. Use With Dynamic, Shared IPv4 Addresses . . . . . . . . . 11 92 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 93 8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 12 94 8.2. Handling Conflicts Between Client's Bound IPv6 95 Source Addresses . . . . . . . . . . . . . . . . . . . . 12 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 9.1. Client Privacy Considerations . . . . . . . . . . . . . . 13 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 99 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 102 12.2. Informative References . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 105 1. Introduction 107 Deterministic IPv4-over-IPv6 transition technologies require that 108 elements are pre-configured with binding rules for routing traffic to 109 clients. This places a constraint on the choice of address used as 110 the client's softwire source address: it must use a pre-determined 111 prefix which is usually configured on the home gateway device. 112 [RFC7598] describes a DHCPv6 based mechanism for provisioning such 113 deterministic softwires. 115 A dynamic provisioning model, such as using DHCPv4 over DHCPv6 116 [RFC7341] (DHCP 4o6) allows much more flexibility in the location of 117 the IPv4-over-IPv6 softwire source address. In this model, the IPv6 118 address is dynamically communicated back to the service provider 119 allowing the corresponding softwire configuration to be created in 120 the border router (BR). 122 The DHCP 4o6 client and softwire client could be run on end devices 123 attached to a network segment using any routable IPv6 prefix 124 allocated to an end-user, located anywhere within an arbitrary home 125 network topology. Dynamic allocation also helps to optimize IPv4 126 resource usage as only clients which are actively renewing their IPv4 127 lease hold on to the address. 129 This document describes a mechanism for dynamically provisioning 130 softwires created using DHCP 4o6, including provisioning the client 131 with the address of the softwire border router (BR) and informing the 132 service provider of client's binding between the dynamically 133 allocated IPv4 address and Port Set ID and the IPv6 address that the 134 softwire Initiator will use for accessing IPv4-over-IPv6 services. 136 The mechanism operates alongside the DHCP 4o6 message flows to 137 communicate the binding information over the IPv6-only network. The 138 DHCP 4o6 server provides a single point in the network which holds 139 the current client binding information. The service provider can 140 then use this binding information to provision other functional 141 elements, such as the BR(s). 143 2. Applicability 145 The mechanism described in this document is only suitable for use for 146 provisioning softwire clients via DHCP 4o6. The options described 147 here are only applicable within the DHCP 4o6 message exchange 148 process. Current softwire technologies suitable for extending to 149 incorporate DHCP 4o6 with dynamic IPv4 address leasing include 150 [RFC7597] and [RFC7596]. 152 3. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 4. Solution Overview 162 In order to provision a softwire, both IPv6 and IPv4 configuration 163 needs to be passed to the client. To map this to the DHCP 4o6 164 configuration process, the IPv6 configuration is carried in DHCPv6 165 options [I-D.ietf-dhc-rfc3315bis], carried inside the DHCPv6 message 166 DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used 167 to provision the remote IPv6 address for the softwire border router 168 (see Section 4.1 below). OPTION_S46_BIND_IPV6_PREFIX (TBD1), is 169 optionally sent by the DHCP 4o6 server to indicate to the client a 170 preferred IPv6 prefix for binding the received IPv4 configuration and 171 sourcing tunnel traffic. This may be necessary if there are multiple 172 IPv6 prefixes in use in the customer network (e.g., Unique Local 173 Addresses (ULAs)), or if the specific IPv4-over-IPv6 transition 174 mechanism requires the use of a particular prefix for any reason. 176 IPv4 configuration is carried in DHCPv4 messages [RFC2131], (inside 177 the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism 178 described in [RFC7341]. 180 In order for the client to communicate the softwire source address, a 181 new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (TBD2) is defined in this 182 document. This is included in DHCPREQUEST messages sent by the 183 client and is stored by the server for the lifetime of the IPv4 184 address lease. 186 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 188 Section 4.2 of [RFC7598] defines option OPTION_S46_BR(90) for 189 communicating remote softwire border relay (BR) IPv6 address(es) to a 190 client, but mandates that the option can only be used when 191 encapsulated within one of the softwire container options: 192 OPTION_S46_CONT_MAPE (94) or OPTION_S46_CONT_LW(96). From Section 3 193 of [RFC7598]: 195 "Softwire46 DHCPv6 clients that receive provisioning options that 196 are not encapsulated in container options MUST silently ignore 197 these options." 199 This document updates [RFC7598], removing this restriction for 200 OPTION_S46_BR (90), allowing it to be enumerated in the client's ORO 201 request and appear directly within subsequent messages sent by the 202 DHCPv6 server. 204 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow 206 The following diagram shows the relevant extensions to the successful 207 DHCP 4o6 IPv4 allocation client/server message flow for the softwire 208 source address function. The full process, including error handling 209 is described in Section 7. 211 In each step, the DHCPv6 portion of the message and any relevant 212 option is shown above the arrow. The DHCP 4o6 content of the message 213 and its relevant options are below the arrow. All the DHCPv4 214 messages are encapsulated in DHCPV4-QUERY (20) or DHCPV4-RESPONSE 215 (21) messages. Where relevant, the necessary options and their 216 contents are shown. 218 DHCP 4o6 DHCP 4o6 219 Client Server 220 | | 221 | DHCPv6 - DHCPV4-QUERY message containing | 222 | OPTION_ORO(6) listing (90, TBD1) | 223 Step 1 |----------------------------------------------------->| 224 | DHCPv4 - DHCPDISCOVER message | 225 | | 226 | | 227 | DHCPv6 - DHCPV4-RESPONSE message containing | 228 | OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) | 229 | (bind-ipv6-prefix with service provider's | 230 | preferred prefix) | 231 Step 2 |<-----------------------------------------------------| 232 | DHCPv4 - DHCPOFFER message | 233 | containing an available IPv4 address | 234 | | 235 | DHCPv6 - DHCPV4-QUERY message | 236 Step 3 |----------------------------------------------------->| 237 | DHCPv4 - DHCPREQUEST message containing the | 238 | requested IPv4 address and OPTION_DHCP4O6_S46_SADDR | 239 | (softwire-ipv6-src-address with client's bound | 240 | IPv6 softwire source address) | 241 | | 242 | | 243 | DHCPv6 - DHCPV4-RESPONSE message | 244 Step 4 |<-----------------------------------------------------| 245 | DHCPv4 - DHCPACK message containing | 246 | the leased IPv4 address and OPTION_DHCP4O6_S46_SADDR | 247 | (softwire-ipv6-src-address with client's bound | 248 | IPv6 softwire source address) | 249 | | 251 Figure 1: IPv6/IPv4 Binding Message Flow 253 Step 1 The client constructs a DHCPv6 'DHCPV4-QUERY(20)' message. 254 This message contains two options: DHCPv6 OPTION_ORO (6) and 255 OPTION_DHCPV4_MSG (87). OPTION_ORO lists '90' 256 (OPTION_S46_BR) and 'TBD1' (OPTION_S46_BIND_IPV6_PREFIX). 257 OPTION_DHCPV4_MSG contains a DHCPv4 DHCPDISCOVER message. 259 Step 2 The server responds with a DHCPv6 'DHCPV4-RESPONSE (21)' 260 message. This message contains an OPTION_S46_BR (90) 261 containing the IPv6 address of the BR for the client's 262 softwire configuration. The message may also optionally 263 contain OPTION_S46_BIND_IPV6_PREFIX (TBD1). 264 OPTION_DHCPV4_MSG contains a DHCPv4 DHCPOFFER message. The 265 DHCPv4 message contains an available IPv4 address. 267 Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message 268 containing a DHCPv4 DHCPREQUEST message with the requested 269 IPv4 address and OPTION_DHCP4O6_S46_SADDR (TBD2) with the 270 IPv6 address which the client will use as its softwire source 271 address. 273 Step 4 The server sends a DHCPv6 'DHCPV4-RESPONSE (21)' message. 274 OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message with the 275 allocated IPv4 address. OPTION_DHCP4O6_S46_SADDR with the 276 client's bound softwire source address is included. 278 6. DHCP Options 280 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option 282 The format of DHCPv6 Source Binding Prefix hint option is as follows: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | OPTION_S46_BIND_IPV6_PREFIX | option-length | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |bindprefix6-len| | 290 +-+-+-+-+-+-+-+-+ bind-ipv6-prefix . 291 . (variable length) . 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Format of OPTION_S46_BIND_IPV6_PREFIX 296 o option-code: OPTION_S46_BIND_IPV6_PREFIX (TBD1) 297 o option-length: 1 + length of bind-ipv6-prefix, specified in bytes. 298 o bindprefix6-len: 8-bit field expressing the bit mask length of the 299 IPv6 prefix specified in bind-ipv6-prefix. Valid values are 0 to 300 128. 301 o bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix 302 for the client to bind the received IPv4 configuration to. The 303 length is (bindprefix6-len + 7) / 8. The field is padded on the 304 right with zero bits up to the next octet boundary when bind- 305 ipv6-prefix is not evenly divisible by 8. These padding bits are 306 ignored by the receiver (see Section 7.4). 308 OPTION_S46_BIND_IPV6_PREFIX is a singleton. Servers MUST NOT send 309 more than one instance of the OPTION_S46_BIND_IPV6_PREFIX option. 311 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option 313 The format of DHCPv4 over DHCPv6 softwire source address option is as 314 follows: 316 0 1 317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 318 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 319 | option-code | option-length | 320 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 321 + softwire-ipv6-src-address + 322 . (128 bits) . 323 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 325 Format of OPTION_DHCP4O6_S46_SADDR 327 o option-code: OPTION_DHCP4O6_S46_SADDR (TBD2) 328 o option-length: 16. 329 o softwire-ipv6-src-address: 16 bytes long; The IPv6 address that is 330 associated (either being requested for binding or currently bound) 331 with the client's IPv4 configuration. 333 NB - The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the 334 DHCPv4 message's 'chaddr' field, or the Client Identifier (61) option 335 in that it provides a lower-layer address which is unique that the 336 server can use for identifying the client. However, as both of these 337 are required to remain constant throughout the address lease 338 lifetime, they cannot be used with the mechanism described in this 339 document. This is because the client may only be able to construct 340 the IPv6 address to use as the source address after it has received 341 the first DHCPV4-RESPONSE message from the server containing 342 OPTION_S46_BIND_IPV6_PREFIX. 344 7. Client Behavior 346 A client requiring dynamic softwire configuration first enables DHCP 347 4o6 configuration using the method described in Section 5 of 348 [RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the 349 corresponding REPLY message, the client MAY continue with the 350 configuration process described below. 352 Before the dynamic softwire configuration process can commence, the 353 client MUST be configured with a suitable IPv6 prefix to be used as 354 the local softwire endpoint. This could be obtained using DHCPv6, 355 RA/PIO or another mechanism. 357 7.1. Client Initialization 359 When constructing the initial DHCP 4o6 DHCPDISCOVER message, the 360 client includes a DHCPv6 OPTION_ORO (6) within the options field of 361 the DHCP-QUERY message. OPTION_ORO contains the option codes for 362 OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (TBD1). 364 On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE 365 containing a DHCPOFFER message), the client checks the contents of 366 the DHCPv4-RESPONSE for the presence of a valid OPTION_S46_BR option. 367 If this option is not present, or does not contain at least one valid 368 IPv6 address for a BR, then the client MUST discard the message, as 369 without the address of the BR the client cannot configure the 370 softwire and so has no interface to request IPv4 configuration for. 372 The DHCPV4-RESPONSE message may also include 373 OPTION_S46_BIND_IPV6_PREFIX, which is used by the operator to 374 indicate a preferred prefix that the client should use to bind IPv4 375 configuration to. If received, the client first checks the option 376 according to Section 7.4. If valid, the client uses this prefix as 377 the 'IPv6 binding prefix' and follows to the process described in 378 Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to 379 construct the softwire. If no match is found, or the client doesn't 380 receive OPTION_S46_BIND_IPV6_PREFIX the client MAY select any valid 381 IPv6 prefix (of a suitable scope) to use as the tunnel source. 383 Once the client has selected a suitable prefix, it MAY use either an 384 existing IPv6 address that is already configured on an interface, or 385 create a new address specifically for use as the softwire source 386 address (e.g., using an Interface Identifier constructed as per 387 Section 6 of [RFC7597]). If a new address is being created, the 388 client MUST complete configuration of the new address, performing 389 duplicate address detection (if required) before proceeding. 391 The client then constructs a DHCPV4-QUERY message containing a DHCPv4 392 DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is included in the 393 options field of the DHCPREQUEST message with the IPv6 address of its 394 softwire source address in the softwire-ipv6-src-address field. 396 When the client receives a DHCPv4 DHCPACK message from the server, it 397 checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its 398 active softwire source address. If they match, the allocation 399 process has concluded. If there is a discrepancy then the process 400 described in Section 7.5 is followed. 402 If the client receives a DHCPv4 DHCPNAK message from the server, then 403 the configuration process has been unsuccessful. The client then 404 restarts the process from Step 1 of Figure 1. 406 7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source 407 Address 409 Whenever the client attempts to extend the lease time of the IPv4 410 address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its 411 softwire source address in the softwire-ipv6-src-address field MUST 412 be included in the DHCPREQUEST message. 414 7.2.1. Changing the Bound IPv6 Softwire Source Address 416 Across the lifetime of the leased IPv4 address, it is possible that 417 the client's IPv6 address will change, e.g., if there is an IPv6 re- 418 numbering event. 420 In this situation, the client MUST inform the server of the new 421 address. This is done by sending a DHCPREQUEST message containing 422 OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address. 424 When the client receives a DHCPv4 DHCPACK message from the server, it 425 checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its 426 active softwire source address. If they match, the allocation 427 process has concluded. If there is a discrepancy then the process 428 described in Section 7.5 is followed. 430 If the client receives a DHCPv4 DHCPNAK message in response from the 431 server, then the change of the bound IPv6 Softwire source address has 432 been unsuccessful. In this case, the client MUST stop using the new 433 IPv6 source address. The client then restarts the process from Step 434 1 of Figure 1. 436 7.3. Releasing the IPv4 Address Lease and Softwire Source Address 438 When the client no longer requires the IPv4 resource, it sends a 439 DHCPv4 DHCPRELEASE message to the server. As the options field is 440 unused in this message type, OPTION_DHCP4O6_S46_SADDR is not 441 included. 443 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior 445 On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client 446 makes the following validation checks: 448 o The received bindprefix6-len value is not larger than 128. 449 o The number of bytes received in the bind-ipv6-prefix field is 450 consistent with the received bindprefix6-len value (calculated as 451 described in Section 6.1). 453 If either check fails, the receiver discards the invalid option and 454 proceeds to attempt configuration as if the option had not been 455 received. 457 The receiver MUST only use bits from the bind-ipv6-prefix field up to 458 the value specified in the bindprefix6-len when performing the 459 longest prefix match. bind-ipv6-prefix bits beyond this value MUST be 460 ignored. 462 7.5. Client and Server Softwire Source Address Mismatch 464 If the client receives a DHCPACK message with an 465 OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which differs 466 from its active softwire source address, the client SHOULD wait for a 467 randomized time interval and then resend the DHCPREQUEST message with 468 the correct softwire source address. [RFC2131] Section 4.1 descibes 469 the retransmission backoff interval process. 471 The default minimum time for the client to attempt retransmission is 472 60 seconds. If, after this time has expired, the client has not 473 received a DHCPACK message with the correct bound IPv6 address, 474 client MAY send a DHCPRELEASE message and re-start the process 475 described in Section 7. The re-try interval should be configurable 476 and aligned with any server policy defining the minimum time interval 477 for client address updates as described in Section 8.1. 479 7.6. Use With Dynamic, Shared IPv4 Addresses 481 [RFC7618] describes a mechanism for using DHCPv4 to distribute 482 dynamic, shared IPv4 addresses to clients. The mechanism described 483 in this document is compatible with IPv4 address sharing, and can be 484 enabled by following the process described in Section 6 of [RFC7618]. 486 8. Server Behavior 488 Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the 489 server MUST also store the IPv6 softwire source address of the client 490 in the leasing address database, alongside the IPv4 address and 491 client identifier. 493 An OPTION_DHCP4O6_S46_SADDR containing the bound softwire source 494 address MUST be sent in every DHCPACK message sent by the server. 496 The binding entry between the client's IPv6 softwire source address 497 and the leased IPv4 address is valid as long as the IPv4 lease 498 remains valid. 500 8.1. Changing the Bound IPv6 Source Address 502 In the event that the server receives a DHCPREQUEST message for an 503 active IPv4 lease containing a OPTION_DHCP4O6_S46_SADDR with an IPv6 504 address which differs from the address which is currently stored, the 505 server updates the stored softwire source address with the new 506 address supplied by the client, and sends a DHCPACK message 507 containing the updated softwire source address in 508 OPTION_DHCP4O6_S46_SADDR. 510 The server MAY implement a policy enforcing a minimum time interval 511 between a client updating its softwire source IPv6 address. If a 512 client attempts to update the softwire source IPv6 address before the 513 minimum time has expired, the server can either silently drop the 514 client's message or send back a DHCPACK message containing the 515 existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. If 516 implemented, the default minimum client source address update 517 interval is 60 seconds. 519 8.2. Handling Conflicts Between Client's Bound IPv6 Source Addresses 521 In order for traffic to be forwarded correctly, each CE's softwire 522 IPv6 source addresses must be unique. To ensure this, on receipt of 523 every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR, 524 the DHCP 4o6 server MUST check the received IPv6 address against all 525 existing CE source addresses stored for active client IPv4 leases. 526 If there is a match for any active lease other than the lease 527 belonging to the client sending the DHCPREQUEST, then the client's 528 IPv6 source address MUST NOT be stored or updated. 530 Depending on where the client and server are in the address leasing 531 lifecycle, the DHCP 4o6 server then takes the following action: 533 o If the DHCP 4o6 does not have a current, active IPv4 address lease 534 for the client, then the DHCP address allocation process has not 535 been succesful. The server returns a DHCPNAK message to the 536 client. 537 o If the DHCP 4o6 does have a current, active IPv4 address lease, 538 then the source address update process (see Section 8.1) has not 539 been successful. The DHCP 4o6 server can either silently drop the 540 client's message or return a DHCPACK message containing the 541 existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. 543 9. Security Considerations 545 Security considerations which are applicable to [RFC7341] are also 546 applicable here. 548 A rogue client could attempt to use the mechanism described in 549 Section 7.2.1 to redirect IPv4 traffic intended for another client to 550 itself. This would be performed by sending a DHCPREQUEST message for 551 another client's active IPv4 lease containing the attacker's softwire 552 IPv6 address in OPTION_DHCP4O6_S46_SADDR. 554 For such an attack to be effective, the attacker would need to know 555 both the client identifier and active IPv4 address lease currently in 556 use by another client. This could be attempted in three ways: 558 1. One customer learning the active IPv4 address lease and client 559 identifier of another customer via snooping the DHCP4o6 message 560 flow between the client and server. The mechanism described in 561 this document is intended for use in a typical ISP network 562 topology with a dedicated layer-2 access network per-client, 563 meaning that snooping of another client's traffic is not 564 possible. If the access network is a shared medium then 565 provisioning softwire clients using dynamic DHCP4o6 as described 566 here is NOT RECOMMENDED. 567 2. Learning the active IPv4 address lease and client identifier via 568 snooping the DHCP4o6 message flow between the client and server 569 in the aggregation or core ISP network. In this case, the 570 attacker requires a level of access to the ISP's infrastructure 571 that means they can already intercept or interfere with traffic 572 flows to the client. 573 3. An attacker could attempt to brute-force guessing the IPv4 lease 574 address and client identifier tuple. The risk of this can be 575 reduced by using a client identifier format which is not easily 576 guessable, e.g., by using a random based client identifier (see 577 [RFC7844] Section 3.5). 579 An attacker could attempt to redirect existing flows to a client 580 unable to process the traffic. This type of attack can be prevented 581 by implementing [BCP38] network ingress filtering in conjunction with 582 the BR source address validation processes described in [RFC7596] 583 Section 5.2 and [RFC7597] Section 8.1. 585 A client may attempt to overload the server by sending multiple 586 source address update messages (see Section 7.2.1) in a short time 587 frame. This risk can be reduced by implementing a server policy 588 enforcing a minimum time interval between client address changes as 589 described in Section 8.1. 591 9.1. Client Privacy Considerations 593 [RFC7844] describes anonymity profiles for DHCP clients. These 594 considerations and recommendations are also applicable to clients 595 implementing the mechanism described in this document. As DHCP4o6 596 only uses DHCPv6 as a stateless transport for DHCPv4 messages, the 597 "Anonymity Profile for DHCPv4" described in Section 3 is most 598 relevant here. 600 In addition to the considerations given in [RFC7844], the mechanism 601 that the client uses for constructing the interface identifier for 602 its IPv6 softwire source address (see Section 7.1), could result in 603 the device being trackable across different networks and sessions, 604 e.g., if the client's softwire Interface Identifier (IID) is 605 immutable. 607 This can be mitigated by constructing the softwire source IPv6 608 address as per Section 6 of [RFC7597]. Here, the address' IID 609 contains only the allocated IPv4 address (and port set identifier if 610 [RFC7618] is being used). This means no additional client 611 information is exposed to the DHCP4o6 server, and will also mean that 612 the IID will change as the leased IPv4 address changes (e.g., between 613 sessions when Section 3.5 of [RFC7844] is implemented). 615 10. IANA Considerations 617 IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX (TBD1) 618 option code from the DHCPv6 "Option Codes" registry maintained at 619 http://www.iana.org/assignments/dhcpv6-parameters and use the 620 following data when adding the option to the registry: 622 Value: TDB1 623 Description: OPTION_S46_BIND_IPV6_PREFIX 624 Client ORO: Yes 625 Singleton Option: Yes 626 Reference: this document 628 IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR (TBD2) 629 option code from the "BOOTP Vendor Extensions and DHCP Options" 630 registry maintained at http://www.iana.org/assignments/bootp-dhcp- 631 parameters and use the following data when adding the option to the 632 registry: 634 Value: TDB2 635 Name: OPTION_DHCP4O6_S46_SADDR 636 Data Length: 16 637 Meaning: DHCPv4 over DHCPv6 Softwire Source Address Option 638 Reference: this document 640 IANA is requested to update the entry for DHCPv6 Option S46_BR (90) 641 in the Option Codes table maintained at 642 https://www.iana.org/assignments/dhcpv6-parameters as follows: 644 Old Entry: 646 Value: 90 647 Description: OPTION_S46_BR 648 Client ORO: No 649 Singleton Option: No 650 Reference: [RFC7598] 652 New Entry: 654 Value: 90 655 Description: OPTION_S46_BR 656 Client ORO: Yes 657 Singleton Option: No 658 Reference: [RFC7598], this document 660 11. Acknowledgements 662 The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei, 663 Jonas Gorski and Razvan Becheriu for their contributions and 664 comments. 666 12. References 668 12.1. Normative References 670 [I-D.ietf-dhc-rfc3315bis] 671 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 672 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 673 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 674 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 675 April 2018. 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, 679 DOI 10.17487/RFC2119, March 1997, 680 . 682 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 683 RFC 2131, DOI 10.17487/RFC2131, March 1997, 684 . 686 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 687 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 688 RFC 7341, DOI 10.17487/RFC7341, August 2014, 689 . 691 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 692 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 693 Configuration of Softwire Address and Port-Mapped 694 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 695 . 697 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 698 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 699 May 2017, . 701 12.2. Informative References 703 [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of 704 Service Attacks which employ IP Source Address Spoofing 705 https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. 707 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 708 Defeating Denial of Service Attacks which employ IP Source 709 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 710 May 2000, . 712 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 713 Farrer, "Lightweight 4over6: An Extension to the Dual- 714 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 715 July 2015, . 717 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 718 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 719 Port with Encapsulation (MAP-E)", RFC 7597, 720 DOI 10.17487/RFC7597, July 2015, 721 . 723 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 724 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 725 RFC 7618, DOI 10.17487/RFC7618, August 2015, 726 . 728 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 729 Profiles for DHCP Clients", RFC 7844, 730 DOI 10.17487/RFC7844, May 2016, 731 . 733 Authors' Addresses 734 Ian Farrer 735 Deutsche Telekom AG 736 CTO-ATI, Landgrabenweg 151 737 Bonn, NRW 53227 738 Germany 740 Email: ian.farrer@telekom.de 742 Qi Sun 743 Tsinghua University 744 Beijing 100084 745 P.R. China 747 Phone: +86-10-6278-5822 748 Email: sunqi.ietf@gmail.com 750 Yong Cui 751 Tsinghua University 752 Beijing 100084 753 P.R. China 755 Phone: +86-10-6260-3059 756 Email: yong@csnet1.cs.tsinghua.edu.cn 758 Linhui Sun 759 Tsinghua University 760 Beijing 100084 761 P.R. China 763 Phone: +86-10-6278-5822 764 Email: lh.sunlinh@gmail.com