idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-dhcpv6-01.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 (July 15, 2013) is 3909 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) == Unused Reference: 'I-D.ietf-dhc-dhcpv4-over-ipv6' is defined on line 443, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-dhc-dhcpv6-unknown-msg-01 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-06 Summary: 1 error (**), 0 flaws (~~), 4 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: January 16, 2014 M. Siodelski 6 ISC 7 S. Krishnan 8 Ericsson 9 I. Farrer 10 Deutsche Telekom AG 11 July 15, 2013 13 DHCPv4 over DHCPv6 Transport 14 draft-ietf-dhc-dhcpv4-over-dhcpv6-01 16 Abstract 18 This document describes a mechanism for obtaining IPv4 address and 19 other parameters in IPv6 networks by carrying DHCPv4 messages over 20 DHCPv6 transport. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 16, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. New DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 3 60 5. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3 61 6. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 5 62 6.1. BOOTP Message Option Format . . . . . . . . . . . . . . . 5 63 6.2. DHCPv4-over-DHCPv6 Enable Option Format . . . . . . . . . 5 64 6.3. 4o6 Servers Address Option Format . . . . . . . . . . . . 6 65 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 8 67 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 12. Contributors List . . . . . . . . . . . . . . . . . . . . . . 9 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 13.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 As the migration towards IPv6 continues, IPv6 only networks will 79 become more prevalent. However, IPv4 connectivity will continue to 80 be provided as a service over these IPv6 only networks. In addition 81 to providing IPv4 addresses for clients of this service, other IPv4 82 configuration parameters may also need to be provided, (e.g. 83 addresses of IPv4-only services). 85 By conveying DHCPv4 messages over DHCPv6 transport, this mechanism 86 can achieve dynamic provisioning of IPv4 address and other 87 configuration parameters. In addition, it is able to leverage 88 existing infrastructure for DHCPv4, e.g. failover, DNS updates, 89 leasequery, etc. This mechanism is suitable for stateful allocation 90 and management of IPv4 addresses and configuration parameters across 91 IPv6 networks. 93 2. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Terminology 101 This document makes use of the following terms: 103 DHCP client: The 'DHCP client' in this document consists of 104 both DHCPv4 and DHCPv6 client engines. The 105 client is able to request IPv6 information 106 through DHCPv6, as well as to request IPv4 107 information using DHCPv4-over-DHCPv6 transport. 109 4o6 Server: A DHCP server capable of processing DHCPv4 110 packets wrapped in the BOOTP Message Option 111 (defined below). 113 DHCPv4-over-DHCPv6: A protocol described in this document, which is 114 used to carry DHCPv4 messages encapsulated in 115 DHCPv6 messages. 117 4. New DHCPv6 Messages 119 The following new DHCPv6 Client/Server messages are defined by this 120 document. These are formatted as specified in Section 6 of 121 [RFC3315]. 123 BOOTREQUESTV6 (TBD): A client sends a BOOTREQUESTV6 message to a 124 server, which contains a BOOTP Message Option. 125 The BOOTP Message Option contains a BOOTREQUEST 126 message that the client uses to request IPv4 127 configuration parameters from the server. 129 BOOTREPLYV6 (TBD): A server sends a BOOTREPLYV6 message containing 130 a BOOTP Message Option in response to a 131 client's BOOTREQUESTV6 message. The BOOTP 132 Message Option contains a BOOTREPLY message in 133 response to a BOOTREQUEST received by the 134 server in the BOOTP Message Option of a 135 BOOTREQUESTV6 message. 137 5. Architecture Overview 139 The architecture described in this document addresses a typical use 140 case, whereby a DHCP client's uplink supports IPv6 only and the 141 Service Provider's network supports IPv6 and limited IPv4 services. 142 In this scenario, the client can only use the IPv6 network to access 143 IPv4 services and so it must configure IPv4 services using IPv6 as 144 the underlying transport protocol. 146 Although the purpose of this document is to address the problem of 147 communication between DHCPv4 client and DHCPv4 server, the mechanism 148 it describes does not restrict the transported types of messages to 149 DHCPv4. BOOTP messages can be transported using the same mechanism. 151 DHCP clients can be running on CPE devices, end hosts or any other 152 device which supports the DHCP client function. At the time of 153 writing, DHCP clients on CPE devices are relatively easier to modify 154 compared to those implemented on end hosts. As a result, this 155 document uses the CPE as an example for describing the mechanism. 156 This doesn't preclude end hosts from implementing the mechanism in 157 the future. 159 This mechanism works by carrying encapsulated DHCPv4 messages over 160 DHCPv6 messages. Figure 1, below, illustrates one possible 161 deployment architecture. 163 The DHCP client implements a new DHCPv6 message called BOOTREQUESTV6, 164 which contains a new option called BOOTP Message Option. The format 165 of the option is described in Section 6.1. 167 The DHCPv6 packet can be transmitted either via Relay Agents or 168 directly to the 4o6 Server. The server replies with a relevant 169 DHCPv6 packet carrying DHCPv4 response wrapped with the BOOTP Message 170 Option. 172 _____________ _____________ 173 / \ / \ 174 | | | | 175 +--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+ 176 | DHCP | network | DHCP | network | 4o6 | 177 | Client +---------+ Relay Agent +---------+ Server | 178 | (on CPE) | | | | | 179 +--------+-+ +-+-----------+-+ +-+--------+ 180 | | | | 181 \_____________/ \_____________/ 183 Figure 1: Architecture Overview 185 The DHCPv4-over-DHCPv6 is by default disabled on the client. Before 186 client can use this protocol it MUST obtain configuration using 187 DHCPv6 as described in [RFC3315]. During this configuration, server 188 MAY include DHCPv4-over-DHCPv6 Enable Option in its Reply message to 189 indicate that client SHOULD use DHCPv4-over-DHCPv6 protocol to obtain 190 additional configuration. The format of the DHCPv4-over-DHCPv6 191 Enable Option is described in Section 6.2 192 Typically, client communicates with the 4o6 Servers using well known 193 All_DHCP_Relay_Agents_and_Servers multicast address. If DHCPv6 194 server is configured to do so, it MAY send unicast addresses of the 195 4o6 Servers to the client during client's configuration using DHCPv6. 196 The unicast addresses are carried in the 4o6 Server Addresses Option 197 encapsulated in the Reply message. The 4o6 Server Addresses Option's 198 format is defined in Section 6.3. 200 6. DHCPv6 Options 202 6.1. BOOTP Message Option Format 204 The BOOTP Message option carries a BOOTP message that is sent by the 205 client or the server. Such BOOTP messages exclude any IP or UDP 206 headers. 208 The format of the BOOTP Message Option is: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | OPTION_BOOTP_MSG | option-len | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 . BOOTP-message . 217 . . 218 . . 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 2: BOOTP Message Option Format 223 option-code OPTION_BOOTP_MSG (TBD) 225 option-len Length of BOOTP message 227 BOOTP-message The BOOTP message sent by the client or the server. 228 In a BOOTREQUESTV6 message it contains a BOOTREQUEST 229 message sent by client. In a BOOTREPLYV6 message it 230 contains a BOOTREPLY message sent by a server in 231 response to a client. 233 6.2. DHCPv4-over-DHCPv6 Enable Option Format 235 The DHCPv4-over-DHCPv6 Enable Option indicates that the client SHOULD 236 enable the DHCPv4-over-DHCPv6 function. 238 The format of the DHCPv4-over-DHCPv6 Enable Option is: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | OPTION_DHCP4_O_DHCP6_ENABLE | option-len | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 3: DHCPv4-over-DHCPv6 Enable Option Format 248 option-code OPTION_DHCP4_O_DHCP6_ENABLE (TBD) 250 option-len 0 252 6.3. 4o6 Servers Address Option Format 254 The 4o6 Servers Address Option carries unicast IPv6 addresses of the 255 4o6 Servers. 257 The format of the 4o6 Servers Address Option is: 259 0 1 2 3 260 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | OPTION_DHCP4_O_DHCP6_SERVERS | option-len | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 . IPv6 Address(es) . 266 . . 267 . . 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 4: 4o6 Servers Address Option Format 272 option-code OPTION_DHCP4_O_DHCP6_SERVERS (TBD) 274 option-len Length of the IPv6 address(es), i.e. integer times 275 of 16. 277 IPv6 Address The IPv6 address(es) of the 4o6 Server(s). 279 7. Client Behavior 281 The DHCP client SHOULD request the DHCPv4-over-DHCPv6 Enable Option 282 and the 4o6 Server Addresses Option in the Option Request Option 283 (ORO) to launch the DHCPv4-over-DHCPv6 function. 285 Client MUST NOT initiate communication with 4o6 Servers before it 286 obtains configuration using DHCPv6 as described in [RFC3315]. If 287 client supports DHCPv4-over-DHCPv6 function it SHOULD request the 288 DHCPv4-over-DHCPv6 Enable Option and 4o6 Server Addresses Option in 289 the Option Request Option (ORO). DHCPv6 server MAY include these 290 options in Reply message sent to the client. The client determines 291 how to launch the DHCPv4-over-DHCPv6 function using the presence / 292 absence of these two options: 294 o If the client doesn't receive the DHCPv4-over-DHCPv6 Enable 295 Option, it SHOULD NOT enable the DHCPv4 over DHCPv6 function. 297 o If the client receives the DHCPv4-over-DHCPv6 Enable Option but no 298 4o6 Servers Address Option, it SHOULD enable the DHCPv4-over- 299 DHCPv6 function, but use IPv6 multicast to communicate with the 300 servers or relays as described above. 302 o If the client receives both options, it SHOULD enable the DHCPv4 303 -over-DHCPv6 function, and send requests to all unicast addresses 304 conveyed by the 4o6 Server Addresses Option. 306 If client is instructed by the DHCPv6 server to use DHCPv4-over- 307 DHCPv6 function it MUST generate a DHCPv4 message to obtain 308 configuration from the 4o6 Server. This message is stored verbatim 309 in the BOOTP Message Option carried by the BOOTREQUESTV6 message. 310 Client MUST put exactly one BOOTP Message Option into a single 311 BOOTREQUESTV6 message. 313 If client did not receive a 4o6 Server Addresses Option from the 314 DHCPv6 server, it transmits the BOOTREQUESTV6 message as specified in 315 Section 13 of [RFC3315]. If client received this option it MUST send 316 BOOTREQUESTV6 message to all unicast addresses listed in the received 317 option. 319 When a client receives a BOOTREPLYV6 message, it MUST look for the 320 BOOTP Message Option within this message. If this option is not 321 found, the BOOTREPLYV6 message is discarded. If the BOOTP Message 322 Option is found, the client extracts the DHCPv4 message it contains 323 and processes it as described in section 4.4 of [RFC2131]. 325 DHCP clients are responsible for the retransmission of messages. 326 When requesting IPv4 information, the client SHOULD follow the normal 327 DHCPv4 retransmission requirements and strategy as specified in 328 section 4.1 of [RFC2131]. As a result there are no explicit 329 transmission parameters associated with a BOOTPREQUESTV6 message. 331 As the DHCPv4 and DHCPv6 clients are running on the same host, the 332 client MUST implement [RFC4361] to ensure that the device correctly 333 identifies itself. 335 The IPv4 address allocated from the server MAY be assigned to a 336 different interface from the IPv6 interface requesting the 337 information. Future documents depending on this memo MUST specify 338 which IPv6 interface is to be used by the client for that purpose. 340 8. Relay Agent Behavior 342 When a DHCPv6 relay agent receives a BOOTREQUESTV6 message, it MUST 343 handle the message as described in section 4 of 344 [I-D.ietf-dhc-dhcpv6-unknown-msg]. 346 A DHCPv6 relay agent MUST implement the Relay behaviour described in 347 section 20.1.1 of [RFC3315]. 349 Additionally, the DHCPv6 relay agent MAY allow the configuration of 350 dedicated DHCPv4 over DHCPv6 specific destination addresses, 351 differing from the addresses of the DHCPv6 only server(s). To 352 implement this function, the relay checks the received DHCPv6 message 353 type and forwards according to the following logic: 355 1. If the message type is BOOTREQUESTV6, then the DHCPv6 request is 356 relayed to the configured DHCPv4 aware 4o6 Server's address(es). 358 2. For any other DHCPv6 message type, forward according to section 359 20 of [RFC3315]. 361 The above logic only allows for separate relay destinations 362 configured on the relay agent closest to the client (single relay 363 hop). Multiple relaying hops are not considered in the case of 364 separate relay destinations. 366 9. Server Behavior 368 When server receives a BOOTREQUESTV6 message from a client, it 369 searches for a BOOTP Message Option. If this option is missing, the 370 server discards the packet. The server MAY notify an administrator 371 about the receipt of a malformed packet. The mechanism for this 372 notification is out of scope for this document 374 If the server finds a valid BOOTP Message Option, it extracts the 375 original DHCPv4 message sent by the client. This message is passed 376 to the DHCPv4 server engine, which generates a response to the client 377 as specified in [RFC2131]. This engine can be implemented as a 378 built-in DHCPv4 server function of the 4o6 Server, or it can be a 379 separate DHCPv4 server instance. Discussion regarding communication 380 between the 4o6 Server and a DHCPv4 server engine is out of scope for 381 this document. 383 When appropriate DHCPv4 response is generated, 4o6 Server places it 384 in the payload of a BOOTP Message Option, which it puts into the 385 BOOTREPLYV6 message. 387 If the BOOTREQUESTV6 message was received directly by the server, the 388 BOOTREPLYV6 message MUST be unicast from the interface on which the 389 original message was received. 391 If the BOOTREQUESTV6 message was received in a Relay-forward message, 392 the server creates a Relay-reply message with the BOOTREPLYV6 message 393 in the payload of a Relay Message Option, and responds as described 394 in section 20.3 of [RFC3315]. 396 10. Security Considerations 398 In this specification, DHCPv4 messages are encapsulated in the newly 399 defined option and messages. This is similar to handling the current 400 relay agent messages. In order to bypass firewalls or network 401 authentication gateways, a malicious attacker may leverage this 402 feature to convey other messages using DHCPv6, i.e. use DHCPv6 as a 403 form of encapsulation. However, the potential risk from this is no 404 greater than that with current DHCPv4 and DHCPv6 practice. 406 11. IANA Considerations 408 IANA is kindly requested to allocate three DHCPv6 option codes to the 409 OPTION_BOOTP_MSG, OPTION_DHCP4_O_DHCP6_ENABLE and 410 OPTION_DHCP4_O_DHCP6_SERVERS, and two DHCPv6 message type codes to 411 the BOOTREQUESTV6 and BOOTREPLYV6. 413 12. Contributors List 415 Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Yuchi Chen 416 and Cong Liu, for their great contributions to the draft. 418 13. References 420 13.1. Normative References 422 [I-D.ietf-dhc-dhcpv6-unknown-msg] 423 Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 424 Messages", draft-ietf-dhc-dhcpv6-unknown-msg-01 (work in 425 progress), June 2013. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 431 2131, March 1997. 433 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 434 and M. Carney, "Dynamic Host Configuration Protocol for 435 IPv6 (DHCPv6)", RFC 3315, July 2003. 437 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 438 Identifiers for Dynamic Host Configuration Protocol 439 Version Four (DHCPv4)", RFC 4361, February 2006. 441 13.2. Informative References 443 [I-D.ietf-dhc-dhcpv4-over-ipv6] 444 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 445 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in 446 progress), March 2013. 448 Authors' Addresses 450 Qi Sun 451 Tsinghua University 452 Department of Computer Science, Tsinghua University 453 Beijing 100084 454 P.R.China 456 Phone: +86-10-6278-5822 457 Email: sunqi@csnet1.cs.tsinghua.edu.cn 459 Yong Cui 460 Tsinghua University 461 Department of Computer Science, Tsinghua University 462 Beijing 100084 463 P.R.China 465 Phone: +86-10-6260-3059 466 Email: yong@csnet1.cs.tsinghua.edu.cn 468 Marcin Siodelski 469 950 Charter Street 470 Redwood City, CA 94063 471 USA 473 Phone: +1 650 423 1431 474 Email: msiodelski@gmail.com 475 Suresh Krishnan 476 Ericsson 478 Email: suresh.krishnan@ericsson.com 480 Ian Farrer 481 Deutsche Telekom AG 482 GTN-FM4,Landgrabenweg 151 483 Bonn, NRW 53227 484 Germany 486 Email: ian.farrer@telekom.de