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