idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-dhcpv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 22, 2013) is 3779 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-03 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: May 26, 2014 M. Siodelski 6 ISC 7 S. Krishnan 8 Ericsson 9 I. Farrer 10 Deutsche Telekom AG 11 November 22, 2013 13 DHCPv4 over DHCPv6 Transport 14 draft-ietf-dhc-dhcpv4-over-dhcpv6-03 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 as well as new DHCPv6 options are defined for the purpose of 24 conveying DHCPv4 messages through IPv6 networks. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 26, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 64 5. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 5 66 5.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 5 67 5.3. Boot-request-v6 Message Flags . . . . . . . . . . . . . . 6 68 5.4. Boot-reply-v6 Message Flags . . . . . . . . . . . . . . . 6 69 6. New DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. BOOTP Message Option Format . . . . . . . . . . . . . . . 7 71 6.2. DHCPv4-over-DHCPv6 Enable Option Format . . . . . . . . . 7 72 6.3. 4o6 Server Address Option Format . . . . . . . . . . . . 8 73 7. Use of the Boot-request-v6 Unicast Flag . . . . . . . . . . . 8 74 8. 4o6 DHCP Client Behavior . . . . . . . . . . . . . . . . . . 9 75 9. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 10 76 10. 4o6 DHCP Server Behavior . . . . . . . . . . . . . . . . . . 11 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 13. Contributors List . . . . . . . . . . . . . . . . . . . . . . 12 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 14.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 As the migration towards IPv6 continues, IPv6-only networks will 88 become more prevalent. At the same time, IPv4 connectivity will 89 continue to be provided as a service over IPv6-only networks. In 90 addition to providing IPv4 addresses for clients of this service, 91 other IPv4 configuration parameters may also need to be provided 92 (e.g. addresses of IPv4-only services). 94 This document describes a transport mechanism to carry DHCPv4 95 messages using DHCPv6 protocol, for the dynamic provisioning of IPv4 96 addresses and other DHCPv4 specific configuration parameters across 97 IPv6-only networks. It leverages the existing infrastructure for 98 DHCPv4, e.g. failover, DNS updates, leasequery, etc. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Terminology 108 This document makes use of the following terms: 110 4o6 DHCP Client: A DHCP client which supports both DHCPv6 111 protocol [RFC3315] as well as the DHCPv4 over 112 DHCPv6 protocol described in this document. 113 Such a client is capable to request its IPv6 114 configuration using DHCPv6 and IPv4 115 configuration using DHCPv4 over DHCPv6. 117 4o6 DHCP Server: A DHCP server that is capable of processing 118 DHCPv4 packets encapsulated in the BOOTP 119 Message option (defined below). 121 CPE: Customer Premises Equipment (also known as 122 Customer Provided Equipment), which provides 123 the access of devices connected to Local Area 124 Network (typically at customer's site/home) to 125 Internet Service Provider's network. 127 DHCPv4 over DHCPv6: A protocol described in this document, which is 128 used to carry DHCPv4 messages in the payload of 129 DHCPv6 messages. 131 4. Architecture Overview 133 The architecture described in this document addresses a typical use 134 case, where a DHCP client's uplink supports IPv6 only and the Service 135 Provider's network supports IPv6 and limited IPv4 services. In this 136 scenario, the client can only use the IPv6 network to access IPv4 137 services. So it must configure IPv4 services using IPv6 as the 138 underlying network protocol. 140 Although the purpose of this document is to address the problem of 141 communication between the DHCPv4 client and the DHCPv4 server, the 142 mechanism that it describes does not restrict the transported 143 messages types only to DHCPv4. As the DHCPv4 message is a special 144 type of the BOOTP message, BOOTP messages can also be transported 145 using the same mechanism. 147 DHCP clients can be running on CPE devices, end hosts or any other 148 device which supports the DHCP client function. At the time of 149 writing, DHCP clients on CPE devices are easier to modify compared to 150 those implemented on end hosts. As a result, this document uses the 151 CPE as an example for describing the mechanism. This does not 152 preclude any end-host, or other device requiring IPv4 configuration, 153 from implementing the mechanism in the future. 155 This mechanism works by carrying DHCPv4 messages encapsulated within 156 DHCPv6 messages. Figure 1, below, illustrates one possible 157 deployment architecture. 159 The 4o6 DHCP client implements a new DHCPv6 message called Boot- 160 request-v6, which contains a new option called BOOTP Message option. 161 The format of this option is described in Section 6.1. 163 The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents 164 or directly to the 4o6 DHCP Server. The server replies with a Boot- 165 reply-v6 message, which is a new DHCPv6 message type. This message 166 carries the DHCPv4 response encapsulated in the BOOTP Message option. 168 _____________ _____________ 169 / \ / \ 170 | | | | 171 +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ 172 | 4o6 DHCP | network | DHCPv6 | network | 4o6 DHCP | 173 | Client +---------+ Relay Agent +---------+ Server | 174 | (on CPE) | | | | | 175 +--------+-+ +-+-----------+-+ +-+--------+ 176 | | | | 177 \_____________/ \_____________/ 179 Figure 1: Architecture Overview 181 By default, the DHCPv4-over-DHCPv6 function MUST be disabled on the 182 client. Before the client can use DHCPv4 over DHCPv6, it MUST obtain 183 the IPv6 configuration. It requests the DHCPv4-over-DHCPv6 Enable 184 option by sending its code in Option Request Option (ORO) described 185 in [RFC3315]. The DHCPv6 server includes the DHCPv4-over-DHCPv6 186 Enable option in response to a client's request to instruct the 187 client to use DHCPv4 over DHCPv6 for IPv4 configuration. The format 188 of the DHCPv4-over-DHCPv6 Enable option is described in Section 6.2. 190 Typically, a 4o6 DHCP client communicates with the 4o6 DHCP servers 191 using well-known All_DHCP_Relay_Agents_and_Servers multicast address. 193 Client SHOULD request the 4o6 Server Address Option from a DHCPv6 194 server and the server may be configured to respond to the client with 195 one such option that contains one or more unicast addresses of the 196 4o6 DHCP Servers. The server includes 4o6 Server Address Option in 197 Advertise and Reply messages. The format of the option is defined in 198 Section 6.3. 200 5. New DHCPv6 Messages 202 There are two new DHCPv6 messages defined in this document which 203 carry DHCPv4 messages between a client and a server using DHCPv6 204 protocol: Boot-request-v6 and Boot-reply-v6. This section describes 205 the structures of these messages. 207 5.1. Message Types 209 BOOTREQUESTV6 (TBD): Identifies a Boot-request-v6 message. A 4o6 210 DHCP client sends this message to a 4o6 DHCP 211 server. The BOOTP Message Option carried by 212 this message contains a BOOTREQUEST message 213 that the 4o6 DHCP client uses to request IPv4 214 configuration parameters from the server. 216 BOOTREPLYV6 (TBD): Identifies a Boot-reply-v6 message. A 4o6 DHCP 217 server sends this message to a 4o6 DHCP client. 218 It contains a BOOTP Message Option carrying a 219 BOOTREPLY message in response to a BOOTREQUEST 220 received by the server in the BOOTP Message 221 Option of the Boot-request-v6 message. 223 5.2. Message Formats 225 Both DHCPv6 messages defined in this document share the following 226 format: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | msg-type | flags | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 . options . 235 . (variable) . 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 2: Architecture Overview 241 msg-type Identifies message type. It can be either 242 BOOTREQUESTV6 (TBD) or BOOTREPLYV6 (TBD) which 243 corresponds to the Boot-request-v6 or Boot-reply-v6, 244 respectively. 246 flags Specifies flags which provide additional information 247 required by the server to process a DHCPv4 message 248 encapsulated in Boot-request-v6 message, or required 249 by the client to process DHCPv4 message encapsulated 250 in Boot-reply-v6 message. 252 options The options carried by the message. The BOOTP 253 Message Option described in Section 6.1 MUST be 254 carried by the message. 256 5.3. Boot-request-v6 Message Flags 258 The "flags" field of the Boot-request-v6 is used to carry additional 259 information which may be used by the server to process the 260 encapsulated DHCPv4 message. Currently only one bit of this field is 261 used. Remaining bits are reserved for the future use. The "flags" 262 field has the following format: 264 0 1 2 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |U| Reserved | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3: Boot-request-v6 flags format 272 U Unicast Flag. If set to 1, it indicates that the 273 DHCPv4 message encapsulated with the Boot-request-v6 274 message would be sent to a unicast address if it was 275 sent using IPv4. If this flag is set to 0, it 276 indicates that the DHCPv4 message would be sent to 277 broadcast address if it was sent using IPv4. 279 Reserved Bits reserved for future use. A client that doesn't 280 implement future extensions using these bits MUST set 281 them to 0. 283 5.4. Boot-reply-v6 Message Flags 285 This document introduces no flags to be carried in the "flags" field 286 of the Boot-reply-v6 message. They are all reserved for the future 287 use. The 4o6 Server MUST set all bits of this field to 0 and the 4o6 288 client MUST ignore the content in this field. 290 6. New DHCPv6 Options 292 6.1. BOOTP Message Option Format 294 The BOOTP Message option carries a BOOTP message that is sent by the 295 client or the server. Such BOOTP messages exclude any IP or UDP 296 headers. 298 The format of the BOOTP Message Option is: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | OPTION_BOOTP_MSG | option-len | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 . BOOTP-message . 307 . . 308 . . 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 4: BOOTP Message Option Format 313 option-code OPTION_BOOTP_MSG (TBD). 315 option-len Length of BOOTP message. 317 BOOTP-message The BOOTP message sent by the client or the server. 318 In a Boot-request-v6 message it contains a 319 BOOTREQUEST message sent by a client. In a Boot- 320 reply-v6 message it contains a BOOTREPLY message sent 321 by a server in response to a client. 323 6.2. DHCPv4-over-DHCPv6 Enable Option Format 325 The DHCPv4-over-DHCPv6 Enable option is sent by the DHCPv6-only 326 server to signal that the client SHOULD use DHCPv4 over DHCPv6 to 327 obtain IPv4 configuration. The server includes this option if it is 328 requested by the client. 330 The format of the DHCPv4-over-DHCPv6 Enable option is: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | OPTION_DHCP4_O_DHCP6_ENABLE | option-len | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 5: DHCPv4-over-DHCPv6 Enable Option Format 339 option-code OPTION_DHCP4_O_DHCP6_ENABLE (TBD). 341 option-len 0 343 6.3. 4o6 Server Address Option Format 345 The 4o6 Server Address option carries one or more unicast IPv6 346 addresses of the 4o6 DHCP Server(s). The DHCPv6-only server includes 347 this option if it is requested by the client. 349 The format of the 4o6 Server Address option is: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | OPTION_DHCP4_O_DHCP6_SERVER | option-len | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | | 357 . IPv6 Address(es) . 358 . . 359 . . 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 6: 4o6 Servers Address Option Format 364 option-code OPTION_DHCP4_O_DHCP6_SERVER (TBD). 366 option-len Length of the IPv6 address(es) carried by the option, 367 i.e. multiple of 16 octets. 369 IPv6 Address One or more IPv6 addresses of the 4o6 DHCP Server(s). 371 7. Use of the Boot-request-v6 Unicast Flag 373 A DHCPv4 client conforming to the [RFC2131] may send its DHCPREQUEST 374 message to either broadcast or unicast address depending on its 375 state. For example, the client in the RENEWING state uses a unicast 376 address to contact a DHCPv4 server to renew its lease. The client in 377 the REBINDING state uses a broadcast address. If there is a DHCPv4 378 relay agent in the middle, a client in the RENEWING state may send a 379 DHCPREQUEST message to the unicast address of the relay agent. In 380 such case the server can't find out whether the client sent a message 381 to a unicast or broadcast address and thus it can't determine the 382 client's state. [RFC5010] introduced the "Flags Suboption" which 383 relay agents add to relayed messages to indicate whether broadcast or 384 unicast was used by the client. 386 In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the 387 4o6 DHCP Server. There is no relation between the outer IPv6 address 388 and the inner DHCPv4 message. So the server is not able to know 389 whether the DHCPv4 messages should have been sent using broadcast or 390 unicast in IPv4 by checking the IPv6 address. This is similar to the 391 case addressed by the [RFC5010]. 393 In order to allow the server to determine the client's state, the 394 "Unicast" flag is carried in the Boot-request-v6 message. Client 395 MUST set this flag to 1 when the DHCPv4 message would have been sent 396 to the unicast address if using DHCPv4 over IPv4. This flag MUST be 397 set to 0 if the DHCPv4 client would have sent the message to the 398 broadcast address in IPv4. The choice whether a given message should 399 be sent to a broadcast or unicast address MUST be made based on the 400 [RFC2131] and its extensions. 402 8. 4o6 DHCP Client Behavior 404 The DHCPv4-over-DHCPv6 function MUST be disabled by default. The 405 client MUST obtain its IPv6 configuration before using DHCPv4 over 406 DHCPv6. The client that intends to use DHCPv4 over DHCPv6 MUST 407 request the DHCPv4-over-DHCPv6 Enable Option and SHOULD request the 408 4o6 Server Address Option in the Option Request Option (ORO) in every 409 Solicit, Request, Renew and Information-request messages. The 4o6 410 DHCP client MUST NOT request the DHCPv4-over-DHCPv6 Enable Option nor 411 the 4o6 Server Address Option in the Boot-request-v6 message. 413 The DHCPv6 server MAY include these options in the responses to the 414 client. The client determines how to enable the DHCPv4-over-DHCPv6 415 function based on the presence / absence of the two options: 417 o If the client doesn't receive the DHCPv4-over-DHCPv6 Enable 418 option, it MUST NOT enable the DHCPv4-over-DHCPv6 function. In 419 the case where the DHCPv4 over DHCPv6 service is running, the 420 client MUST disable the function. 422 o If the client receives the DHCPv4-over-DHCPv6 Enable Option but no 423 4o6 Servers Address Option, it SHOULD enable the DHCPv4-over- 424 DHCPv6 function and use IPv6 All_DHCP_Relay_Agents_and_Servers 425 multicast address to communicate with servers and relays. 427 o If the client receives both options, it SHOULD enable the DHCPv4 428 -over-DHCPv6 function and send requests to the unicast address(es) 429 in the 4o6 Server Address Option. 431 o If the client only receives 4o6 Server Address Option, the client 432 MUST ignore the 4o6 Server Address Option and MUST NOT enable the 433 DHCPv4-over-DHCPv6 function. 435 The client supporting DHCPv4 over DHCPv6 SHOULD use Information 436 Refresh Time Option [RFC4242] to refresh the status of DHCPv4-over- 437 DHCPv6 service as well as other DHCPv6 configuration data. 439 The client signaled by the server to use DHCPv4 over DHCPv6 SHOULD 440 cease to send DHCPv4 messages using DHCP protocol described in 441 [RFC2131] and use the DHCPv4 over DHCPv6 to request IPv4 442 configuration from the 4o6 DHCP Server. The DHCPv4 message is stored 443 verbatim in the BOOTP Message option carried by the Boot-request-v6 444 message. The client MUST put exactly one BOOTP Message option into a 445 single Boot-request-v6 message. 447 Client MUST follow rules defined in Section 7 when setting Unicast 448 flag. 450 If the client has not received the 4o6 Server Addresses option from 451 the DHCPv6 server, it transmits the Boot-request-v6 message as 452 specified in Section 13 of [RFC3315]. If the client received this 453 option, it SHOULD send Boot-request-v6 message to all unicast 454 addresses listed in the option. 456 On receiving a Boot-reply-v6 message, the client MUST look for the 457 BOOTP Message option within this message. If this option is not 458 found, the Boot-reply-v6 message is discarded. If the BOOTP Message 459 Option presents, the client extracts the DHCPv4 message it contains 460 and processes it as described in section 4.4 of [RFC2131]. 462 When dealing with IPv4 configuration, the 4o6 DHCP client SHOULD 463 follow the normal DHCPv4 retransmission requirements and strategy as 464 specified in section 4.1 of [RFC2131]. There are no explicit 465 transmission parameters associated with a Boot-request-v6 message. 467 The 4o6 DHCP client MUST implement [RFC4361] to ensure that the 468 device correctly identifies itself. 470 9. Relay Agent Behavior 472 When a DHCPv6 relay agent receives a Boot-request-v6 message, it may 473 not recognize this message. It can just forward this message as in 474 [I-D.ietf-dhc-dhcpv6-unknown-msg]. 476 Additionally, the DHCPv6 relay agent MAY allow the configuration of a 477 dedicated DHCPv4 over DHCPv6 specific destination address(es), 478 differing from the address(es) of the DHCPv6-only server(s). To 479 implement this function, the relay checks the received DHCPv6 message 480 type and forwards according to the following logic: 482 1. If the message type is BOOTREQUESTV6, the packet is relayed to 483 the configured 4o6 DHCP Server's address(es) in the form of 484 normal DHCPv6 packet (i.e. DHCPv6/UDP/IPv6). 486 2. For any other DHCPv6 message type, forward according to section 487 20 of [RFC3315]. 489 The above logic only allows for separate relay destinations 490 configured on the relay agent closest to the client (single relay 491 hop). Multiple relaying hops are not considered in the case of 492 separate relay destinations. 494 10. 4o6 DHCP Server Behavior 496 When the server receives a Boot-request-v6 message from a client, it 497 searches for the BOOTP Message Option. The server discards the 498 packet without this option. The server MAY notify an administrator 499 about the receipt of a malformed packet. The mechanism for this 500 notification is out of scope for this document 502 If the server finds a valid BOOTP Message option, it extracts the 503 original DHCPv4 message and the contents of the "flags" field carried 504 in the Boot-request-v6 message and uses them to generate the 505 appropriate DHCPv4 response (server to client message). The response 506 is generated as described in [RFC2131] with the exception that the 507 server SHOULD use the information carried in the "flags" field of the 508 Boot-request-v6 message to find out whether the client's message 509 would have been sent to the broadcast or unicast address if DHCPv4 510 protocol was used. This is useful for the server to determine the 511 state of the client. The use of the "flags" field is described in 512 detail in Section 7. 514 When appropriate DHCPv4 response is generated, the 4o6 Server places 515 it in the payload of a BOOTP Message Option, which it puts into the 516 Boot-reply-v6 message. 518 If the Boot-request-v6 message was received directly by the server, 519 the Boot-reply-v6 message MUST be unicast from the interface on which 520 the original message was received. 522 If the Boot-request-v6 message was received in a Relay-forward 523 message, the server creates a Relay-reply message with the Boot- 524 reply-v6 message in the payload of a Relay Message option, and 525 responds as described in section 20.3 of [RFC3315]. 527 11. Security Considerations 528 In this specification, DHCPv4 messages are encapsulated in the newly 529 defined option and messages. This is similar to the handling of the 530 current relay agent messages. In order to bypass firewalls or 531 network authentication gateways, a malicious attacker may leverage 532 this feature to convey other messages using DHCPv6, i.e. use DHCPv6 533 as a form of encapsulation. However, the potential risk from this is 534 no more severe than that with the current DHCPv4 and DHCPv6 practice. 536 There are chances that a rogue DHCPv6 server may reply with a 4o6 537 Server Address Option containing duplicated unicast IPv6 addresses, 538 which can cause an amplification attack. To avoid this, the client 539 MUST check if there are repeated IPv6 addresses in a 4o6 Server 540 Address Option when receiving one. The client MUST ignore those 541 duplicated unicast IPv6 addresses. 543 12. IANA Considerations 545 IANA is requested to allocate three DHCPv6 option codes for use by 546 OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and 547 OPTION_DHCP4_O_DHCP6_SERVERS, and two DHCPv6 message type codes for 548 the BOOTREQUESTV6 and BOOTREPLYV6. 550 13. Contributors List 552 Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen 553 and Cong Liu, for their great contributions to the draft. 555 14. References 557 14.1. Normative References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, March 1997. 562 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 563 2131, March 1997. 565 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 566 and M. Carney, "Dynamic Host Configuration Protocol for 567 IPv6 (DHCPv6)", RFC 3315, July 2003. 569 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 570 Time Option for Dynamic Host Configuration Protocol for 571 IPv6 (DHCPv6)", RFC 4242, November 2005. 573 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 574 Identifiers for Dynamic Host Configuration Protocol 575 Version Four (DHCPv4)", RFC 4361, February 2006. 577 14.2. Informative References 579 [I-D.ietf-dhc-dhcpv6-unknown-msg] 580 Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 581 Messages", draft-ietf-dhc-dhcpv6-unknown-msg-03 (work in 582 progress), November 2013. 584 [RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host 585 Configuration Protocol Version 4 (DHCPv4) Relay Agent 586 Flags Suboption", RFC 5010, September 2007. 588 Authors' Addresses 590 Qi Sun 591 Tsinghua University 592 Beijing 100084 593 P.R.China 595 Phone: +86-10-6278-5822 596 Email: sunqi@csnet1.cs.tsinghua.edu.cn 598 Yong Cui 599 Tsinghua University 600 Beijing 100084 601 P.R.China 603 Phone: +86-10-6260-3059 604 Email: yong@csnet1.cs.tsinghua.edu.cn 606 Marcin Siodelski 607 950 Charter Street 608 Redwood City, CA 94063 609 USA 611 Phone: +1 650 423 1431 612 Email: msiodelski@gmail.com 614 Suresh Krishnan 615 Ericsson 617 Email: suresh.krishnan@ericsson.com 618 Ian Farrer 619 Deutsche Telekom AG 620 GTN-FM4,Landgrabenweg 151 621 Bonn, NRW 53227 622 Germany 624 Email: ian.farrer@telekom.de