idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-dhcpv6-07.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 (April 15, 2014) is 3635 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: October 17, 2014 M. Siodelski 6 ISC 7 S. Krishnan 8 Ericsson 9 I. Farrer 10 Deutsche Telekom AG 11 April 15, 2014 13 DHCPv4 over DHCPv6 Transport 14 draft-ietf-dhc-dhcpv4-over-dhcpv6-07 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 October 17, 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 . . . . . . . . . . . . . . . . . . 12 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 13 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 14.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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. This document uses 158 the CPE as an example for describing the mechanism. This does not 159 preclude any end-host, or other device requiring IPv4 configuration, 160 from implementing DHCPv4 over DHCPv6 in the future. 162 This mechanism works by carrying DHCPv4 messages encapsulated within 163 DHCPv6 messages. Figure 1, below, illustrates one possible 164 deployment architecture. 166 The DHCP 4o6 client implements a new DHCPv6 message called 167 DHCPv4-query, which contains a new option called the DHCPv4 Message 168 option encapsulating a DHCPv4 message sent by the client. The format 169 of this option is described in Section 6.1. 171 The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents 172 or directly to the DHCP 4o6 server. The server replies with a 173 DHCPv4-response message, which is a new DHCPv6 message carrying the 174 DHCPv4 response encapsulated in the DHCPv4 Message option. 176 _____________ _____________ 177 / \ / \ 178 | | | | 179 +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ 180 | DHCP 4o6 | network | DHCPv6 | network | DHCP 4o6 | 181 | client +---------+ Relay Agent +---------+ Server | 182 | (on CPE) | | | | | 183 +--------+-+ +-+-----------+-+ +-+--------+ 184 | | | | 185 \_____________/ \_____________/ 187 Figure 1: Architecture Overview 189 By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the 190 client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain 191 the necessary IPv6 configuration. The client requests the 4o6 Server 192 Address option from the server by sending the option code in Option 193 Request option as described in [RFC3315]. If the server responds 194 with the 4o6 Server Address option, it is an indication to the client 195 to attempt using DHCPv4 over DHCPv6 to obtain IPv4 configuration. 197 The client obtains the address(es) of the DHCP 4o6 server(s) from the 198 4o6 Server Address option and uses them to communicate with the DHCP 199 4o6 servers as described in Section 8. If the 4o6 Server Address 200 option contains no addresses (is empty), the client uses the well- 201 known All_DHCP_Relay_Agents_and_Servers multicast address to 202 communicate with the DHCP 4o6 server(s). 204 Before applying for an IPv4 address via a DHCPv4-query message, the 205 client must identify a suitable network interface for the address. 206 Once the request is acknowledged by the server, the client can 207 configure the address and other relevant parameters on this 208 interface. The mechanism for determining a suitable interface is out 209 of the scope of the document. 211 5. New DHCPv6 Messages 213 Two new DHCPv6 messages carry DHCPv4 messages between the client and 214 the server using the DHCPv6 protocol: DHCPv4-query and 215 DHCPv4-response. This section describes the structures of these 216 messages. 218 5.1. Message Types 220 DHCPV4-QUERY (TBD): The DHCP 4o6 client sends a DHCPv4-query 221 message to a DHCP 4o6 server. The DHCPv4 222 Message option carried by this message 223 contains a DHCPv4 message that the DHCP 4o6 224 client uses to request IPv4 configuration 225 parameters from the server. 227 DHCPv4-RESPONSE (TBD): A DHCP 4o6 server sends a DHCPv4-response 228 message to a DHCP 4o6 client. It contains a 229 DHCPv4 Message option carrying a DHCPv4 230 message in response to a DHCPv4 message 231 received by the server in the DHCPv4 Message 232 option of the DHCPv4-query message. 234 5.2. Message Formats 236 Both DHCPv6 messages defined in this document share the following 237 format: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | msg-type | flags | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 . options . 246 . (variable) . 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 2: The format of DHCPv4-query and DHCPv4-response messages 252 msg-type Identifies the message type. It can be either 253 DHCPV4-QUERY (TBD) or DHCPV4-RESPONSE (TBD) 254 corresponding to the contained DHCPv4-query or 255 DHCPv4-response, respectively. 257 flags Specifies flags providing additional information 258 required by the server to process the DHCPv4 message 259 encapsulated in the DHCPv4-query message, or required 260 by the client to process a DHCPv4 message 261 encapsulated in the DHCPv4-response message. 263 options Options carried by the message. The DHCPv4 Message 264 Option (described in Section 6.1) MUST be carried by 265 the message. Only DHCPv6 options for IPv4 266 configuration may be included in this field. It MUST 267 NOT contain DHCPv6 options related solely to IPv6, or 268 IPv6-only service configuration. 270 5.3. DHCPv4-query Message Flags 272 The "flags" field of the DHCPv4-query is used to carry additional 273 information that may be used by the server to process the 274 encapsulated DHCPv4 message. Currently only one bit of this field is 275 used. Remaining bits are reserved for the future use. The "flags" 276 field has the following format: 278 0 1 2 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |U| MBZ | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 3: DHCPv4-query flags format 286 U Unicast Flag. If set to 1, it indicates that the 287 DHCPv4 message encapsulated within the DHCPv4-query 288 message would be sent to a unicast address if it was 289 sent using IPv4. If this flag is set to 0, it 290 indicates that the DHCPv4 message would be sent to 291 the broadcast address if it was sent using IPv4. The 292 usage of the flag is described in detail in 293 Section 7. 295 MBZ Bits MUST be set to zero when sending and MUST be 296 ignored when receiving. 298 5.4. DHCPv4-response Message Flags 300 This document introduces no flags to be carried in the "flags" field 301 of the DHCPv4-response message. They are all reserved for the future 302 use. The DHCP 4o6 server MUST set all bits of this field to 0 and 303 the DHCP 4o6 client MUST ignore the content in this field. 305 6. New DHCPv6 Options 307 6.1. DHCPv4 Message Option Format 309 The DHCPv4 Message option carries a DHCPv4 message that is sent by 310 the client or the server. Such messages exclude any IP or UDP 311 headers. 313 The format of the DHCPv4 Message option is: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | OPTION_DHCPV4_MSG | option-len | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 . DHCPv4-message . 322 . . 323 . . 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 4: DHCPv4 Message option Format 328 option-code OPTION_DHCPV4_MSG (TBD). 330 option-len Length of the DHCPv4 message. 332 DHCPv4-message The DHCPv4 message sent by the client or the server. 333 In a DHCPv4-query message it contains a DHCPv4 334 message sent by a client. In a DHCPv4-response 335 message it contains a DHCPv4 message sent by a server 336 in response to a client. 338 6.2. 4o6 Server Address Option Format 340 The 4o6 Server Address option is sent by a server to a client 341 requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a 342 list of DHCP 4o6 server's IPv6 addresses that the client should 343 contact to obtain IPv4 configuration. This list may include 344 multicast and unicast addresses. The client sends its requests to 345 all unique addresses carried in this option. 347 This option may also carry no IPv6 addresses, which instructs the 348 client to use the All_DHCP_Relay_Agents_and_Servers multicast address 349 as the destination address. 351 The presence of this option in the server's response indicates to the 352 client that it should use DHCPv4 over DHCPv6 to obtain IPv4 353 configuration. If the option is absent, the client MUST NOT enable 354 DHCPv4-over-DHCPv6 function. 356 The format of the 4o6 Server Address option is: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | OPTION_DHCP4_O_DHCP6_SERVER | option-len | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 . IPv6 Address(es) . 365 . . 366 . . 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 5: 4o6 Servers Address Option Format 371 option-code OPTION_DHCP4_O_DHCP6_SERVER (TBD). 373 option-len Length of the IPv6 address(es) carried by the option, 374 i.e. multiple of 16 octets. Minimal length of this 375 option is 0. 377 IPv6 Address Zero or more IPv6 addresses of the DHCP 4o6 378 Server(s). 380 7. Use of the DHCPv4-query Unicast Flag 382 A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST 383 message to either a broadcast or unicast address depending on its 384 state. For example, a client in the RENEWING state uses a unicast 385 address to contact the DHCPv4 server to renew its lease. A client in 386 the REBINDING state uses a broadcast address. 388 In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the 389 DHCP 4o6 server. There is no relation between the outer IPv6 address 390 and the inner DHCPv4 message. As a result, the server is unable to 391 determine whether the received DHCPv4 messages should have been sent 392 using broadcast or unicast in IPv4 by checking the IPv6 address. 394 In order to allow the server to determine the client's state, the 395 "Unicast" flag is carried in the DHCPv4-query message. The client 396 MUST set this flag to 1 when the DHCPv4 message would have been sent 397 to the unicast address if using DHCPv4 over IPv4. This flag MUST be 398 set to 0 if the DHCPv4 client would have sent the message to the 399 broadcast address in IPv4. The choice whether a given message should 400 be sent to a broadcast or unicast address is made based on the 401 [RFC2131] and its extensions. 403 Note: The "Unicast" flag reflects how the DHCPv4 packet would have 404 been sent; not how the DHCPv6 packet itself is sent. 406 8. DHCP 4o6 Client Behavior 408 The DHCPv4-over-DHCPv6 function MUST be disabled by default. The 409 client MUST obtain the necessary IPv6 configuration (stateless or 410 stateful) before using DHCPv4 over DHCPv6. The client intending to 411 use DHCPv4 over DHCPv6 MUST request the 4o6 Server Address option 412 using Option Request option (ORO) in every Solicit, Request, Renew, 413 Rebind and Information-request message. 415 The server MAY include the 4o6 Server Address option in its response 416 to the client. If the client receives this option, it enables the 417 DHCPv4-over-DHCPv6 function. The client MUST NOT enable the DHCPv4 418 -over-DHCPv6 function if the server does not include the 4o6 Server 419 Address option in its response. If the DHCPv6 configuration that 420 contained the 4o6 Server Address option subsequently expires, the 421 client MUST disable the DHCPv4-over-DHCPv6 function. If, when the 422 DHCPv6 configuration that contained the 4o6 Server Address option is 423 renewed, the renewed configuration does not contain a 4o6 Server 424 Address option, the client MUST disable the DHCPv4-over-DHCPv6 425 function. 427 It is possible in a multi-homed configuration for there to be more 428 than one DHCPv6 configuration active at the same time that contains a 429 4o6 Server Address option. In this case, the configurations are 430 treated as being independent, so that when any such configuration is 431 active, a DHCPv4-over-DHCPv6 function may be enabled for that 432 configuration. 434 An implementation may also treat such configurations as being 435 exclusive, such that only one is kept active at a time. In this 436 case, the client keeps the same configuration active continuously as 437 long as it is valid. If that configuration becomes invalid but one 438 or more other configurations remain valid, the client activates one 439 of the remaining valid configurations. 441 Which strategy to follow is dependent on the implementation: keeping 442 multiple configurations active at the same time may provide useful 443 redundancy in some applications, but may be needlessly complex in 444 other cases. 446 If the client receives the 4o6 Server Address option and there is a 447 DHCPv4 client active on the interface over which that DHCPv6 option 448 was received, it MUST stop the DHCPv4 client from sending messages 449 using [RFC2131]. 451 If the client receives a 4o6 Server Address option that contains no 452 IP addresses, i.e. the option is empty, the client MUST send its 453 requests to the All_DHCP_Relay_Agents_and_Servers multicast address. 454 If there is a list of IP addresses in the option, the client SHOULD 455 send requests to each unique address carried by the option. 457 If the client obtained stateless IPv6 configuration by sending 458 Information-request message to the server, the client MUST follow the 459 rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6 460 configuration (i.e. list of DHCP 4o6 servers) as well as other 461 configuration data. The client which obtained stateful IPv6 462 configuration will refresh the status of DHCPv4-over-DHCPv6 function 463 when extending a lifetime of acquired IPv6 address (Renew and Rebind 464 messages). 466 The client MUST employ an IPv6 address of an appropriate scope to 467 source the DHCPv4-query message from. When the client sends a 468 DHCPv4-query message to the multicast address, it MUST use a link- 469 local address as the source address as described in [RFC3315]. When 470 the client sends a DHCPv4-query message using unicast, the source 471 address MUST be an address of appropriate scope, acquired in advance. 473 The client generates a DHCPv4 message and stores it verbatim in the 474 DHCPv4 Message option carried by the DHCPv4-query message. The 475 client MUST put exactly one DHCPv4 Message option into a single 476 DHCPv4-query message. The client MUST NOT request the 4o6 Server 477 Address option in the DHCPv4-query message. 479 The client MUST follow rules defined in Section 7 when setting the 480 Unicast flag based on the DHCPv4 destination. 482 On receiving a DHCPv4-response message, the client MUST look for the 483 DHCPv4 Message option within this message. If this option is not 484 found, the DHCPv4-response message is discarded. If the DHCPv4 485 Message option is present, the client extracts the DHCPv4 message it 486 contains and processes it as described in section 4.4 of [RFC2131]. 488 When dealing with IPv4 configuration, the client MUST follow the 489 normal DHCPv4 retransmission requirements and strategy as specified 490 in section 4.1 of [RFC2131]. There are no explicit transmission 491 parameters associated with a DHCPv4-query message, as this is 492 governed by the DHCPv4 [RFC2131] "state machine". 494 The client MUST implement [RFC4361] to ensure that the device 495 correctly identifies itself. 497 9. Relay Agent Behavior 499 When a DHCPv6 relay agent receives a DHCPv4-query message, it may not 500 recognize this message. The unknown message can be forwarded as 501 described in [I-D.ietf-dhc-dhcpv6-unknown-msg]. 503 Additionally, the DHCPv6 relay agent MAY allow the configuration of a 504 dedicated DHCPv4 over DHCPv6 specific destination address(es), 505 differing from the address(es) of the DHCPv6-only server(s). To 506 implement this function, the relay checks the received DHCPv6 message 507 type and forwards according to the following logic: 509 1. If the message type is DHCPV4-QUERY, the packet is relayed to the 510 configured DHCP 4o6 Server's address(es) in the form of normal 511 DHCPv6 packet (i.e. DHCPv6/UDP/IPv6). 513 2. For any other DHCPv6 message type, forward according to section 514 20 of [RFC3315]. 516 The above logic only allows for separate relay destinations 517 configured on the relay agent closest to the client (single relay 518 hop). Multiple relaying hops are not considered in the case of 519 separate relay destinations. 521 10. DHCP 4o6 Server Behavior 523 When the server receives a DHCPv4-query message from a client, it 524 searches for the DHCPv4 Message option. The server discards the 525 packet without this option. The server MAY notify an administrator 526 about the receipt of a malformed packet. The mechanism for this 527 notification is out of scope for this document. 529 If the server finds a valid DHCPv4 Message option, it extracts the 530 original DHCPv4 message. Since the DHCPv4 message is encapsulated in 531 the DHCPv6 message, it lacks the information which is typically used 532 by the DHCPv4 server, implementing [RFC2131], to make address 533 allocation decisions, e.g. giaddr for relayed messages and IPv4 534 address of the interface which the server using to communicate with 535 directly connected client. Therefore, the DHCP 4o6 server allocates 536 addresses according to the local address assignment policies 537 determined by the server administrator. For example, if the 538 DHCPv4-query message has been sent via a relay, the server MAY use 539 the link-address field of the Relay-forward message as a lookup for 540 the IPv4 subnet to assign DHCPv4 address from. If the DHCPv4-query 541 message has been sent from a directly connected client, the server 542 MAY use IPv6 source address of the message to determine the 543 appropriate IPv4 subnet to use for DHCPv4 address assignment. 545 The server may also act as a DHCPv4 relay agent and forward the 546 DHCPv4 packet to a "normal" DHCPv4 server. In this case, the server 547 would need to set the giaddr to one of its own addresses and add 548 Relay Agent Information option (82), including a Link Selection 549 suboption [RFC3527] with the IPv4 subnet to assign a DHCPv4 address 550 from, as mentioned above. There are other complexities with this 551 solution as enough information needs to be retained (or included in a 552 Relay Agent Information option) to be able to return the response 553 back to the client; how this might be done is outside the scope of 554 this document. 556 The server SHOULD use "flags" field of the DHCPv4-query message to 557 create a response (server to client DHCPv4 message). The use of this 558 field is described in detail in Section 7. 560 When an appropriate DHCPv4 response is created, the server places it 561 in the payload of a DHCPv4 Message option, which it puts into the 562 DHCPv4-response message. 564 If the DHCPv4-query message was received directly by the server, the 565 DHCPv4-response message MUST be unicast from the interface on which 566 the original message was received. 568 If the DHCPv4-query message was received in a Relay-forward message, 569 the server creates a Relay-reply message with the DHCPv4-response 570 message in the payload of a Relay Message option, and responds as 571 described in section 20.3 of [RFC3315]. 573 11. Security Considerations 575 In this specification, DHCPv4 messages are encapsulated in the newly 576 defined option and messages. This is similar to the handling of the 577 current relay agent messages. In order to bypass firewalls or 578 network authentication gateways, a malicious attacker may leverage 579 this feature to convey other messages using DHCPv6, i.e. use DHCPv6 580 as a form of encapsulation. However, the potential risk from this is 581 no more severe than that with the current DHCPv4 and DHCPv6 practice. 583 It is possible for a rogue server to reply with a 4o6 Server Address 584 Option containing duplicated IPv6 addresses, which could cause an 585 amplification attack. To avoid this, the client MUST check if there 586 are duplicate IPv6 addresses in a 4o6 Server Address Option when 587 receiving one. The client MUST ignore any but the first instance of 588 each address. 590 12. IANA Considerations 592 IANA is requested to allocate two DHCPv6 option codes for use by 593 OPTION_DHCPV4_MSG, OPTION_DHCP4_O_DHCP6_SERVER from the "DHCP Option 594 Codes" table, and two DHCPv6 message type codes for the DHCPV4-QUERY 595 and DHCPV4-RESPONSE from the "DHCP Message Codes" table of the 596 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Registry. Both 597 tables can be found at http://www.iana.org/assignments/ 598 dhcpv6-parameters/dhcpv6-parameters.xml. 600 13. Contributors List 602 Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen 603 and Cong Liu, for their great contributions to the draft. 605 14. References 607 14.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, March 1997. 612 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 613 2131, March 1997. 615 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 616 and M. Carney, "Dynamic Host Configuration Protocol for 617 IPv6 (DHCPv6)", RFC 3315, July 2003. 619 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 620 Time Option for Dynamic Host Configuration Protocol for 621 IPv6 (DHCPv6)", RFC 4242, November 2005. 623 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 624 Identifiers for Dynamic Host Configuration Protocol 625 Version Four (DHCPv4)", RFC 4361, February 2006. 627 14.2. Informative References 629 [I-D.ietf-dhc-dhcpv6-unknown-msg] 630 Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 631 Messages", draft-ietf-dhc-dhcpv6-unknown-msg-08 (work in 632 progress), March 2014. 634 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 635 "Link Selection sub-option for the Relay Agent Information 636 Option for DHCPv4", RFC 3527, April 2003. 638 Authors' Addresses 640 Qi Sun 641 Tsinghua University 642 Beijing 100084 643 P.R.China 645 Phone: +86-10-6278-5822 646 Email: sunqi@csnet1.cs.tsinghua.edu.cn 648 Yong Cui 649 Tsinghua University 650 Beijing 100084 651 P.R.China 653 Phone: +86-10-6260-3059 654 Email: yong@csnet1.cs.tsinghua.edu.cn 655 Marcin Siodelski 656 950 Charter Street 657 Redwood City, CA 94063 658 USA 660 Phone: +1 650 423 1431 661 Email: msiodelski@gmail.com 663 Suresh Krishnan 664 Ericsson 666 Email: suresh.krishnan@ericsson.com 668 Ian Farrer 669 Deutsche Telekom AG 670 GTN-FM4,Landgrabenweg 151 671 Bonn, NRW 53227 672 Germany 674 Email: ian.farrer@telekom.de