idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-dhcpv6-05.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 (February 14, 2014) is 3717 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-05 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: August 18, 2014 M. Siodelski 6 ISC 7 S. Krishnan 8 Ericsson 9 I. Farrer 10 Deutsche Telekom AG 11 February 14, 2014 13 DHCPv4 over DHCPv6 Transport 14 draft-ietf-dhc-dhcpv4-over-dhcpv6-05 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 August 18, 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 . . . . . . . . . . . . 9 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 CPE: Customer Premises Equipment (also 114 known as Customer Provided 115 Equipment), which provides access for 116 devices connected to a Local Area 117 Network (typically at the customer's 118 site/home) to the Internet Service 119 Provider's network. 121 DHCP 4o6 client (or client): A DHCP client supporting both the 122 DHCPv6 protocol [RFC3315] as well as 123 the DHCPv4 over DHCPv6 protocol 124 described in this document. Such a 125 client is capable of requesting IPv6 126 configuration using DHCPv6 and IPv4 127 configuration using DHCPv4 over 128 DHCPv6. 130 DHCP 4o6 server (or server): A DHCP server that is capable of 131 processing DHCPv4 packets 132 encapsulated in the DHCPv4 Message 133 option (defined below). 135 DHCPv4 over DHCPv6: A protocol described in this 136 document, used to carry DHCPv4 137 messages in the payload of DHCPv6 138 messages. 140 4. Architecture Overview 142 The architecture described here addresses a typical use case, where a 143 DHCP client's uplink supports IPv6 only and the Service Provider's 144 network supports IPv6 and limited IPv4 services. In this scenario, 145 the client can only use the IPv6 network to access IPv4 services, so 146 IPv4 services must be configured using IPv6 as the underlying network 147 protocol. 149 Although the purpose of this document is to address the problem of 150 communication between the DHCPv4 client and the DHCPv4 server, the 151 mechanism that it describes does not restrict the transported 152 messages types to DHCPv4 only. As the DHCPv4 message is a special 153 type of BOOTP message, BOOTP messages can also be transported using 154 the same mechanism. 156 DHCP clients may be running on CPE devices, end hosts or any other 157 device that supports the DHCP client function. At the time of 158 writing, DHCP clients on CPE devices are comparatively easier to 159 modify than those implemented on end hosts. As a result, this 160 document uses the CPE as an example for describing the mechanism. 161 This does not preclude any end-host, or other device requiring IPv4 162 configuration, from implementing DHCPv4 over DHCPv6 in the future. 164 This mechanism works by carrying DHCPv4 messages encapsulated within 165 DHCPv6 messages. Figure 1, below, illustrates one possible 166 deployment architecture. 168 The DHCP 4o6 client implements a new DHCPv6 message called 169 DHCPv4-query, which contains a new option called the DHCPv4 Message 170 option encapsulating a DHCPv4 message sent by the client. The format 171 of this option is described in Section 6.1. 173 The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents 174 or directly to the DHCP 4o6 server. The server replies with a 175 DHCPv4-response message, which is a new DHCPv6 message carrying the 176 DHCPv4 response encapsulated in the DHCPv4 Message option. 178 _____________ _____________ 179 / \ / \ 180 | | | | 181 +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ 182 | DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 | 183 | client +---------+ Relay Agent +---------+ Server | 184 | (on CPE) | | | | | 185 +--------+-+ +-+-----------+-+ +-+--------+ 186 | | | | 187 \_____________/ \_____________/ 189 Figure 1: Architecture Overview 191 By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the 192 client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain 193 the necessary IPv6 configuration. The client requests the 4o6 Server 194 Address option from the server by sending the option code in Option 195 Request option as described in [RFC3315]. If the server responds 196 with the 4o6 Server Address option, it is an indication to the client 197 to attempt using DHCPv4 over DHCPv6 to obtain IPv4 configuration. 199 The client obtains the address(es) of the DHCP 4o6 server(s) from the 200 4o6 Server Address option and uses them to communicate with the DHCP 201 4o6 servers as described in Section 8. If the 4o6 Server Address 202 option contains no addresses (is empty), the client uses the well- 203 known All_DHCP_Relay_Agents_and_Servers multicast address to 204 communicate with the DHCP 4o6 server(s). 206 Before applying for an IPv4 address via a DHCPv4-query message, the 207 client must identify a suitable network interface for the address. 208 Once the request is acknowledged by the server, the client can 209 configure the address and other relevant parameters on this 210 interface. The mechanism for determining a suitable interface is out 211 of the scope of the document. 213 5. New DHCPv6 Messages 215 Two new DHCPv6 messages carry DHCPv4 messages between the client and 216 the server using the DHCPv6 protocol: DHCPv4-query and 217 DHCPv4-response. This section describes the structures of these 218 messages. 220 5.1. Message Types 222 DHCPV4-QUERY (TBD): The DHCP 4o6 client sends a DHCPv4-query 223 message to a DHCP 4o6 server. The DHCPv4 224 Message option carried by this message 225 contains a DHCPv4 message that the DHCP 4o6 226 client uses to request IPv4 configuration 227 parameters from the server. 229 DHCPv4-RESPONSE (TBD): A DHCP 4o6 server sends a DHCPv4-response 230 message to a DHCP 4o6 client. It contains a 231 DHCPv4 Message option carrying a DHCPv4 232 message in response to a DHCPv4 message 233 received by the server in the DHCPv4 Message 234 option of the DHCPv4-query message. 236 5.2. Message Formats 238 Both DHCPv6 messages defined in this document share the following 239 format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | msg-type | flags | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 . options . 248 . (variable) . 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 2: The format of DHCPv4-query and DHCPv4-response messages 254 msg-type Identifies the message type. It can be either 255 DHCPV4-QUERY (TBD) or DHCPV4-RESPONSE (TBD) 256 corresponding to the contained DHCPv4-query or 257 DHCPv4-response, respectively. 259 flags Specifies flags providing additional information 260 required by the server to process the DHCPv4 message 261 encapsulated in the DHCPv4-query message, or required 262 by the client to process a DHCPv4 message 263 encapsulated in the DHCPv4-response message. 265 options Options carried by the message. The DHCPv4 Message 266 Option (described in Section 6.1) MUST be carried by 267 the message. Only DHCPv6 options for IPv4 268 configuration may be included in this field. It MUST 269 NOT contain DHCPv6 options related solely to IPv6, or 270 IPv6-only service configuration. 272 5.3. DHCPv4-query Message Flags 274 The "flags" field of the DHCPv4-query is used to carry additional 275 information that may be used by the server to process the 276 encapsulated DHCPv4 message. Currently only one bit of this field is 277 used. Remaining bits are reserved for the future use. The "flags" 278 field has the following format: 280 0 1 2 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |U| MBZ | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 3: DHCPv4-query flags format 288 U Unicast Flag. If set to 1, it indicates that the 289 DHCPv4 message encapsulated within the DHCPv4-query 290 message would be sent to a unicast address if it was 291 sent using IPv4. If this flag is set to 0, it 292 indicates that the DHCPv4 message would be sent to 293 the broadcast address if it was sent using IPv4. The 294 usage of the flag is described in detail in 295 Section 7. 297 MBZ Bits MUST be set to zero when sending and MUST be 298 ignored when receiving. 300 5.4. DHCPv4-response Message Flags 302 This document introduces no flags to be carried in the "flags" field 303 of the DHCPv4-response message. They are all reserved for the future 304 use. The DHCP 4o6 server MUST set all bits of this field to 0 and 305 the DHCP 4o6 client MUST ignore the content in this field. 307 6. New DHCPv6 Options 309 6.1. DHCPv4 Message Option Format 311 The DHCPv4 Message option carries a DHCPv4 message that is sent by 312 the client or the server. Such messages exclude any IP or UDP 313 headers. 315 The format of the DHCPv4 Message option is: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | OPTION_DHCPV4_MSG | option-len | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 . DHCPv4-message . 324 . . 325 . . 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 4: DHCPv4 Message option Format 330 option-code OPTION_DHCPV4_MSG (TBD). 332 option-len Length of the DHCPv4 message. 334 DHCPv4-message The DHCPv4 message sent by the client or the server. 335 In a DHCPv4-query message it contains a DHCPv4 336 message sent by a client. In a DHCPv4-response 337 message it contains a DHCPv4 message sent by a server 338 in response to a client. 340 6.2. 4o6 Server Address Option Format 342 The 4o6 Server Address option is sent by a server to a client 343 requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a 344 list of DHCP 4o6 server's IPv6 addresses that the client should 345 contact to obtain IPv4 configuration. This list may include either 346 multicast or unicast addresses. The client sends its requests to all 347 unique addresses carried in this option. 349 This option may also carry no IPv6 addresses, which instructs the 350 client to use the All_DHCP_Relay_Agents_and_Servers multicast address 351 as the destination address. 353 The presence of this option in the server's response indicates to the 354 client that it should use DHCPv4 over DHCPv6 to obtain IPv4 355 configuration. If the option is absent, the client MUST NOT enable 356 DHCPv4-over-DHCPv6 function. 358 The format of the 4o6 Server Address option is: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | OPTION_DHCP4_O_DHCP6_SERVER | option-len | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | 366 . IPv6 Address(es) . 367 . . 368 . . 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 5: 4o6 Servers Address Option Format 373 option-code OPTION_DHCP4_O_DHCP6_SERVER (TBD). 375 option-len Length of the IPv6 address(es) carried by the option, 376 i.e. multiple of 16 octets. Minimal length of this 377 option is 0. 379 IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6 380 Server(s). 382 7. Use of the DHCPv4-query Unicast Flag 384 A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST 385 message to either a broadcast or unicast address depending on its 386 state. For example, a client in the RENEWING state uses a unicast 387 address to contact the DHCPv4 server to renew its lease. A client in 388 the REBINDING state uses a broadcast address. If there is a DHCPv4 389 relay agent in the middle, a client in the RENEWING state may send a 390 DHCPREQUEST message to the unicast address of the relay agent. In 391 such a case, the server is unable to determine whether the client 392 sent the message to a unicast or broadcast address and thus the 393 server may be unable to correctly determine the client's state. 394 [RFC5010] introduced the "Flags Suboption" that relay agents add to 395 relayed messages to indicate whether broadcast or unicast was used by 396 the client. 398 In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the 399 DHCP 4o6 server. There is no relation between the outer IPv6 address 400 and the inner DHCPv4 message. As a result, the server is unable to 401 determine whether the received DHCPv4 messages should have been sent 402 using broadcast or unicast in IPv4 by checking the IPv6 address. 403 This is similar to the case addressed by [RFC5010]. 405 In order to allow the server to determine the client's state, the 406 "Unicast" flag is carried in the DHCPv4-query message. The client 407 MUST set this flag to 1 when the DHCPv4 message would have been sent 408 to the unicast address if using DHCPv4 over IPv4. This flag MUST be 409 set to 0 if the DHCPv4 client would have sent the message to the 410 broadcast address in IPv4. The choice whether a given message should 411 be sent to a broadcast or unicast address is made based on the 412 [RFC2131] and its extensions. 414 Note: The "Unicast" flag reflects how the DHCPv4 packet would have 415 been sent; not how the DHCPv6 packet itself is sent. 417 8. DHCP 4o6 Client Behavior 419 The DHCPv4-over-DHCPv6 function MUST be disabled by default. The 420 client MUST obtain the necessary IPv6 configuration (stateless or 421 stateful) before using DHCPv4 over DHCPv6. The client intending to 422 use DHCPv4 over DHCPv6 MUST request the 4o6 Server Address option 423 using Option Request option (ORO) in every Solicit, Request, Renew, 424 Rebind and Information-request message. 426 The server MAY include the 4o6 Server Address option in its response 427 to the client. If the client receives this option, it MUST enable 428 the DHCPv4-over-DHCPv6 function. The client MUST NOT enable the 429 DHCPv4-over-DHCPv6 function if the server does not include the 4o6 430 Server Address option in its response. If the client does not 431 receive this option and DHCPv4 over DHCPv6 is already enabled, the 432 client MUST disable the DHCPv4-over-DHCPv6 function. 434 If the client receives the 4o6 Server Address option and there is a 435 DHCPv4 client active on the interface over which that DHCPv6 option 436 was received, it MUST stop the DHCPv4 client from sending messages 437 using [RFC2131]. 439 If the client receives a 4o6 Server Address option that contains no 440 IP addresses, i.e. the option is empty, the client MUST send its 441 requests to the All_DHCP_Relay_Agents_and_Servers multicast address. 442 If there is a list of IP addresses in the option, the client SHOULD 443 send requests to each unique address carried by the option. 445 If the client obtained stateless IPv6 configuration by sending 446 Information-request message to the server, the client MUST follow the 447 rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6 448 configuration (i.e. list of DHCP 4o6 servers) as well as other 449 configuration data. The client which obtained stateful IPv6 450 configuration will refresh the status of DHCPv4-over-DHCPv6 function 451 when extending a lifetime of acquired IPv6 address (Renew and Rebind 452 messages). 454 The client MUST employ an IPv6 address of an appropriate scope to 455 source the DHCPv4-query message from. When the client sends a 456 DHCPv4-query message to the multicast address, it MUST use a link- 457 local address as the source address as described in [RFC3315]. When 458 the client sends a DHCPv4-query message using unicast, the source 459 address MUST be an address of appropriate scope, acquired in advance. 461 The client generates a DHCPv4 message and stores it verbatim in the 462 DHCPv4 Message option carried by the DHCPv4-query message. The 463 client MUST put exactly one DHCPv4 Message option into a single 464 DHCPv4-query message. The client MUST NOT request the 4o6 Server 465 Address option in the DHCPv4-query message. 467 The client MUST follow rules defined in Section 7 when setting the 468 Unicast flag based on the DHCPv4 destination. 470 On receiving a DHCPv4-response message, the client MUST look for the 471 DHCPv4 Message option within this message. If this option is not 472 found, the DHCPv4-response message is discarded. If the DHCPv4 473 Message option is present, the client extracts the DHCPv4 message it 474 contains and processes it as described in section 4.4 of [RFC2131]. 476 When dealing with IPv4 configuration, the client MUST follow the 477 normal DHCPv4 retransmission requirements and strategy as specified 478 in section 4.1 of [RFC2131]. There are no explicit transmission 479 parameters associated with a DHCPv4-query message, as this is 480 governed by the DHCPv4 [RFC2131] "state machine". 482 The client MUST implement [RFC4361] to ensure that the device 483 correctly identifies itself. 485 9. Relay Agent Behavior 487 When a DHCPv6 relay agent receives a DHCPv4-query message, it may not 488 recognize this message. The unknown message can be forwarded as 489 described in [I-D.ietf-dhc-dhcpv6-unknown-msg]. 491 Additionally, the DHCPv6 relay agent MAY allow the configuration of a 492 dedicated DHCPv4 over DHCPv6 specific destination address(es), 493 differing from the address(es) of the DHCPv6-only server(s). To 494 implement this function, the relay checks the received DHCPv6 message 495 type and forwards according to the following logic: 497 1. If the message type is DHCPV4-QUERY, the packet is relayed to the 498 configured DHCP 4o6 Server's address(es) in the form of normal 499 DHCPv6 packet (i.e. DHCPv6/UDP/IPv6). 501 2. For any other DHCPv6 message type, forward according to section 502 20 of [RFC3315]. 504 The above logic only allows for separate relay destinations 505 configured on the relay agent closest to the client (single relay 506 hop). Multiple relaying hops are not considered in the case of 507 separate relay destinations. 509 10. DHCP 4o6 Server Behavior 511 When the server receives a DHCPv4-query message from a client, it 512 searches for the DHCPv4 Message option. The server discards the 513 packet without this option. The server MAY notify an administrator 514 about the receipt of a malformed packet. The mechanism for this 515 notification is out of scope for this document. 517 If the server finds a valid DHCPv4 Message option, it extracts the 518 original DHCPv4 message and the contents of the "flags" field carried 519 in the DHCPv4-query message and uses them to generate the appropriate 520 DHCPv4 response (server to client message). The response is 521 generated as described in [RFC2131] with the exception that the 522 server SHOULD use the information carried in the "flags" field of the 523 DHCPv4-query message to find out whether the client's message would 524 have been sent to the broadcast or unicast address if IPv4 has been 525 used. This is useful for the server to determine the state of the 526 client. The use of the "flags" field is described in detail in 527 Section 7. 529 When an appropriate DHCPv4 response is generated, the 4o6 Server 530 places it in the payload of a DHCPv4 Message option, which it puts 531 into the DHCPv4-response message. 533 If the DHCPv4-query message was received directly by the server, the 534 DHCPv4-response message MUST be unicast from the interface on which 535 the original message was received. 537 If the DHCPv4-query message was received in a Relay-forward message, 538 the server creates a Relay-reply message with the DHCPv4-response 539 message in the payload of a Relay Message option, and responds as 540 described in section 20.3 of [RFC3315]. 542 11. Security Considerations 544 In this specification, DHCPv4 messages are encapsulated in the newly 545 defined option and messages. This is similar to the handling of the 546 current relay agent messages. In order to bypass firewalls or 547 network authentication gateways, a malicious attacker may leverage 548 this feature to convey other messages using DHCPv6, i.e. use DHCPv6 549 as a form of encapsulation. However, the potential risk from this is 550 no more severe than that with the current DHCPv4 and DHCPv6 practice. 552 It is possible for a rogue server to reply with a 4o6 Server Address 553 Option containing duplicated IPv6 addresses, which could cause an 554 amplification attack. To avoid this, the client MUST check if there 555 are duplicate IPv6 addresses in a 4o6 Server Address Option when 556 receiving one. The client MUST ignore any but the first instance of 557 each address. 559 12. IANA Considerations 561 IANA is requested to allocate two DHCPv6 option codes for use by 562 OPTION_DHCPV4_MSG, OPTION_DHCP4_O_DHCP6_SERVER from the "DHCP Option 563 Codes" table, and two DHCPv6 message type codes for the DHCPV4-QUERY 564 and DHCPV4-RESPONSE from the "DHCP Message Codes" table of the 565 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry. Both 566 tables can be found at http://www.iana.org/assignments/ 567 dhcpv6-parameters/dhcpv6-parameters.xml. 569 13. Contributors List 571 Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen 572 and Cong Liu, for their great contributions to the draft. 574 14. References 576 14.1. Normative References 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, March 1997. 581 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 582 2131, March 1997. 584 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 585 and M. Carney, "Dynamic Host Configuration Protocol for 586 IPv6 (DHCPv6)", RFC 3315, July 2003. 588 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 589 Time Option for Dynamic Host Configuration Protocol for 590 IPv6 (DHCPv6)", RFC 4242, November 2005. 592 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 593 Identifiers for Dynamic Host Configuration Protocol 594 Version Four (DHCPv4)", RFC 4361, February 2006. 596 14.2. Informative References 598 [I-D.ietf-dhc-dhcpv6-unknown-msg] 599 Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 600 Messages", draft-ietf-dhc-dhcpv6-unknown-msg-05 (work in 601 progress), February 2014. 603 [RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host 604 Configuration Protocol Version 4 (DHCPv4) Relay Agent 605 Flags Suboption", RFC 5010, September 2007. 607 Authors' Addresses 609 Qi Sun 610 Tsinghua University 611 Beijing 100084 612 P.R.China 614 Phone: +86-10-6278-5822 615 Email: sunqi@csnet1.cs.tsinghua.edu.cn 616 Yong Cui 617 Tsinghua University 618 Beijing 100084 619 P.R.China 621 Phone: +86-10-6260-3059 622 Email: yong@csnet1.cs.tsinghua.edu.cn 624 Marcin Siodelski 625 950 Charter Street 626 Redwood City, CA 94063 627 USA 629 Phone: +1 650 423 1431 630 Email: msiodelski@gmail.com 632 Suresh Krishnan 633 Ericsson 635 Email: suresh.krishnan@ericsson.com 637 Ian Farrer 638 Deutsche Telekom AG 639 GTN-FM4,Landgrabenweg 151 640 Bonn, NRW 53227 641 Germany 643 Email: ian.farrer@telekom.de