idnits 2.17.00 (12 Aug 2021) /tmp/idnits16461/draft-ietf-dhc-dhcpv4-over-dhcpv6-09.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 (June 11, 2014) is 2894 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) == Outdated reference: draft-ietf-dhc-dhcpv6-unknown-msg has been published as RFC 7283 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-softwire-lw4over6 has been published as RFC 7596 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Q. Sun 3 Internet-Draft Y. Cui 4 Intended status: Standards Track Tsinghua University 5 Expires: December 13, 2014 M. Siodelski 6 ISC 7 S. Krishnan 8 Ericsson 9 I. Farrer 10 Deutsche Telekom AG 11 June 11, 2014 13 DHCPv4 over DHCPv6 Transport 14 draft-ietf-dhc-dhcpv4-over-dhcpv6-09 16 Abstract 18 IPv4 connectivity is still needed as networks migrate towards IPv6. 19 Users require IPv4 configuration even if the uplink to their service 20 provider supports IPv6 only. This document describes a mechanism for 21 obtaining IPv4 configuration information dynamically in IPv6 networks 22 by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 23 messages and two new DHCPv6 options are defined for this purpose. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 13, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 64 6. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 6 66 6.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 6 67 6.3. DHCPv4-query Message Flags . . . . . . . . . . . . . . . 7 68 6.4. DHCPv4-response Message Flags . . . . . . . . . . . . . . 7 69 7. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. DHCPv4 Message Option Format . . . . . . . . . . . . . . 7 71 7.2. 4o6 Server Address Option Format . . . . . . . . . . . . 8 72 8. Use of the DHCPv4-query Unicast Flag . . . . . . . . . . . . 9 73 9. DHCP 4o6 Client Behavior . . . . . . . . . . . . . . . . . . 10 74 10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 12 75 11. DHCP 4o6 Server Behavior . . . . . . . . . . . . . . . . . . 12 76 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 14. Contributors List . . . . . . . . . . . . . . . . . . . . . . 14 79 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 15.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 As the migration towards IPv6 continues, IPv6-only networks will 87 become more prevalent. In such networks, IPv4 connectivity will 88 continue to be provided as a service over IPv6-only networks. In 89 addition to provisioning IPv4 addresses for clients of this service, 90 other IPv4 configuration parameters may also be needed (e.g. 91 addresses of IPv4-only services). 93 This document describes a transport mechanism to carry DHCPv4 94 messages using the DHCPv6 protocol for the dynamic provisioning of 95 IPv4 addresses and other DHCPv4 specific configuration parameters 96 across IPv6-only networks. It leverages the existing DHCPv4 97 infrastructure, e.g. failover, DNS updates, DHCP Leasequery, etc. 99 When IPv6 multicast is used to transport 4o6 messages, another 100 benefit is that the operator can gain information about the 101 underlying IPv6 network the 4o6 client is connected to from the the 102 DHCPv6 relay agents the request has passed through. 104 2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Terminology 112 This document makes use of the following terms: 114 CPE: Customer Premises Equipment (also 115 known as Customer Provided 116 Equipment), which provides access for 117 devices connected to a Local Area 118 Network (typically at the customer's 119 site/home) to the Internet Service 120 Provider's network. 122 DHCP 4o6 client (or client): A DHCP client supporting both the 123 DHCPv6 protocol [RFC3315] as well as 124 the DHCPv4 over DHCPv6 protocol 125 described in this document. Such a 126 client is capable of requesting IPv6 127 configuration using DHCPv6 and IPv4 128 configuration using DHCPv4 over 129 DHCPv6. 131 DHCP 4o6 server (or server): A DHCP server that is capable of 132 processing DHCPv4 packets 133 encapsulated in the DHCPv4 Message 134 option (defined below). 136 DHCPv4 over DHCPv6: A protocol described in this 137 document, used to carry DHCPv4 138 messages in the payload of DHCPv6 139 messages. 141 4. Applicability 143 The mechanism described in this document is not universally 144 applicable. This is intended as a special-purpose mechanism that 145 will be implemented on nodes that must obtain IPv4 configuration 146 information using DHCPv4 in specific environments where native DHCPv4 147 is not available. Such nodes are expected to follow the advice in 148 the "client behavior" section; nodes that do not require this 149 functionality are expected not to implement it, or not to enable it 150 by default. This mechanism may be enabled using an administrative 151 control, or may be enabled automatically in accordance with the needs 152 of some dual-stack transition mechanism such as 153 [I-D.ietf-softwire-lw4over6]. Such mechanisms are beyond the scope 154 of this document. 156 5. Architecture Overview 158 The architecture described here addresses a typical use case, where a 159 DHCP client's uplink supports IPv6 only and the Service Provider's 160 network supports IPv6 and limited IPv4 services. In this scenario, 161 the client can only use the IPv6 network to access IPv4 services, so 162 IPv4 services must be configured using IPv6 as the underlying network 163 protocol. 165 Although the purpose of this document is to address the problem of 166 communication between the DHCPv4 client and the DHCPv4 server, the 167 mechanism that it describes does not restrict the transported 168 messages types to DHCPv4 only. As the DHCPv4 message is a special 169 type of BOOTP message, BOOTP messages [RFC0951] MAY also be 170 transported using the same mechanism. 172 DHCP clients may be running on CPE devices, end hosts or any other 173 device that supports the DHCP client function. This document uses 174 the CPE as an example for describing the mechanism. This does not 175 preclude any end-host, or other device requiring IPv4 configuration, 176 from implementing DHCPv4 over DHCPv6 in the future. 178 This mechanism works by carrying DHCPv4 messages encapsulated within 179 the newly defined DHCPv6 messages. The DHCPv6 relay encapsulation is 180 used solely to deliver DHCPv4 packets to a DHCPv4-capable server, and 181 do not allocate any IPv6 addresses nor provide IPv6 configuration 182 information to the client. Figure 1, below, illustrates one possible 183 deployment architecture of this mechanism. 185 The DHCP 4o6 client implements a new DHCPv6 message called 186 DHCPv4-query, which contains a new option called the DHCPv4 Message 187 option encapsulating a DHCPv4 message sent by the client. The format 188 of this option is described in Section 7.1. 190 The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents 191 or directly to the DHCP 4o6 server. The server replies with a 192 DHCPv4-response message, which is a new DHCPv6 message carrying the 193 DHCPv4 response encapsulated in the DHCPv4 Message option. 195 _____________ _____________ 196 / \ / \ 197 | | | | 198 +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ 199 | DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 | 200 | client +---------+ Relay Agent +---------+ Server | 201 | (on CPE) | | | | | 202 +--------+-+ +-+-----------+-+ +-+--------+ 203 | | | | 204 \_____________/ \_____________/ 206 Figure 1: Architecture Overview 208 Before the client can use DHCPv4 over DHCPv6, it MUST obtain the 209 necessary IPv6 configuration. The client requests the 4o6 Server 210 Address option from the server by sending the option code in Option 211 Request option as described in [RFC3315]. If the server responds 212 with the 4o6 Server Address option, it is an indication to the client 213 to attempt using DHCPv4 over DHCPv6 to obtain IPv4 configuration. 214 Otherwise, the client MUST NOT use DHCPv4 over DHCPv6 to request IPv4 215 configuration. 217 The client obtains the address(es) of the DHCP 4o6 server(s) from the 218 4o6 Server Address option and uses them to communicate with the DHCP 219 4o6 servers as described in Section 9. If the 4o6 Server Address 220 option contains no addresses (is empty), the client uses the well- 221 known All_DHCP_Relay_Agents_and_Servers multicast address to 222 communicate with the DHCP 4o6 server(s). 224 Before applying for an IPv4 address via a DHCPv4-query message, the 225 client must identify a suitable network interface for the address. 226 Once the request is acknowledged by the server, the client can 227 configure the address and other relevant parameters on this 228 interface. The mechanism for determining a suitable interface is out 229 of the scope of the document. 231 6. New DHCPv6 Messages 233 Two new DHCPv6 messages carry DHCPv4 messages between the client and 234 the server using the DHCPv6 protocol: DHCPv4-query and 235 DHCPv4-response. This section describes the structures of these 236 messages. 238 6.1. Message Types 240 DHCPV4-QUERY (TBD): The DHCP 4o6 client sends a DHCPv4-query 241 message to a DHCP 4o6 server. The DHCPv4 242 Message option carried by this message 243 contains a DHCPv4 message that the DHCP 4o6 244 client uses to request IPv4 configuration 245 parameters from the server. 247 DHCPv4-RESPONSE (TBD): A DHCP 4o6 server sends a DHCPv4-response 248 message to a DHCP 4o6 client. It contains a 249 DHCPv4 Message option carrying a DHCPv4 250 message in response to a DHCPv4 message 251 received by the server in the DHCPv4 Message 252 option of the DHCPv4-query message. 254 6.2. Message Formats 256 Both DHCPv6 messages defined in this document share the following 257 format: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | msg-type | flags | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 . options . 266 . (variable) . 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 2: The format of DHCPv4-query and DHCPv4-response messages 272 msg-type Identifies the message type. It can be either 273 DHCPV4-QUERY (TBD) or DHCPV4-RESPONSE (TBD) 274 corresponding to the contained DHCPv4-query or 275 DHCPv4-response, respectively. 277 flags Specifies flags providing additional information 278 required by the server to process the DHCPv4 message 279 encapsulated in the DHCPv4-query message, or required 280 by the client to process a DHCPv4 message 281 encapsulated in the DHCPv4-response message. 283 options Options carried by the message. The DHCPv4 Message 284 Option (described in Section 7.1) MUST be carried by 285 the message. Only DHCPv6 options for IPv4 286 configuration may be included in this field. It MUST 287 NOT contain DHCPv6 options related solely to IPv6, or 288 IPv6-only service configuration. 290 6.3. DHCPv4-query Message Flags 292 The "flags" field of the DHCPv4-query is used to carry additional 293 information that may be used by the server to process the 294 encapsulated DHCPv4 message. Currently only one bit of this field is 295 used. Remaining bits are reserved for the future use. The "flags" 296 field has the following format: 298 0 1 2 299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |U| MBZ | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 3: DHCPv4-query flags format 306 U Unicast Flag. If set to 1, it indicates that the 307 DHCPv4 message encapsulated within the DHCPv4-query 308 message would be sent to a unicast address if it was 309 sent using IPv4. If this flag is set to 0, it 310 indicates that the DHCPv4 message would be sent to 311 the broadcast address if it was sent using IPv4. The 312 usage of the flag is described in detail in 313 Section 8. 315 MBZ Bits MUST be set to zero when sending and MUST be 316 ignored when receiving. 318 6.4. DHCPv4-response Message Flags 320 This document introduces no flags to be carried in the "flags" field 321 of the DHCPv4-response message. They are all reserved for the future 322 use. The DHCP 4o6 server MUST set all bits of this field to 0 and 323 the DHCP 4o6 client MUST ignore the content in this field. 325 7. New DHCPv6 Options 327 7.1. DHCPv4 Message Option Format 329 The DHCPv4 Message option carries a DHCPv4 message that is sent by 330 the client or the server. Such messages exclude any IP or UDP 331 headers. 333 The format of the DHCPv4 Message option is: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | option-code | option-len | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 . DHCPv4-message . 342 . . 343 . . 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 4: DHCPv4 Message option Format 348 option-code OPTION_DHCPV4_MSG (TBD). 350 option-len Length of the DHCPv4 message. 352 DHCPv4-message The DHCPv4 message sent by the client or the server. 353 In a DHCPv4-query message it contains a DHCPv4 354 message sent by a client. In a DHCPv4-response 355 message it contains a DHCPv4 message sent by a server 356 in response to a client. 358 7.2. 4o6 Server Address Option Format 360 The 4o6 Server Address option is sent by a server to a client 361 requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a 362 list of DHCP 4o6 servers' IPv6 addresses that the client should 363 contact to obtain IPv4 configuration. This list may include 364 multicast and unicast addresses. The client sends its requests to 365 all unique addresses carried in this option. 367 This option may also carry no IPv6 addresses, which instructs the 368 client to use the All_DHCP_Relay_Agents_and_Servers multicast address 369 as the destination address. 371 The presence of this option in the server's response indicates to the 372 client that it should use DHCPv4 over DHCPv6 to obtain IPv4 373 configuration. If the option is absent, the client MUST NOT enable 374 DHCPv4-over-DHCPv6 function. 376 The format of the 4o6 Server Address option is: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | option-code | option-len | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 . IPv6 Address(es) . 385 . . 386 . . 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 5: 4o6 Servers Address Option Format 391 option-code OPTION_DHCP4_O_DHCP6_SERVER (TBD). 393 option-len Length of the IPv6 address(es) carried by the option, 394 i.e. multiple of 16 octets. Minimal length of this 395 option is 0. 397 IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6 398 Server(s). 400 8. Use of the DHCPv4-query Unicast Flag 402 A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST 403 message to either a broadcast or unicast address depending on its 404 state. For example, a client in the RENEWING state uses a unicast 405 address to contact the DHCPv4 server to renew its lease. A client in 406 the REBINDING state uses a broadcast address. 408 In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the 409 DHCP 4o6 server. There is no relation between the outer IPv6 address 410 and the inner DHCPv4 message. As a result, the server is unable to 411 determine whether the received DHCPv4 messages should have been sent 412 using broadcast or unicast in IPv4 by checking the IPv6 address. 414 In order to allow the server to determine the client's state, the 415 "Unicast" flag is carried in the DHCPv4-query message. The client 416 MUST set this flag to 1 when the DHCPv4 message would have been sent 417 to the unicast address if using DHCPv4 over IPv4. This flag MUST be 418 set to 0 if the DHCPv4 client would have sent the message to the 419 broadcast address in IPv4. The choice whether a given message should 420 be sent to a broadcast or unicast address is made based on the 421 [RFC2131] and its extensions. 423 Note: The "Unicast" flag reflects how the DHCPv4 packet would have 424 been sent; not how the DHCPv6 packet itself is sent. 426 9. DHCP 4o6 Client Behavior 428 The client MUST obtain necessary IPv6 configuration from a DHCPv6 429 server before using DHCPv4 over DHCPv6. The client requests the 4o6 430 Server Address option using Option Request option (ORO) in every 431 Solicit, Request, Renew, Rebind and Information-request message. If 432 the DHCPv6 server includes the 4o6 Server Address option in its 433 response, it is an indication that the client can use DHCPv4 over 434 DHCPv6 to obtain the IPv4 configuration (by sending DHCPv4 messages 435 encapsulated in DHCPv4-query messages). 437 The client MUST NOT use DHCPv4 over DHCPv6 to request IPv4 438 configuration if the DHCPv6 server does not include the 4o6 Server 439 Address option. If the IPv6 configuration that contained the 4o6 440 Server Address option subsequently expires, or if the renewed IPv6 441 configuration does not contain the 4o6 Server Address option, the 442 client MUST stop using DHCPv4 over DHCPv6 to request or renew IPv4 443 configuration. However, the client continues to request 4o6 Server 444 Address option in the messages sent to the DHCPv6 server as long as 445 it desires to use DHCPv4 over DHCPv6. 447 It is possible in a multi-homed configuration for there to be more 448 than one DHCPv6 configuration active at the same time that contains a 449 4o6 Server Address option. In this case, the configurations are 450 treated as being independent, so that when any such configuration is 451 active, a DHCPv4-over-DHCPv6 function may be enabled for that 452 configuration. 454 An implementation may also treat such configurations as being 455 exclusive, such that only one is kept active at a time. In this 456 case, the client keeps the same configuration active continuously as 457 long as it is valid. If that configuration becomes invalid but one 458 or more other configurations remain valid, the client activates one 459 of the remaining valid configurations. 461 Which strategy to follow is dependent on the implementation: keeping 462 multiple configurations active at the same time may provide useful 463 redundancy in some applications, but may be needlessly complex in 464 other cases. 466 If the client receives the 4o6 Server Address option and DHCPv4 467 [RFC2131] is used on the interface over which the DHCPv6 option was 468 received, the client MUST stop using the IPv4 configuration received 469 using DHCPv4 on this interface. The client MAY send a DHCPRELEASE to 470 the DHCPv4 server to relinquish an existing lease as described in 471 [RFC2131] in section 4.4.6. The client MUST NOT use DHCPv4 on this 472 interface as long as it receives 4o6 Server Address option in the 473 messages received from the DHCPv6 server. 475 If the client receives a 4o6 Server Address option that contains no 476 IP addresses, i.e. the option is empty, the client MUST send its 477 requests to the All_DHCP_Relay_Agents_and_Servers multicast address. 478 If there is a list of IP addresses in the option, the client SHOULD 479 send requests to each unique address carried by the option. 481 If the client obtained stateless IPv6 configuration by sending 482 Information-request message to the server, the client MUST follow the 483 rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6 484 configuration (i.e. list of DHCP 4o6 servers) as well as other 485 configuration data. The client which obtained stateful IPv6 486 configuration will refresh the status of DHCPv4-over-DHCPv6 function 487 when extending a lifetime of acquired IPv6 address (Renew and Rebind 488 messages). 490 The client MUST employ an IPv6 address of an appropriate scope to 491 source the DHCPv4-query message from. When the client sends a 492 DHCPv4-query message to the multicast address, it MUST use a link- 493 local address as the source address as described in [RFC3315]. When 494 the client sends a DHCPv4-query message using unicast, the source 495 address MUST be an address of appropriate scope, acquired in advance. 497 The client generates a DHCPv4 message and stores it verbatim in the 498 DHCPv4 Message option carried by the DHCPv4-query message. The 499 client MUST put exactly one DHCPv4 Message option into a single 500 DHCPv4-query message. The client MUST NOT request the 4o6 Server 501 Address option in the DHCPv4-query message. 503 The client MUST follow rules defined in Section 8 when setting the 504 Unicast flag based on the DHCPv4 destination. 506 On receiving a DHCPv4-response message, the client MUST look for the 507 DHCPv4 Message option within this message. If this option is not 508 found, the DHCPv4-response message is discarded. If the DHCPv4 509 Message option is present, the client extracts the DHCPv4 message it 510 contains and processes it as described in section 4.4 of [RFC2131]. 512 When dealing with IPv4 configuration, the client MUST follow the 513 normal DHCPv4 retransmission requirements and strategy as specified 514 in section 4.1 of [RFC2131]. There are no explicit transmission 515 parameters associated with a DHCPv4-query message, as this is 516 governed by the DHCPv4 [RFC2131] "state machine". 518 The client MUST implement [RFC4361] to ensure that the device 519 correctly identifies itself. It MUST send a 'client identifier' 520 option when using DHCPv4 over DHCPv6. 522 10. Relay Agent Behavior 524 When a DHCPv6 relay agent receives a DHCPv4-query message, it may not 525 recognize this message. The unknown message MUST be forwarded as 526 described in [I-D.ietf-dhc-dhcpv6-unknown-msg]. 528 If it recognises the message, the DHCPv6 relay agent MAY allow the 529 configuration of a dedicated DHCPv4 over DHCPv6 specific destination 530 address(es), differing from the address(es) of the DHCPv6-only 531 server(s). To implement this function, the relay checks the received 532 DHCPv6 message type and forwards according to the following logic: 534 1. If the message type is DHCPV4-QUERY, the packet is relayed to the 535 configured DHCP 4o6 Server's address(es) in the form of normal 536 DHCPv6 packet (i.e. DHCPv6/UDP/IPv6). 538 2. For any other DHCPv6 message type, forward according to section 539 20 of [RFC3315]. 541 The above logic only allows for separate relay destinations 542 configured on the relay agent closest to the client (single relay 543 hop). Multiple relaying hops are not considered in the case of 544 separate relay destinations. 546 11. DHCP 4o6 Server Behavior 548 When the server receives a DHCPv4-query message from a client, it 549 searches for the DHCPv4 Message option. The server discards a packet 550 without this option. In addition, the server MAY notify an 551 administrator about the receipt of this malformed packet. The 552 mechanism for this notification is out of scope for this document. 554 If the server finds a valid DHCPv4 Message option, it extracts the 555 original DHCPv4 message. Since the DHCPv4 message is encapsulated in 556 the DHCPv6 message, it lacks the information which is typically used 557 by the DHCPv4 server, implementing [RFC2131], to make address 558 allocation decisions, e.g. giaddr for relayed messages and IPv4 559 address of the interface which the server is using to communicate 560 with directly connected client. Therefore, the DHCP 4o6 server 561 allocates addresses according to the local address assignment 562 policies determined by the server administrator. For example, if the 563 DHCPv4-query message has been sent via a relay, the server MAY use 564 the link-address field of the Relay-forward message as a lookup for 565 the IPv4 subnet to assign DHCPv4 address from. If the DHCPv4-query 566 message has been sent from a directly connected client, the server 567 MAY use IPv6 source address of the message to determine the 568 appropriate IPv4 subnet to use for DHCPv4 address assignment. 570 Alternatively, the server may act as a DHCPv4 relay agent and forward 571 the DHCPv4 packet to a "normal" DHCPv4 server. The details of such a 572 solution have not been considered by the working group; describing 573 that solution is out of scope of this document and is left as future 574 work should the need for it arise. 576 The server SHOULD use the "flags" field of the DHCPv4-query message 577 to create a response (server to client DHCPv4 message). The use of 578 this field is described in detail in Section 8. 580 When an appropriate DHCPv4 response is created, the server places it 581 in the payload of a DHCPv4 Message option, which it puts into the 582 DHCPv4-response message. 584 If the DHCPv4-query message was received directly by the server, the 585 DHCPv4-response message MUST be unicast from the interface on which 586 the original message was received. 588 If the DHCPv4-query message was received in a Relay-forward message, 589 the server creates a Relay-reply message with the DHCPv4-response 590 message in the payload of a Relay Message option, and responds as 591 described in section 20.3 of [RFC3315]. 593 12. Security Considerations 595 In this specification, DHCPv4 messages are encapsulated in the newly 596 defined option and messages. This is similar to the handling of the 597 current relay agent messages. In order to bypass firewalls or 598 network authentication gateways, a malicious attacker may leverage 599 this feature to convey other messages using DHCPv6, i.e. use DHCPv6 600 as a form of encapsulation. However, the potential risk from this is 601 no more severe than that with the current DHCPv4 and DHCPv6 practice. 603 It is possible for a rogue server to reply with a 4o6 Server Address 604 Option containing duplicated IPv6 addresses, which could cause an 605 amplification attack. To avoid this, the client MUST check if there 606 are duplicate IPv6 addresses in a 4o6 Server Address Option when 607 receiving one. The client MUST ignore any but the first instance of 608 each address. 610 When considering whether to enable DHCPv4-over-DHCPv6, one important 611 consideration is that when it is enabled, this gives the DHCPv6 612 server the ability to shut off DHCPv4 traffic, and, consequently, 613 IPv4 traffic, on the interface that is configured to do DHCPv4-over- 614 DHCPv6. For this reason, DHCPv4-over-DHCPv6 should only be enabled 615 in situations where there is a clear trust relationship that 616 eliminates this concern. For instance, a CPE device can safely 617 enable this on its WAN interface, because it is reasonable to assume 618 that an ISP will not accidentally configure DHCPv4 over DHCPv6 619 service on that link, and that it will be impractical for an attacker 620 to set up a rogue DHCPv6 server in the ISP's network. 622 13. IANA Considerations 624 IANA is requested to allocate two DHCPv6 option codes for use by 625 OPTION_DHCPV4_MSG and OPTION_DHCP4_O_DHCP6_SERVER from the "Option 626 Codes" table, and two DHCPv6 message type codes for the DHCPV4-QUERY 627 and DHCPV4-RESPONSE from the "Message Types" table of the Dynamic 628 Host Configuration Protocol for IPv6 (DHCPv6) Registry. Both tables 629 can be found at http://www.iana.org/assignments/dhcpv6-parameters/. 631 14. Contributors List 633 Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Cong Liu and 634 Yuchi Chen, for their great contributions to the specification. 636 15. References 638 15.1. Normative References 640 [I-D.ietf-dhc-dhcpv6-unknown-msg] 641 Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 642 Messages", draft-ietf-dhc-dhcpv6-unknown-msg-08 (work in 643 progress), March 2014. 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 649 2131, March 1997. 651 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 652 and M. Carney, "Dynamic Host Configuration Protocol for 653 IPv6 (DHCPv6)", RFC 3315, July 2003. 655 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 656 Time Option for Dynamic Host Configuration Protocol for 657 IPv6 (DHCPv6)", RFC 4242, November 2005. 659 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 660 Identifiers for Dynamic Host Configuration Protocol 661 Version Four (DHCPv4)", RFC 4361, February 2006. 663 15.2. Informative References 665 [I-D.ietf-softwire-lw4over6] 666 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 667 I. Farrer, "Lightweight 4over6: An Extension to the DS- 668 Lite Architecture", draft-ietf-softwire-lw4over6-10 (work 669 in progress), June 2014. 671 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 672 September 1985. 674 Authors' Addresses 676 Qi Sun 677 Tsinghua University 678 Beijing 100084 679 P.R.China 681 Phone: +86-10-6278-5822 682 Email: sunqi@csnet1.cs.tsinghua.edu.cn 684 Yong Cui 685 Tsinghua University 686 Beijing 100084 687 P.R.China 689 Phone: +86-10-6260-3059 690 Email: yong@csnet1.cs.tsinghua.edu.cn 692 Marcin Siodelski 693 950 Charter Street 694 Redwood City, CA 94063 695 USA 697 Phone: +1 650 423 1431 698 Email: msiodelski@gmail.com 700 Suresh Krishnan 701 Ericsson 703 Email: suresh.krishnan@ericsson.com 704 Ian Farrer 705 Deutsche Telekom AG 706 GTN-FM4,Landgrabenweg 151 707 Bonn, NRW 53227 708 Germany 710 Email: ian.farrer@telekom.de