idnits 2.17.1 draft-ietf-dhc-dhcp4o6-saddr-opt-06.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 (October 5, 2018) is 2002 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 (==), 2 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: April 8, 2019 L. Sun 7 Tsinghua University 8 October 5, 2018 10 Softwire Provisioning using DHCPv4 Over DHCPv6 11 draft-ietf-dhc-dhcp4o6-saddr-opt-06 13 Abstract 15 DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically 16 configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 17 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms 18 and deployment scenarios (e.g., RFC7596 or RFC7597), the operator 19 needs to know the IPv6 address that the client will use as the s 20 ource of IPv4-in-IPv6 softwire tunnel. This address, in conjunction 21 with the client's IPv4 address, and (in some deployments) the Port 22 Set ID are used to create a binding table entry in the operator's 23 softwire tunnel concentrator. This memo defines a DHCPv6 option to 24 convey IPv6 parameters for establishing the softwire tunnel and a 25 DHCPv4 option (to be used only with DHCP 4o6) to communicate the 26 source tunnel IPv6 address between the DHCP 4o6 client and server. 27 It is designed to work in conjunction with the IPv4 address 28 allocation process. 30 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped 31 Clients (RFC7598) describes a deterministic DHCPv6 based mechanism 32 for provisioning softwires. This document updates "DHCPv6 Options 33 for Configuration of Softwire Address and Port-Mapped Clients" 34 (RFC7598), allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 35 client's Option Request Option (ORO) request and appear directly 36 within subsequent messages sent by the DHCPv6 server. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 8, 2019. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 75 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 76 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 4 77 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 5 78 6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7 79 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7 80 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option . . . . 7 81 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 82 7.1. Client Initialization . . . . . . . . . . . . . . . . . . 8 83 7.2. Renewing or Rebinding the IPv4 Address Lease and 84 Softwire Source Address . . . . . . . . . . . . . . . . . 9 85 7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10 86 7.3. Releasing the IPv4 Address Lease and Softwire 87 Source Address . . . . . . . . . . . . . . . . . . . . . 10 88 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 10 89 7.5. Client and Server Softwire Source Address Mismatch . . . 11 90 7.6. Use With Dynamic, Shared IPv4 Addresses . . . . . . . . . 11 91 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 92 8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 11 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 98 12.2. Informative References . . . . . . . . . . . . . . . . . 14 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 101 1. Introduction 103 Deterministic IPv4-over-IPv6 transition technologies require that 104 elements are pre-configured with binding rules for routing traffic to 105 clients. This places a constraint on the choice of address used as 106 the client's softwire source address: it must use a pre-determined 107 prefix which is usually configured on the home gateway device. 108 [RFC7598] describes a DHCPv6 based mechanism for provisioning such 109 deterministic softwires. 111 A dynamic provisioning model, such as using DHCPv4 over DHCPv6 112 [RFC7341] (DHCP 4o6) allows much more flexibility in the location of 113 the IPv4-over-IPv6 softwire source address. In this model, the IPv6 114 address is dynamically communicated back to the service provider 115 allowing the corresponding softwire configuration to be created in 116 the border router (BR). 118 The DHCP 4o6 client and softwire client could be run on end devices 119 attached to a network segment using any routable IPv6 prefix 120 allocated to an end-user, located anywhere within an arbitrary home 121 network topology. Dynamic allocation also helps to optimize IPv4 122 resource usage as only clients which are actively renewing their IPv4 123 lease hold on to the address. 125 This document describes a mechanism for dynamically provisioning 126 softwires created using DHCP 4o6, including provisioning the client 127 with the address of the softwire border router (BR) and informing the 128 service provider of client's binding between the dynamically 129 allocated IPv4 address and Port Set ID and the IPv6 address that the 130 softwire Initiator will use for accessing IPv4-over-IPv6 services. 132 The mechanism operates alongside the DHCP 4o6 message flows to 133 communicate the binding information over the IPv6-only network. The 134 DHCP 4o6 server provides a single point in the network which holds 135 the current client binding information. The service provider can 136 then use this binding information to provision other functional 137 elements, such as the BR(s). 139 2. Applicability 141 The mechanism described in this document is only suitable for use for 142 provisioning softwire clients via DHCP 4o6. The options described 143 here are only applicable within the DHCP 4o6 message exchange 144 process. Current softwire technologies suitable for extending to 145 incorporate DHCP 4o6 with dynamic IPv4 address leasing include 146 [RFC7597] and [RFC7596]. 148 3. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 4. Solution Overview 156 In order to provision a softwire, both IPv6 and IPv4 configuration 157 needs to be passed to the client. To map this to the DHCP 4o6 158 configuration process, the IPv6 configuration is carried in DHCPv6 159 options [I-D.ietf-dhc-rfc3315bis], carried inside the DHCPv6 message 160 DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used 161 to provision the remote IPv6 address for the softwire border router 162 (see Section 4.1 below). OPTION_S46_BIND_IPV6_PREFIX (TBD1), is 163 optionally sent by the DHCP 4o6 server to indicate to the client a 164 preferred IPv6 prefix for binding the received IPv4 configuration and 165 sourcing tunnel traffic. This may be necessary if there are multiple 166 IPv6 prefixes in use in the customer network (e.g., Unique Local 167 Addresses (ULAs)), or if the specific IPv4-over-IPv6 transition 168 mechanism requires the use of a particular prefix for any reason. 170 IPv4 configuration is carried in DHCPv4 messages [RFC2131], (inside 171 the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism 172 described in [RFC7341]. 174 In order for the client to communicate the softwire source address, a 175 new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (TBD2) is defined in this 176 document. This is included in DHCPREQUEST messages sent by the 177 client and is stored by the server for the lifetime of the IPv4 178 address lease. 180 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 182 Section 4.2 of [RFC7598] defines option OPTION_S46_BR(90) for 183 communicating remote softwire border relay (BR) IPv6 address(es) to a 184 client, but mandates that the option can only be used when 185 encapsulated within one of the softwire container options: 186 OPTION_S46_CONT_MAPE (94) or OPTION_S46_CONT_LW(96). From Section 3 187 of [RFC7598]: 189 "Softwire46 DHCPv6 clients that receive provisioning options that 190 are not encapsulated in container options MUST silently ignore 191 these options." 193 This document updates [RFC7598], removing this restriction for 194 OPTION_S46_BR (90), allowing it to be enumerated in the client's ORO 195 request and appear directly within subsequent messages sent by the 196 DHCPv6 server. 198 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow 200 The following diagram shows the relevant extensions to the successful 201 DHCP 4o6 IPv4 allocation client/server message flow for the softwire 202 source address function. The full process, including error handling 203 is described in Section 7. 205 In each step, the DHCPv6 portion of the message and any relevant 206 option is shown above the arrow. The DHCP 4o6 content of the message 207 and its relevant options are below the arrow. All the DHCPv4 208 messages are encapsulated in DHCPV4-QUERY (20) or DHCPV4-RESPONSE 209 (21) messages. Where relevant, the necessary options and their 210 contents are shown. 212 DHCP 4o6 DHCP 4o6 213 Client Server 214 | | 215 | DHCPv6 - DHCPV4-QUERY message containing | 216 | OPTION_ORO(6) listing (90, TBD1) | 217 Step 1 |----------------------------------------------------->| 218 | DHCPv4 - DHCPDISCOVER message | 219 | | 220 | | 221 | DHCPv6 - DHCPV4-RESPONSE message containing | 222 | OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) | 223 | (bind-ipv6-prefix with service provider's | 224 | preferred prefix) | 225 Step 2 |<-----------------------------------------------------| 226 | DHCPv4 - DHCPOFFER message | 227 | | 228 | | 229 | DHCPv6 - DHCPV4-QUERY message | 230 Step 3 |----------------------------------------------------->| 231 | DHCPv4 - DHCPREQUEST message containing | 232 | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | 233 | with client's bound IPv6 softwire source address) | 234 | | 235 | | 236 | DHCPv6 - DHCPV4-RESPONSE message | 237 Step 4 |<-----------------------------------------------------| 238 | DHCPv4 - DHCPACK message containing | 239 | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | 240 | with client's bound IPv6 softwire source address) | 241 | | 243 Figure 1: IPv6/IPv4 Binding Message Flow 245 Step 1 The client constructs a DHCPv6 'DHCPV4-QUERY(20)' message. 246 This message contains two options: DHCPv6 OPTION_ORO (6) and 247 OPTION_DHCPV4_MSG (87). OPTION_ORO lists '90' 248 (OPTION_S46_BR) and 'TBD1' (OPTION_S46_BIND_IPV6_PREFIX). 249 OPTION_DHCPV4_MSG contains a DHCPv4 DHCPDISCOVER message. 251 Step 2 The server responds with a DHCPv6 'DHCPV4-RESPONSE (21)' 252 message. This message contains OPTION_S46_BR (90) containing 253 the IPv6 address of the BR for the client's softwire 254 configuration. The message may also optionally contain 255 OPTION_S46_BIND_IPV6_PREFIX (TBD1). OPTION_DHCPV4_MSG 256 contains a DHCPv4 DHCPOFFER message. 258 Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message 259 containing a DHCPv4 DHCPREQUEST message with 260 OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6 address which 261 the client will use as its softwire source address. 263 Step 4 The server sends a DHCPv6 'DHCPV4-RESPONSE (21)' message. 264 OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message. 265 OPTION_DHCP4O6_S46_SADDR with the client's softwire source 266 address is included. 268 6. DHCP Options 270 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option 272 The format of DHCPv6 Source Binding Prefix hint option is as follows: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | OPTION_S46_BIND_IPV6_PREFIX | option-length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |bindprefix6-len| | 280 +-+-+-+-+-+-+-+-+ bind-ipv6-prefix . 281 . (variable length) . 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Format of OPTION_S46_BIND_IPV6_PREFIX 286 o option-code: OPTION_S46_BIND_IPV6_PREFIX (TBD1) 287 o option-length: 1 + length of bind-ipv6-prefix, specified in bytes. 288 o bindprefix6-len: 8-bit field expressing the bit mask length of the 289 IPv6 prefix specified in bind-ipv6-prefix. Valid values are 0 to 290 128. 291 o bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix 292 for the client to bind the received IPv4 configuration to. The 293 length is (bindprefix6-len + 7) / 8. The field is padded on the 294 right with zero bits up to the next octet boundary when bind- 295 ipv6-prefix is not evenly divisible by 8. These padding bits are 296 ignored by the receiver (see Section 7.4). 298 OPTION_S46_BIND_IPV6_PREFIX is a singleton. Servers MUST NOT send 299 more than one instance of the OPTION_S46_BIND_IPV6_PREFIX option. 301 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option 303 The format of DHCPv4 over DHCPv6 softwire source address option is as 304 follows: 306 0 1 307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 308 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 309 | option-code | option-length | 310 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 311 + softwire-ipv6-src-address + 312 . (128 bits) . 313 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 315 Format of OPTION_DHCP4O6_S46_SADDR 317 o option-code: OPTION_DHCP4O6_S46_SADDR (TBD2) 318 o option-length: 16. 319 o softwire-ipv6-src-address: 16 bytes long; The IPv6 address that is 320 associated (either being requested for binding or currently bound) 321 with the client's IPv4 configuration. 323 NB - The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the 324 DHCPv4 message's 'chaddr' field, or the Client Identifier (61) option 325 in that it provides a lower-layer address which is unique that the 326 server can use for identifying the client. However, as both of these 327 are required to remain constant throughout the address lease 328 lifetime, they cannot be used with the mechanism described in this 329 document. This is because the client may only be able to construct 330 the IPv6 address to use as the source address after it has received 331 the first DHCPV4-RESPONSE message from the server containing 332 OPTION_S46_BIND_IPV6_PREFIX. 334 7. Client Behavior 336 A client requiring dynamic softwire configuration first enables DHCP 337 4o6 configuration using the method described in Section 5 of 338 [RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the 339 corresponding REPLY message, the client MAY continue with the 340 configuration process described below. 342 It is also a prerequisite that the client has already learned a 343 suitable IPv6 prefix to use for its local softwire endpoint using 344 DHCPv6, RA/PIO or another mechanism. 346 7.1. Client Initialization 348 When constructing the initial DHCP 4o6 DHCPDISCOVER message, the 349 client includes a DHCPv6 OPTION_ORO (6) within the options field of 350 the DHCP-QUERY message. OPTION_ORO contains the option codes for 351 OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (TBD1). 353 On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE 354 containing a DHCPOFFER message), the client checks the contents of 355 the DHCPv4-RESPONSE for the presence of a valid OPTION_S46_BR option. 356 If this option is not present, or does not contain at least one valid 357 IPv6 address for a BR, then the client MUST discard the message, as 358 without the address of the BR the client cannot configure the 359 softwire and so has no interface to request IPv4 configuration for. 361 The DHCPV4-RESPONSE message may also include 362 OPTION_S46_BIND_IPV6_PREFIX, which is used by the operator to 363 indicate a preferred prefix that the client should use to bind IPv4 364 configuration to. If received, the client first checks the option 365 according to Section 7.4. If valid, the client uses this prefix as 366 the 'IPv6 binding prefix' and follows to the process described in 367 Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to 368 construct the softwire. If no match is found, or the client doesn't 369 receive OPTION_S46_BIND_IPV6_PREFIX the client MAY select any valid 370 IPv6 prefix (of a suitable scope) to use as the tunnel source. 372 Once the client has selected a suitable prefix, it MAY use either an 373 existing IPv6 address that is already configured on an interface, or 374 create a new address specifically for use as the softwire source 375 address (e.g., using an Interface Identifier constructed as per 376 Section 6 of [RFC7597]). If a new address is being created, the 377 client MUST complete configuration of the new address, performing 378 duplicate address detection (if required) before proceeding. 380 The client then constructs a DHCPV4-QUERY message containing a DHCPv4 381 DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is included in the 382 options field of the DHCPREQUEST message with the IPv6 address of its 383 softwire source address in the softwire-ipv6-src-address field. 385 When the client receives a DHCPv4 DHCPACK message from the server, it 386 checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its 387 active softwire source address. If they match, the allocation 388 process has concluded. If there is a discrepancy then the process 389 described in Section 7.5 is followed. 391 If the client receives a DHCPv4 DHCPNAK message from the server, then 392 the configuration process has been unsuccessful. The client then 393 restarts the process from Step 1 of Figure 1. 395 7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source 396 Address 398 Whenever the client attempts to extend the lease time of the IPv4 399 address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its 400 softwire source address in the softwire-ipv6-src-address field MUST 401 be included in the DHCPREQUEST message. 403 7.2.1. Changing the Bound IPv6 Softwire Source Address 405 Across the lifetime of the leased IPv4 address, it is possible that 406 the client's IPv6 will change. E.g., if there is an IPv6 re- 407 numbering event. 409 In this situation, the client MUST inform the server of the new 410 address. This is done by sending a DHCPREQUEST message containing 411 OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address. 413 When the client receives a DHCPv4 DHCPACK message from the server, it 414 checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its 415 active softwire source address. If they match, the allocation 416 process has concluded. If there is a discrepancy then the process 417 described in Section 7.5 is followed. 419 If the client receives a DHCPv4 DHCPNAK message in response from the 420 server, then the change of the bound IPv6 Softwire source address has 421 been unsuccessful. In this case, the client MUST stop using the new 422 IPv6 source address. The client then restarts the process from Step 423 1 of Figure 1. 425 7.3. Releasing the IPv4 Address Lease and Softwire Source Address 427 When the client no longer requires the IPv4 resource, it sends a 428 DHCPv4 DHCPRELEASE message to the server. As the options field is 429 unused in this message type, OPTION_DHCP4O6_S46_SADDR is not 430 included. 432 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior 434 On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client 435 makes the following validation checks: 437 o The received bindprefix6-len value is not larger than 128. 438 o The number of bytes received in the bind-ipv6-prefix field is 439 consistent with the received bindprefix6-len value (calculated as 440 described in Section 6.1). 442 If either check fails, the receiver discards the invalid option and 443 proceeds to attempt configuration as if the option had not been 444 received. 446 The receiver MUST only use bits from the bind-ipv6-prefix field up to 447 the value specified in the bindprefix6-len when performing the 448 longest prefix match. bind-ipv6-prefix bits beyond this value MUST be 449 ignored. 451 7.5. Client and Server Softwire Source Address Mismatch 453 If the client receives a DHCPACK message with an 454 OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which differs 455 from its active softwire source address, the client SHOULD wait for a 456 randomized time interval and then resend the DHCPREQUEST message with 457 the correct softwire source address. [RFC2131] Section 4.1 descibes 458 the retransmission backoff interval process. 460 The default minimum time for the client to attempt retransmission is 461 60 seconds. If, after this time has expired, the client has not 462 received a DHCPACK message with the correct bound IPv6 address, 463 client MAY send a DHCPRELEASE message and re-start the process 464 described in Section 7. The re-try interval should be configurable 465 and aligned with any server policy defining the minimum time interval 466 for client address updates as described in Section 8.1. 468 7.6. Use With Dynamic, Shared IPv4 Addresses 470 [RFC7618] describes a mechanism for using DHCPv4 to distribute 471 dynamic, shared IPv4 addresses to clients. The mechanism described 472 in this document is compatible with IPv4 address sharing, and can be 473 enabled by following the process described in Section 6 of [RFC7618]. 475 8. Server Behavior 477 Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the 478 server MUST also store the IPv6 softwire source address of the client 479 in the leasing address database, alongside the IPv4 address and 480 client identifier. An OPTION_DHCP4O6_S46_SADDR containing the bound 481 softwire source address MUST be sent in every DHCPACK message sent by 482 the server. 484 The binding entry between the client's IPv6 softwire source address 485 and the leased IPv4 address is valid as long as the IPv4 lease 486 remains valid. 488 8.1. Changing the Bound IPv6 Source Address 490 In the event that the server receives a DHCPREQUEST message for an 491 active IPv4 lease containing a OPTION_DHCP4O6_S46_SADDR with an IPv6 492 address which differs from the address which is currently stored, the 493 server updates the stored softwire source address with the new 494 address supplied by the client, and sends a DHCPACK message 495 containing the updated softwire source address in 496 OPTION_DHCP4O6_S46_SADDR. 498 The server MAY implement a policy enforcing a minimum time interval 499 between a client updating its softwire source IPv6 address. If a 500 client attempts to update the softwire source IPv6 address before the 501 minimum time has expired, the server can either silently drop the 502 client's message or send back a DHCPACK message containing the 503 existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. If 504 implemented, the default minimum client source address update 505 interval is 60 seconds. 507 9. Security Considerations 509 Security considerations which are applicable to [RFC7341] are also 510 applicable here. 512 A rogue client could attempt to use the mechanism described in 513 Section 7.2.1 to redirect IPv4 traffic intended for another client to 514 itself. This would be performed by sending a DHCPREQUEST message for 515 another client's active IPv4 lease containing the attacker's softwire 516 IPv6 address in OPTION_DHCP4O6_S46_SADDR. 518 For such an attack to be effective, the attacker would need to know 519 both the client identifier and active IPv4 address lease currently in 520 use by another client. The risk of this can be reduced by using a 521 client identifier format which is not easily guessable, e.g., by 522 including a time component for when the client identifier was 523 generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2). 525 A client may attempt to overload the server by sending multiple 526 source address update messages (see Section 7.2.1) in a short time 527 frame. This risk can be reduced by implementing a server policy 528 enforcing a minimum time interval between client address changes as 529 described in Section 8.1. 531 10. IANA Considerations 533 IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX (TBD1) 534 option code from the DHCPv6 "Option Codes" registry maintained at 535 http://www.iana.org/assignments/dhcpv6-parameters. 537 IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR (TBD2) 538 option code from the "BOOTP Vendor Extensions and DHCP Options" 539 registry maintained at http://www.iana.org/assignments/bootp-dhcp- 540 parameters. 542 IANA is requested to update the entry for DHCPv6 Option S46_BR (90) 543 in the Option Codes table at https://www.iana.org/assignments/ 544 dhcpv6-parameters as follows: 546 Old entry: 548 | 90 | S46_BR | No | No | 550 New entry: 552 | 90 | S46_BR | Yes | No | 554 IANA is also requested to make a new entry for 555 OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at 556 https://www.iana.org/assignments/dhcpv6-parameters: 558 | TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes | Yes | 560 11. Acknowledgements 562 The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei, 563 Jonas Gorski and Razvan Becheriu for their contributions and 564 comments. 566 12. References 568 12.1. Normative References 570 [I-D.ietf-dhc-rfc3315bis] 571 Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 572 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 573 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 574 bis", draft-ietf-dhc-rfc3315bis-13 (work in progress), 575 April 2018. 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, 579 DOI 10.17487/RFC2119, March 1997, 580 . 582 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 583 RFC 2131, DOI 10.17487/RFC2131, March 1997, 584 . 586 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 587 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 588 RFC 7341, DOI 10.17487/RFC7341, August 2014, 589 . 591 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 592 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 593 Configuration of Softwire Address and Port-Mapped 594 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 595 . 597 12.2. Informative References 599 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 600 Farrer, "Lightweight 4over6: An Extension to the Dual- 601 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 602 July 2015, . 604 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 605 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 606 Port with Encapsulation (MAP-E)", RFC 7597, 607 DOI 10.17487/RFC7597, July 2015, 608 . 610 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 611 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 612 RFC 7618, DOI 10.17487/RFC7618, August 2015, 613 . 615 Authors' Addresses 617 Ian Farrer 618 Deutsche Telekom AG 619 CTO-ATI, Landgrabenweg 151 620 Bonn, NRW 53227 621 Germany 623 Email: ian.farrer@telekom.de 625 Qi Sun 626 Tsinghua University 627 Beijing 100084 628 P.R. China 630 Phone: +86-10-6278-5822 631 Email: sunqi.ietf@gmail.com 632 Yong Cui 633 Tsinghua University 634 Beijing 100084 635 P.R. China 637 Phone: +86-10-6260-3059 638 Email: yong@csnet1.cs.tsinghua.edu.cn 640 Linhui Sun 641 Tsinghua University 642 Beijing 100084 643 P.R. China 645 Phone: +86-10-6278-5822 646 Email: lh.sunlinh@gmail.com