idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-dhcpv6-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 : ---------------------------------------------------------------------------- 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 (January 16, 2014) is 3746 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-dhc-dhcpv6-unknown-msg-04 Summary: 2 errors (**), 0 flaws (~~), 2 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: July 20, 2014 M. Siodelski 6 ISC 7 S. Krishnan 8 Ericsson 9 I. Farrer 10 Deutsche Telekom AG 11 January 16, 2014 13 DHCPv4 over DHCPv6 Transport 14 draft-ietf-dhc-dhcpv4-over-dhcpv6-04 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 July 20, 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. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 63 5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 5 65 5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5 66 5.3. DHCPv4-query Message Flags . . . . . . . . . . . . . . . 6 67 5.4. DHCPv4-response Message Flags . . . . . . . . . . . . . . 7 68 6. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. DHCPv4 Message Option Format . . . . . . . . . . . . . . 7 70 6.2. 4o6 Server Address Option Format . . . . . . . . . . . . 8 71 7. Use of the DHCPv4-query Unicast Flag . . . . . . . . . . . . 8 72 8. DHCP 4o6 Client Behavior . . . . . . . . . . . . . . . . . . 9 73 9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 11 74 10. DHCP 4o6 Server Behavior . . . . . . . . . . . . . . . . . . 11 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 14.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 As the migration towards IPv6 continues, IPv6-only networks will 86 become more prevalent. In such networks, IPv4 connectivity will 87 continue to be provided as a service over IPv6-only networks. In 88 addition to provisioning IPv4 addresses for clients of this service, 89 other IPv4 configuration parameters may also be needed (e.g. 90 addresses of IPv4-only services). 92 This document describes a transport mechanism to carry DHCPv4 93 messages using the DHCPv6 protocol for the dynamic provisioning of 94 IPv4 addresses and other DHCPv4 specific configuration parameters 95 across IPv6-only networks. It leverages the existing DHCPv4 96 infrastructure, e.g. failover, DNS updates, DHCP leasequery, etc. 98 When IPv6 multicast is used to transport 4o6 messages, another 99 benefit is that the operator can gain information about the 100 underlying IPv6 network the 4o6 client is connected to from the the 101 DHCPv6 relay agents the request has passed through. 103 2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Terminology 111 This document makes use of the following terms: 113 DHCP 4o6 Client: A DHCP client supporting both the DHCPv6 protocol 114 [RFC3315] as well as the DHCPv4 over DHCPv6 115 protocol described in this document. Such a 116 client is capable of requesting IPv6 117 configuration using DHCPv6 and IPv4 configuration 118 using DHCPv4 over DHCPv6. 120 DHCP 4o6 Server: A DHCP server that is capable of processing 121 DHCPv4 packets encapsulated in the DHCPv4 Message 122 option (defined below). 124 CPE: Customer Premises Equipment (also known as 125 Customer Provided Equipment), which provides 126 access for devices connected to a Local Area 127 Network (typically at the customer's site/home) 128 to the Internet Service Provider's network. 130 DHCPv4 over DHCPv6: A protocol described in this document, used to 131 carry DHCPv4 messages in the payload of DHCPv6 132 messages. 134 4. Architecture Overview 136 The architecture described here addresses a typical use case, where a 137 DHCP client's uplink supports IPv6 only and the Service Provider's 138 network supports IPv6 and limited IPv4 services. In this scenario, 139 the client can only use the IPv6 network to access IPv4 services, so 140 IPv4 services must be configured using IPv6 as the underlying network 141 protocol. 143 Although the purpose of this document is to address the problem of 144 communication between the DHCPv4 client and the DHCPv4 server, the 145 mechanism that it describes does not restrict the transported 146 messages types to DHCPv4 only. As the DHCPv4 message is a special 147 type of BOOTP message, BOOTP messages can also be transported using 148 the same mechanism. 150 DHCP clients may be running on CPE devices, end hosts or any other 151 device that supports the DHCP client function. At the time of 152 writing, DHCP clients on CPE devices are comparatively easier to 153 modify than those implemented on end hosts. As a result, this 154 document uses the CPE as an example for describing the mechanism. 155 This does not preclude any end-host, or other device requiring IPv4 156 configuration, from implementing DHCPv4 over DHCPv6 in the future. 158 This mechanism works by carrying DHCPv4 messages encapsulated within 159 DHCPv6 messages. Figure 1, below, illustrates one possible 160 deployment architecture. 162 The DHCP 4o6 client implements a new DHCPv6 message called 163 DHCPv4-query, which contains a new option called the DHCPv4 Message 164 option encapsulating a DHCPv4 message sent by the client. The format 165 of this option is described in Section 6.1. 167 The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents 168 or directly to the DHCP 4o6 Server. The server replies with a 169 DHCPv4-response message, which is a new DHCPv6 message carrying the 170 DHCPv4 response encapsulated in the DHCPv4 Message option. 172 _____________ _____________ 173 / \ / \ 174 | | | | 175 +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ 176 | DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 | 177 | Client +---------+ Relay Agent +---------+ Server | 178 | (on CPE) | | | | | 179 +--------+-+ +-+-----------+-+ +-+--------+ 180 | | | | 181 \_____________/ \_____________/ 183 Figure 1: Architecture Overview 185 By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the 186 client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain 187 the necessary IPv6 configuration. The client requests the 4o6 Server 188 Address option from the DHCPv6 server by sending the option code in 189 Option Request option as described in [RFC3315]. If the DHCPv6 190 server responds with the 4o6 Server Address option, it is an 191 indication to the client to attempt using DHCPv4 over DHCPv6 to 192 obtain IPv4 configuration. 194 The DHCP 4o6 client obtains the address(es) of the DHCP 4o6 server(s) 195 from the 4o6 Server Address option and uses them to communicate with 196 the DHCP 4o6 servers as described in Section 8. If the 4o6 Server 197 Address option contains no addresses (is empty), the DHCP 4o6 client 198 uses the well-known All_DHCP_Relay_Agents_and_Servers multicast 199 address to communicate with the DHCP 4o6 server(s). 201 Before applying for an IPv4 address via a DHCPv4-query message, the 202 DHCP 4o6 client must identify a suitable network interface for the 203 address. Once the request is acknowledged by the DHCP 4o6 server, 204 the client can configure the address and other relevant parameters on 205 this interface. The mechanism for determining a suitable interface 206 is out of the scope of the document. 208 5. New DHCPv6 Messages 210 Two new DHCPv6 messages carry DHCPv4 messages between the client and 211 the server using the DHCPv6 protocol: DHCPv4-query and 212 DHCPv4-response. This section describes the structures of these 213 messages. 215 5.1. Message Types 217 DHCPV4-QUERY (TBD): The DHCP 4o6 client sends a DHCPv4-query 218 message to a DHCP 4o6 server. The DHCPv4 219 Message option carried by this message 220 contains a DHCPv4 message that the DHCP 4o6 221 client uses to request IPv4 configuration 222 parameters from the server. 224 DHCPv4-RESPONSE (TBD): A DHCP 4o6 server sends a DHCPv4-response 225 message to a DHCP 4o6 client. It contains a 226 DHCPv4 Message option carrying a DHCPv4 227 message in response to a DHCPv4 message 228 received by the server in the DHCPv4 Message 229 option of the DHCPv4-query message. 231 5.2. Message Formats 233 Both DHCPv6 messages defined in this document share the following 234 format: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | msg-type | flags | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 . options . 243 . (variable) . 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 2: The format of DHCPv4-query and DHCPv4-response messages 249 msg-type Identifies the message type. It can be either 250 DHCPV4-QUERY (TBD) or DHCPV4-RESPONSE (TBD) 251 corresponding to the contained DHCPv4-query or 252 DHCPv4-response, respectively. 254 flags Specifies flags providing additional information 255 required by the server to process the DHCPv4 message 256 encapsulated in the DHCPv4-query message, or required 257 by the client to process a DHCPv4 message 258 encapsulated in the DHCPv4-response message. 260 options Options carried by the message. The DHCPv4 Message 261 Option (described in Section 6.1) MUST be carried by 262 the message. Only DHCPv6 options for IPv4 263 configuration may be included in this field. It MUST 264 NOT contain DHCPv6 options related solely to IPv6, or 265 IPv6-only service configuration. 267 5.3. DHCPv4-query Message Flags 269 The "flags" field of the DHCPv4-query is used to carry additional 270 information that may be used by the server to process the 271 encapsulated DHCPv4 message. Currently only one bit of this field is 272 used. Remaining bits are reserved for the future use. The "flags" 273 field has the following format: 275 0 1 2 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |U| Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 3: DHCPv4-query flags format 283 U Unicast Flag. If set to 1, it indicates that the 284 DHCPv4 message encapsulated within the DHCPv4-query 285 message would be sent to a unicast address if it was 286 sent using IPv4. If this flag is set to 0, it 287 indicates that the DHCPv4 message would be sent to 288 the broadcast address if it was sent using IPv4. 290 Reserved Bits MUST be set to zero when sending and MUST be 291 ignored when receiving. 293 5.4. DHCPv4-response Message Flags 295 This document introduces no flags to be carried in the "flags" field 296 of the DHCPv4-response message. They are all reserved for the future 297 use. The 4o6 Server MUST set all bits of this field to 0 and the 4o6 298 client MUST ignore the content in this field. 300 6. New DHCPv6 Options 302 6.1. DHCPv4 Message Option Format 304 The DHCPv4 Message option carries a DHCPv4 message that is sent by 305 the client or the server. Such messages exclude any IP or UDP 306 headers. 308 The format of the DHCPv4 Message option is: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | OPTION_DHCPV4_MSG | option-len | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 . DHCPv4-message . 317 . . 318 . . 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 4: DHCPv4 Message option Format 323 option-code OPTION_DHCPV4_MSG (TBD). 325 option-len Length of the DHCPv4 message. 327 DHCPv4-message The DHCPv4 message sent by the client or the server. 328 In a DHCPv4-query message it contains a DHCPv4 329 message sent by a client. In a DHCPv4-response 330 message it contains a DHCPv4 message sent by a server 331 in response to a client. 333 6.2. 4o6 Server Address Option Format 335 The 4o6 Server Address option is sent by the DHCPv6 server to a 336 client requesting IPv6 configuration. It carries a list of DHCP 4o6 337 server's IPv6 addresses that the DHCP 4o6 client should contact to 338 obtain IPv4 configuration. This list may include either multicast or 339 unicast addresses. The DHCP 4o6 client sends its requests to all 340 unique addresses carried in this option. 342 This option may also carry no IPv6 addresses, which instructs the 343 client to use the All_DHCP_Relay_Agents_and_Servers multicast address 344 as the destination address. 346 The presence of this option in the DHCPv6 server's response indicates 347 to the client that it should use DHCPv4 over DHCPv6 to obtain IPv4 348 configuration. If the option is absent, the client MUST NOT enable 349 DHCPv4 over DHCPv6 function. 351 The format of the 4o6 Server Address option is: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | OPTION_DHCP4_O_DHCP6_SERVER | option-len | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 . IPv6 Address(es) . 360 . . 361 . . 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 5: 4o6 Servers Address Option Format 366 option-code OPTION_DHCP4_O_DHCP6_SERVER (TBD). 368 option-len Length of the IPv6 address(es) carried by the option, 369 i.e. multiple of 16 octets. Minimal length of this 370 option is 0. 372 IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6 373 Server(s). 375 7. Use of the DHCPv4-query Unicast Flag 377 A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST 378 message to either a broadcast or unicast address depending on its 379 state. For example, a client in the RENEWING state uses a unicast 380 address to contact the DHCPv4 server to renew its lease. A client in 381 the REBINDING state uses a broadcast address. If there is a DHCPv4 382 relay agent in the middle, a client in the RENEWING state may send a 383 DHCPREQUEST message to the unicast address of the relay agent. In 384 such a case, the server is unable to determine whether the client 385 sent the message to a unicast or broadcast address and thus the 386 server may be unable to correctly determine the client's state. 387 [RFC5010] introduced the "Flags Suboption" that relay agents add to 388 relayed messages to indicate whether broadcast or unicast was used by 389 the client. 391 In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the 392 4o6 DHCP Server. There is no relation between the outer IPv6 address 393 and the inner DHCPv4 message. As a result, the server is unable to 394 determine whether the received DHCPv4 messages should have been sent 395 using broadcast or unicast in IPv4 by checking the IPv6 address. 396 This is similar to the case addressed by [RFC5010]. 398 In order to allow the server to determine the client's state, the 399 "Unicast" flag is carried in the DHCPv4-query message. The client 400 MUST set this flag to 1 when the DHCPv4 message would have been sent 401 to the unicast address if using DHCPv4 over IPv4. This flag MUST be 402 set to 0 if the DHCPv4 client would have sent the message to the 403 broadcast address in IPv4. The choice whether a given message should 404 be sent to a broadcast or unicast address is made based on the 405 [RFC2131] and its extensions. 407 Note: The "Unicast" flag reflects how the DHCPv4 packet would have 408 been sent; not how the DHCPv6 packet itself is sent. 410 8. DHCP 4o6 Client Behavior 412 The DHCPv4-over-DHCPv6 function MUST be disabled by default. The 413 client MUST obtain the necessary IPv6 configuration before using 414 DHCPv4 over DHCPv6. A client intending to use DHCPv4 over DHCPv6 415 MUST request the 4o6 Server Address option using Option Request 416 option (ORO) in every Solicit, Request, Renew and Information-request 417 message. 419 The DHCPv6 server MAY include the 4o6 Server Address option in its 420 response to the client. If the client receives this option, it MUST 421 enable the DHCPv4-over-DHCPv6 function. The client MUST NOT enable 422 the DHCPv4-over-DHCPv6 function if the DHCPv6 server does not include 423 the 4o6 Server Address option in its response. If the client does 424 not receive this option and DHCPv4 over DHCPv6 is already enabled, 425 the client MUST disable the DHCPv4-over-DHCPv6 function. 427 If the DHCP 4o6 client receives the 4o6 Server Address option and 428 there is a DHCPv4 client active on the interface over which that 429 DHCPv6 option was received, it MUST stop the DHCPv4 client from 430 sending messages using [RFC2131]. 432 If the 4o6 client receives a 4o6 Server Address option that contains 433 no IP addresses, i.e. the option is empty, the DHCP 4o6 client MUST 434 send its requests to the All_DHCP_Relay_Agents_and_Servers multicast 435 address. If there is a list of IP addresses in the option, the DHCP 436 4o6 client SHOULD send requests to each unique address carried by the 437 option. 439 The DHCP 4o6 client MUST employ an IPv6 address of an appropriate 440 scope to source the DHCPv4-query message from. When the client sends 441 a DHCPv4-query message to the multicast address, it MUST use a link- 442 local address as the source address as described in [RFC3315]. When 443 the client sends a DHCPv4-query message using unicast, the source 444 address MUST be the global IPv6 address, acquired in advance. 446 A client supporting DHCPv4 over DHCPv6 SHOULD use Information Refresh 447 Time Option [RFC4242] to refresh the status of DHCPv4-over-DHCPv6 448 function as well as other DHCPv6 configuration data. 450 The client generates a DHCPv4 message and stores it verbatim in the 451 DHCPv4 Message option carried by the DHCPv4-query message. The 452 client MUST put exactly one DHCPv4 Message option into a single 453 DHCPv4-query message. The client MUST NOT request the 4o6 Server 454 Address option in the DHCPv4-query message. 456 The client MUST follow rules defined in Section 7 when setting the 457 Unicast flag based on the DHCPv4 destination. 459 On receiving a DHCPv4-response message, the client MUST look for the 460 DHCPv4 Message option within this message. If this option is not 461 found, the DHCPv4-response message is discarded. If the DHCPv4 462 Message option is present, the client extracts the DHCPv4 message it 463 contains and processes it as described in section 4.4 of [RFC2131]. 465 When dealing with IPv4 configuration, the DHCP 4o6 client MUST follow 466 the normal DHCPv4 retransmission requirements and strategy as 467 specified in section 4.1 of [RFC2131]. There are no explicit 468 transmission parameters associated with a DHCPv4-query message, as 469 this is governed by the DHCPv4 [RFC2131] "state machine". 471 The DHCP 4o6 client MUST implement [RFC4361] to ensure that the 472 device correctly identifies itself. 474 9. Relay Agent Behavior 476 When a DHCPv6 relay agent receives a DHCPv4-query message, it may not 477 recognize this message. The unknown message can be forwarded as 478 described in [I-D.ietf-dhc-dhcpv6-unknown-msg]. 480 Additionally, the DHCPv6 relay agent MAY allow the configuration of a 481 dedicated DHCPv4 over DHCPv6 specific destination address(es), 482 differing from the address(es) of the DHCPv6-only server(s). To 483 implement this function, the relay checks the received DHCPv6 message 484 type and forwards according to the following logic: 486 1. If the message type is DHCPV4-QUERY, the packet is relayed to the 487 configured DHCP 4o6 Server's address(es) in the form of normal 488 DHCPv6 packet (i.e. DHCPv6/UDP/IPv6). 490 2. For any other DHCPv6 message type, forward according to section 491 20 of [RFC3315]. 493 The above logic only allows for separate relay destinations 494 configured on the relay agent closest to the client (single relay 495 hop). Multiple relaying hops are not considered in the case of 496 separate relay destinations. 498 10. DHCP 4o6 Server Behavior 500 When the server receives a DHCPv4-query message from a client, it 501 searches for the DHCPv4 Message option. The server discards the 502 packet without this option. The server MAY notify an administrator 503 about the receipt of a malformed packet. The mechanism for this 504 notification is out of scope for this document. 506 If the server finds a valid DHCPv4 Message option, it extracts the 507 original DHCPv4 message and the contents of the "flags" field carried 508 in the DHCPv4-query message and uses them to generate the appropriate 509 DHCPv4 response (server to client message). The response is 510 generated as described in [RFC2131] with the exception that the 511 server SHOULD use the information carried in the "flags" field of the 512 DHCPv4-query message to find out whether the client's message would 513 have been sent to the broadcast or unicast address if IPv4 has been 514 used. This is useful for the server to determine the state of the 515 client. The use of the "flags" field is described in detail in 516 Section 7. Since the client MUST use a client identifier to identify 517 itself (as per [RFC4361]), the server MUST implement [RFC6842] and 518 use the client identifier in all DHCPv4 message exchanges with the 519 client. 521 When an appropriate DHCPv4 response is generated, the 4o6 Server 522 places it in the payload of a DHCPv4 Message option, which it puts 523 into the DHCPv4-response message. 525 If the DHCPv4-query message was received directly by the server, the 526 DHCPv4-response message MUST be unicast from the interface on which 527 the original message was received. 529 If the DHCPv4-query message was received in a Relay-forward message, 530 the server creates a Relay-reply message with the DHCPv4-response 531 message in the payload of a Relay Message option, and responds as 532 described in section 20.3 of [RFC3315]. 534 11. Security Considerations 536 In this specification, DHCPv4 messages are encapsulated in the newly 537 defined option and messages. This is similar to the handling of the 538 current relay agent messages. In order to bypass firewalls or 539 network authentication gateways, a malicious attacker may leverage 540 this feature to convey other messages using DHCPv6, i.e. use DHCPv6 541 as a form of encapsulation. However, the potential risk from this is 542 no more severe than that with the current DHCPv4 and DHCPv6 practice. 544 It is possible for a rogue DHCPv6 server to reply with a 4o6 Server 545 Address Option containing duplicated IPv6 addresses, which could 546 cause an amplification attack. To avoid this, the client MUST check 547 if there are duplicate IPv6 addresses in a 4o6 Server Address Option 548 when receiving one. The client MUST ignore those duplicated IPv6 549 addresses. 551 12. IANA Considerations 553 IANA is requested to allocate two DHCPv6 option codes for use by 554 OPTION_DHCPV4_MSG and OPTION_DHCP4_O_DHCP6_SERVER from the "DHCP 555 Option Codes" table, and two DHCPv6 message type codes for the 556 DHCPV4-QUERY and DHCPV4-RESPONSE from the "DHCP Message Codes" table 557 of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 558 Registry. Both tables can be found at http://www.iana.org/ 559 assignments/dhcpv6-parameters/dhcpv6-parameters.xml. 561 13. Contributors List 563 Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen 564 and Cong Liu, for their great contributions to the draft. 566 14. References 568 14.1. Normative References 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, March 1997. 573 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 574 2131, March 1997. 576 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 577 and M. Carney, "Dynamic Host Configuration Protocol for 578 IPv6 (DHCPv6)", RFC 3315, July 2003. 580 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 581 Time Option for Dynamic Host Configuration Protocol for 582 IPv6 (DHCPv6)", RFC 4242, November 2005. 584 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 585 Identifiers for Dynamic Host Configuration Protocol 586 Version Four (DHCPv4)", RFC 4361, February 2006. 588 [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client 589 Identifier Option in DHCP Server Replies", RFC 6842, 590 January 2013. 592 14.2. Informative References 594 [I-D.ietf-dhc-dhcpv6-unknown-msg] 595 Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 596 Messages", draft-ietf-dhc-dhcpv6-unknown-msg-04 (work in 597 progress), December 2013. 599 [RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host 600 Configuration Protocol Version 4 (DHCPv4) Relay Agent 601 Flags Suboption", RFC 5010, September 2007. 603 Authors' Addresses 605 Qi Sun 606 Tsinghua University 607 Beijing 100084 608 P.R.China 610 Phone: +86-10-6278-5822 611 Email: sunqi@csnet1.cs.tsinghua.edu.cn 612 Yong Cui 613 Tsinghua University 614 Beijing 100084 615 P.R.China 617 Phone: +86-10-6260-3059 618 Email: yong@csnet1.cs.tsinghua.edu.cn 620 Marcin Siodelski 621 950 Charter Street 622 Redwood City, CA 94063 623 USA 625 Phone: +1 650 423 1431 626 Email: msiodelski@gmail.com 628 Suresh Krishnan 629 Ericsson 631 Email: suresh.krishnan@ericsson.com 633 Ian Farrer 634 Deutsche Telekom AG 635 GTN-FM4,Landgrabenweg 151 636 Bonn, NRW 53227 637 Germany 639 Email: ian.farrer@telekom.de