idnits 2.17.1 draft-ietf-dhc-dhcp4o6-saddr-opt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2018) is 2221 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 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: September 28, 2018 L. Sun 7 Tsinghua University 8 March 27, 2018 10 Softwire Provisioning using DHCPv4 Over DHCPv6 11 draft-ietf-dhc-dhcp4o6-saddr-opt-03 13 Abstract 15 DHCPv4 over DHCPv6 is a mechanism for dynamically configuring IPv4 16 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with 17 some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the 18 operator needs to know the IPv6 address that the client will use as 19 the source of IPv4-in-IPv6 softwire tunnel. This address, in 20 conjunction with the client's IPv4 address and (in some deployments), 21 the Port Set ID are used to create a binding table entry in the 22 operator's softwire tunnel concentrator. This memo defines a DHCPv6 23 option to convey IPv6 parameters for establishing the softwire tunnel 24 and a DHCPv4 option (to be used only with DHCP 4o6) to communicate 25 the source tunnel IPv6 address between the DHCP 4o6 client and 26 server. It is designed to work in conjunction with the IPv4 address 27 allocation process. This document updates "DHCPv6 Options for 28 Configuration of Softwire Address and Port-Mapped Clients" to allow 29 the DHCPv6 option OPTION_S46_BR (90) to appear outside of DHCPv6 30 softwire container options. 32 This document updates RFC7598, allowing OPTION_S46_BR (90) to be 33 enumerated in the DHCPv6 client's ORO request and appear directly 34 within subsequent messages sent by the DHCPv6 server. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 28, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 73 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 74 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 4 75 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 5 76 6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7 78 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option . . . . 7 79 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 80 7.1. Client Initialization . . . . . . . . . . . . . . . . . . 8 81 7.2. Renewing or Rebinding the IPv4 Address Lease and 82 Softwire Source Address . . . . . . . . . . . . . . . . . 9 83 7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10 84 7.3. Releasing the IPv4 Address Lease and Softwire 85 Source Address . . . . . . . . . . . . . . . . . . . . . 10 86 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 10 87 7.5. Client and Server Softwire Source Address Mismatch . . . 11 88 7.6. Use With Dynamic, Shared IPv4 Addresses . . . . . . . . . 11 89 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 11 90 8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 11 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 96 12.2. Informative References . . . . . . . . . . . . . . . . . 13 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 99 1. Introduction 101 Deterministic IPv4-over-IPv6 transition technologies require that 102 elements are pre-configured with binding rules for routing traffic to 103 clients. This places a constraint on the choice of address used as 104 the client's softwire source address: it must use a pre-determined 105 prefix which is usually configured on the home gateway device. 106 [RFC7597] describes a DHCPv6 based mechanism for provisioning such 107 deterministic softwires. 109 A dynamic provisioning model, such as using DHCPv4 over DHCPv6 110 [RFC7341] (DHCP 4o6) allows much more flexibility in the location of 111 the IPv4-over-IPv6 softwire source address. In this model, the IPv6 112 address is dynamically communicated back to the service provider 113 allowing the corresponding softwire configuration to be created in 114 the border router (BR). 116 The DHCP 4o6 client and softwire client could be run on end devices 117 attached to any routable IPv6 prefix allocated to an end-user, 118 located anywhere within an arbitrary home network topology. Dynamic 119 allocation also helps to optimize IPv4 resource usage as only clients 120 which are actively renewing their IPv4 lease hold on to the address. 122 This document describes a mechanism for dynamically provisioning 123 softwires created using DHCP 4o6, including provisioning the client 124 with the address of the softwire border router (BR) and informing the 125 service provider of client's binding between the dynamically 126 allocated IPv4 address and Port Set ID and the IPv6 address that the 127 softwire Initiator will use for accessing IPv4-over-IPv6 services. 129 The mechanism operates alongside the DHCP 4o6 message flows to 130 communicate the binding information over the IPv6-only network. The 131 DHCP 4o6 server provides a single point in the network which holds 132 the current client binding information. The service provider can 133 then use this binding information to provision other functional 134 elements, such as the BR(s). 136 2. Applicability 138 The mechanism described in this document is only suitable for use for 139 provisioning softwire clients via DHCP 4o6. The options described 140 here are only applicable within the DHCP 4o6 message exchange 141 process. Current softwire technologies suitable for extending to 142 incorporate DHCP 4o6 with dynamic IPv4 address leasing include 143 [RFC7597] and [RFC7596]. 145 3. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 4. Solution Overview 153 In order to provision a softwire, both IPv6 and IPv4 configuration 154 needs to be passed to the client. To map this to the DHCP 4o6 155 configuration process, the IPv6 configuration is carried in DHCPv6 156 options carried inside the DHCPv6 message DHCPV4-RESPONSE (21) sent 157 by the server. OPTION_S46_BR (90) is used to provision the remote 158 IPv6 address for the softwire (see Section 4.1 below). 159 OPTION_S46_BIND_IPV6_PREFIX (TBD1), is optionally sent by the DHCP 160 4o6 server to indicate to the client a preferred IPv6 prefix for 161 binding the received IPv4 configuration and sourcing tunnel traffic. 162 This may be necessary if there are multiple IPv6 prefixes in use in 163 the customer network (e.g. ULAs), or if the specific IPv4-over-IPv6 164 transition mechanism requires the use of a particular prefix for any 165 reason. 167 IPv4 configuration is carried in DHCPv4 messages (inside the DHCP 4o6 168 option OPTION_DHCPV4_MSG (87)) using the mechanism described in 169 [RFC7341]. 171 In order for the client to communicate the softwire source address, a 172 new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (TBD2) is defined in this 173 document. This is included in DHCPREQUEST messages sent by the 174 client and is stored by the server for the lifetime of the IPv4 175 address lease. 177 4.1. Updating RFC7598 to Permit the Reuse of OPTION_S46_BR(90) 179 Section 4.2 of [RFC7598] defines option OPTION_S46_BR(90) for 180 communicating remote softwire border relay (BR)'s' IPv6 address(es) 181 to a client, but mandates that the option can only be used when 182 encapsulated within one of the softwire container options: 183 OPTION_S46_CONT_MAPE (94) or OPTION_S46_CONT_LW(96). From Section 3 184 of [RFC7598]: 186 "Softwire46 DHCPv6 clients that receive provisioning options that 187 are not encapsulated in container options MUST silently ignore 188 these options." 190 This document updates [RFC7598], removing this restriction for 191 OPTION_S46_BR (90), allowing it to be enumerated in the client's ORO 192 request and appear directly within subsequent messages sent by the 193 DHCPv6 server. 195 5. DHCP 4o6 IPv6/IPv4 Binding Message Flow 197 The following diagram shows the relevant extensions to the successful 198 DHCP 4o6 IPv4 allocation client/server message flow for the softwire 199 source address function. The full process, including error handling 200 is described in Section 7. 202 In each step, the DHCPv6 portion of the message and any relevant 203 option is shown above the arrow. The DHCP 4o6 content of the message 204 and its relevant options are below the arrow. All the DHCPv4 205 messages are encapsulated in DHCPV4-QUERY (20) or DHCPV4-RESPONSE 206 (21) messages. Where relevant, the necessary options and their 207 contents are shown. 209 DHCP 4o6 DHCP 4o6 210 Client Server 211 | | 212 | DHCPv6 - DHCPV4-QUERY message containing | 213 | OPTION_ORO(6) listing (90, TBD1) | 214 Step 1 |----------------------------------------------------->| 215 | DHCPv4 - DHCPDISCOVER message | 216 | | 217 | | 218 | DHCPv6 - DHCPV4-RESPONSE message containing | 219 | OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(TDB1) | 220 | (bind-ipv6-prefix with service provider's | 221 | preferred prefix) | 222 Step 2 |<-----------------------------------------------------| 223 | DHCPv4 - DHCPOFFER message | 224 | | 225 | | 226 | DHCPv6 - DHCPV4-QUERY message | 227 Step 3 |----------------------------------------------------->| 228 | DHCPv4 - DHCPREQUEST message containing | 229 | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | 230 | with client's bound IPv6 softwire source address) | 231 | | 232 | | 233 | DHCPv6 - DHCPV4-RESPONSE message | 234 Step 4 |<-----------------------------------------------------| 235 | DHCPv4 - DHCPACK message containing | 236 | OPTION_DHCP4O6_S46_SADDR (softwire-ipv6-src-address | 237 | with client's bound IPv6 softwire source address) | 238 | | 240 Figure 1: IPv6/IPv4 Binding Message Flow 242 Step 1 The client constructs a DHCPv6 'DHCPV4-QUERY(20)' message. 243 This message contains two options: DHCPv6 OPTION_ORO (6) and 244 OPTION_DHCPV4_MSG (87). OPTION_ORO lists '90' 245 (OPTION_S46_BR) and 'TBD1' (OPTION_S46_BIND_IPV6_PREFIX). 246 OPTION_DHCPV4_MSG contains a DHCPv4 DHCPDISCOVER message. 248 Step 2 The server responds with a DHCPv6 'DHCPV4-RESPONSE (21)' 249 message. This message contains OPTION_S46_BR (90) containing 250 the IPv6 address of the BR for the client's softwire 251 configuration. The message may also, optionally contain 252 OPTION_S46_BIND_IPV6_PREFIX (TBD1). OPTION_DHCPV4_MSG 253 contains a DHCPv4 DHCPOFFER message. 255 Step 3 The client sends with a DHCPv6 'DHCPV4-QUERY(20)' message 256 containing a DHCPv4 DHCPREQUEST message with 257 OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6 address which 258 the client will use as its softwire source address. 260 Step 4 The server sends a DHCPv6 'DHCPV4-RESPONSE(21)' message. 261 OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message. 262 OPTION_DHCP4O6_S46_SADDR with the client's softwire source 263 address is included. 265 6. DHCP Options 267 6.1. DHCPv6 Softwire Source Binding Prefix Hint Option 269 The format of DHCPv6 Source Binding Prefix hint option is as follows: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | OPTION_S46_BIND_IPV6_PREFIX | option-length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |bindprefix6-len| | 277 +-+-+-+-+-+-+-+-+ bind-ipv6-prefix . 278 . (variable length) . 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Format of OPTION_S46_BIND_IPV6_PREFIX 283 o option-code: OPTION_S46_BIND_IPV6_PREFIX (TBD1) 284 o option-length: 1 + length of bind-ipv6-prefix, specified in bytes. 285 o bindprefix6-len: 8-bit field expressing the bit mask length of the 286 IPv6 prefix specified in bind-ipv6-prefix. Valid values are 0 to 287 128. 288 o bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix 289 for the client to bind the received IPv4 configuration to. The 290 length is (bindprefix6-len + 7) / 8. The field is padded on the 291 right with zero bits up to the next octet boundary when bind- 292 ipv6-prefix is not evenly divisible by 8. 294 OPTION_S46_BIND_IPV6_PREFIX is a singleton. Servers MUST NOT send 295 more than one instance of the OPTION_S46_BIND_IPV6_PREFIX option. 297 6.2. DHCPv4 over DHCPv6 Softwire Source Address Option 299 The format of DHCPv4 over DHCPv6 softwire source address option is as 300 follows: 302 0 1 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 304 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 305 | option-code (TBD) | option-length | 306 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 307 + softwire-ipv6-src-address + 308 . (128 bits) . 309 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 311 Format of OPTION_DHCP4O6_S46_SADDR 313 o option-code: OPTION_DHCP4O6_S46_SADDR (TBD2) 314 o option-length: 16. 315 o softwire-ipv6-src-address: 16 bytes long; The IPv6 address that is 316 associated (either being requested for binding or currently bound) 317 with the client's IPv4 configuration. 319 NB - The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the 320 DHCPv4 message's 'chaddr' field, or the Client Identifier (61) option 321 in that it provides a lower-layer address which is unique that the 322 server can use for identifying the client. However, as both of these 323 are required to remain constant throughout the address lease 324 lifetime, they cannot be used with the mechanism described in this 325 document. This is because the client may only be able to construct 326 the IPv6 address to use as the source address after it has received 327 the first DHCPV4-RESPONSE message from the server containing 328 OPTION_S46_BIND_IPV6_PREFIX. 330 7. Client Behavior 332 A client requiring dynamic softwire configuration first enables DHCP 333 4o6 configuration using the method described in Section 5. of 334 [RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the 335 corresponding REPLY message, the client MAY continue with the 336 configuration process described below. 338 It is also a prerequisite that the client has already learned a 339 suitable IPv6 prefix to use for its local softwire endpoint using 340 DHCPv6, RA/PIO or another mechanism. 342 7.1. Client Initialization 344 When constructing the initial DHCP 4o6 DHCPDISCOVER message, the 345 client includes a DHCPv6 OPTION_ORO (6) within the options field of 346 the DHCP-QUERY message. OPTION_ORO contains the option codes for 347 OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (TBD1). 349 On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE 350 containing a DHCPOFFER message), the client checks the contents of 351 the DHCPv4-RESPONSE for the presence of a valid OPTION_S46_BR option. 352 If this option is not present, or does not contain at least one valid 353 IPv6 address for a BR, then the client MUST discard the message, as 354 without the address of the BR the client cannot configure the 355 softwire and so has no interface to request IPv4 configuration for. 357 The DHCPV4-RESPONSE message may also include 358 OPTION_S46_BIND_IPV6_PREFIX, which is used by the operator to 359 indicate a preferred prefix that the client should use to bind IPv4 360 configuration to. If received, the client first checks the option 361 according to Section 7.4. If valid, the client uses this prefix as 362 the 'IPv6 binding prefix' and follows to the process described in 363 Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to 364 construct the softwire. If no match is found, or the client doesn't 365 receive OPTION_S46_BIND_IPV6_PREFIX the client MAY select any valid 366 IPv6 prefix (of a suitable scope) to use as the tunnel source. 368 Once the client has selected a suitable prefix, it MAY use either an 369 existing IPv6 address that is already configured on an interface, or 370 create a new address specifically for use as the softwire source 371 address (e.g. using an Interface Identifier constructed as per 372 Section 6. of [RFC7597]). If a new address is being created, the 373 client MUST complete configuration of the new address, performing 374 duplicate address detection (if required) before proceeding. 376 The client then constructs a DHCPV4-QUERY message containing a DHCPv4 377 DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is included in the 378 options field of the DHCPREQUEST message with the IPv6 address of its 379 softwire source address in the softwire-ipv6-src-address field. 381 When the client receives a DHCPv4 DHCPACK message from the server, it 382 checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its 383 active softwire source address. If they match, the allocation 384 process has concluded. If there is a discrepancy then the process 385 described in Section 7.5 is followed. 387 If the client receives a DHCPv4 DHCPNAK message from the server, then 388 the configuration process has been unsuccessful. The client then 389 restarts the process from Step 1 of Figure 1. 391 7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source 392 Address 394 Whenever the client attempts to extend the lease time of the IPv4 395 address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its 396 softwire source address in the softwire-ipv6-src-address field MUST 397 be included in the DHCPREQUEST message. 399 7.2.1. Changing the Bound IPv6 Softwire Source Address 401 Across the lifetime of the leased IPv4 address, it is possible that 402 the client's IPv6 will change. E.g. if there is a flash IPv6 re- 403 numbering event. 405 In this situation, the client MUST inform the server of the new 406 address. This is done by sending a DHCPREQUEST message containing 407 OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address. 409 When the client receives a DHCPv4 DHCPACK message from the server, it 410 checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its 411 active softwire source address. If they match, the allocation 412 process has concluded. If there is a discrepancy then the process 413 described in Section 7.5 is followed. 415 If the client receives a DHCPv4 DHCPNAK message in repsonse from the 416 server, then the change of the bound IPv6 Softwire source address has 417 been unsuccessful. In this case, the client MUST stop using the new 418 IPv6 source address. The client then restarts the process from Step 419 1 of Figure 1. 421 7.3. Releasing the IPv4 Address Lease and Softwire Source Address 423 When the client no longer requires the IPv4 resource, it sends a 424 DHCPv4 DHCPRELEASE message to the server. As the options field is 425 unused in this message type, OPTION_DHCP4O6_S46_SADDR is not 426 included. 428 7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior 430 On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client 431 makes the following validation checks: 433 o The received bindprefix6-len value is not larger than 128. 434 o The received bindprefix6-len value is not larger than the number 435 of bytes sent in the bind-ipv6-prefix field. (e.g. the 436 bindprefix6-len is 128 but the bind-ipv6-prefix has only 8 bytes). 438 For either of these cases the receiver MAY either discard the option 439 and proceed to attempt configuration as if the option had not been 440 received, or attempt to use the received values for the longest 441 prefix match anyway. 443 The receiver MUST only use bits from the bind-ipv6-prefix field up to 444 the value specified in the bindprefix6-len when performing the 445 longest prefix match. bind-ipv6-prefix bits beyond this value MUST be 446 ignored. 448 7.5. Client and Server Softwire Source Address Mismatch 450 If the client receives a DHCPACK message with an 451 OPTION_DHCP4O6_S46_SADDR containing an IPv6 address which differs 452 from its active softwire source address, the client MAY either: 454 o Wait for a randomised time interval and then resend a DHCPREQUEST 455 message with the correct softwire source address, OR 456 o Send a DHCPRELEASE message and re-start the process described in 457 Section 7. 459 7.6. Use With Dynamic, Shared IPv4 Addresses 461 [RFC7618]describes a mechanism for using DHCPv4 to distribute 462 dynamic, shared IPv4 addresses to clients. The mechanism described 463 in this document is compatible with IPv4 address sharing, and can be 464 enabled by following the process described in Section 6 of [RFC7618]. 466 8. Server Behavior 468 Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the 469 server MUST also store the IPv6 softwire source address of the client 470 in the leasing address database, alongside the IPv4 address and 471 client identifier. An OPTION_DHCP4O6_S46_SADDR containing the bound 472 softwire source address MUST be sent in every DHCPACK message sent by 473 the server. 475 The binding entry between the client's IPv6 softwire source address 476 and the leased IPv4 address is valid as long as the IPv4 lease 477 remains valid. 479 8.1. Changing the Bound IPv6 Source Address 481 In the event that the server receives a DHCPREQUEST message for an 482 active IPv4 lease containing a OPTION_DHCP4O6_S46_SADDR with an IPv6 483 address which differs from the address which is currently stored, the 484 server updates the stored softwire source address with the new 485 address supplied by the client, and sends a DHCPACK message 486 containing the updated softwire source address in 487 OPTION_DHCP4O6_S46_SADDR. 489 The server MAY implement a policy enforcing a minimum time interval 490 between a client updating its softwire source IPv6 address. If a 491 client attempts to update the softwire source IPv6 address before the 492 minimum time has expired, the server can either silently drop the 493 client's message or send back a DHCPACK message containing the 494 exisiting IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. 496 9. Security Considerations 498 Security considerations which are applicable to [RFC7341] are also 499 applicable here. 501 10. IANA Considerations 503 IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR option code 504 from the "BOOTP Vendor Extensions and DHCP Options" registry 505 maintained at http://www.iana.org/assignments/bootp-dhcp-parameters. 507 IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX option 508 code from the DHCPv6 "Option Codes" registry maintained at 509 http://www.iana.org/assignments/dhcpv6-parameters. 511 IANA is requested to update the entry for DHCPv6 Option S46_BR (90) 512 in the table at https://www.iana.org/assignments/dhcpv6-parameters as 513 follows: 515 Old entry: 517 | 90 | S46_BR | No | No | 519 New entry: 521 | 90 | S46_BR | Yes | No | 523 IANA is also requested to make a new entry for 524 OPTION_S46_BIND_IPV6_PREFIX TBD1) in the table at 525 https://www.iana.org/assignments/dhcpv6-parameters: 527 | TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes | Yes | 529 11. Acknowledgements 531 The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei, 532 Jonas Gorski and Razvan Becheriu for their contributions and 533 comments. 535 12. References 537 12.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 545 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", 546 RFC 7341, DOI 10.17487/RFC7341, August 2014, 547 . 549 12.2. Informative References 551 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 552 Farrer, "Lightweight 4over6: An Extension to the Dual- 553 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 554 July 2015, . 556 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 557 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 558 Port with Encapsulation (MAP-E)", RFC 7597, 559 DOI 10.17487/RFC7597, July 2015, 560 . 562 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 563 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 564 Configuration of Softwire Address and Port-Mapped 565 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 566 . 568 [RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. 569 Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", 570 RFC 7618, DOI 10.17487/RFC7618, August 2015, 571 . 573 Authors' Addresses 575 Ian Farrer 576 Deutsche Telekom AG 577 CTO-ATI, Landgrabenweg 151 578 Bonn, NRW 53227 579 Germany 581 Email: ian.farrer@telekom.de 582 Qi Sun 583 Tsinghua University 584 Beijing 100084 585 P.R. China 587 Phone: +86-10-6278-5822 588 Email: sunqi.csnet.thu@gmail.com 590 Yong Cui 591 Tsinghua University 592 Beijing 100084 593 P.R. China 595 Phone: +86-10-6260-3059 596 Email: yong@csnet1.cs.tsinghua.edu.cn 598 Linhui Sun 599 Tsinghua University 600 Beijing 100084 601 P.R. China 603 Phone: +86-10-6278-5822 604 Email: lh.sunlinh@gmail.com