idnits 2.17.1 draft-ietf-dhc-v4configuration-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2014) is 3753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-03 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-08 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-03 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-06 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-04 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-09 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC WG B. Rajtar 3 Internet-Draft Hrvatski Telekom 4 Intended status: Informational I. Farrer 5 Expires: July 19, 2014 Deutsche Telekom AG 6 January 15, 2014 8 Provisioning IPv4 Configuration Over IPv6 Only Networks 9 draft-ietf-dhc-v4configuration-04 11 Abstract 13 As IPv6 becomes more widely adopted, some service providers are 14 choosing to deploy IPv6 only networks without dual-stack 15 functionality for IPv4. However, as access to IPv4 based services 16 will continue to be a requirement for the foreseeable future, IPv4 17 over IPv6 mechanisms, such as softwire tunnels are being developed. 19 In order to provision end-user's hosts with the IPv4 configuration 20 necessary for such mechanisms, a number of different approaches have 21 been proposed. This memo discusses each of the proposals, identifies 22 the benefits and drawbacks and recommends a single approach as the 23 basis for future deployment and development. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 19, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Overview of IPv4 Parameter Configuration Approaches . . . 4 67 1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 5 68 1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 6 69 1.4. DHCPv6 + Stateless DHCPv4oSW Based Provisioning - 70 Functional Overview . . . . . . . . . . . . . . . . . . . 6 71 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 7 72 2. Requirements for the Solution Evaluation . . . . . . . . . . 8 73 3. Comparison of the Five Approaches . . . . . . . . . . . . . . 9 74 3.1. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 9 75 3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.2. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 10 78 3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning . . . . . 11 81 3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11 83 3.4. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 12 84 3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 12 86 3.5. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 13 87 3.5.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 13 88 3.5.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 13 89 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 5. Transporting Unmodified DHCPv4 Messages over an IPv6 91 Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 5.1. Combined Hub and DHCPv4 Relay Required Functionality . . 14 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 7.1. DHCPv4oIPv6 . . . . . . . . . . . . . . . . . . . . . . . 15 96 7.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 7.3. DHCPv6+DHCPv4oSW . . . . . . . . . . . . . . . . . . . . 15 98 7.4. DHCPv4oDHCPv6 . . . . . . . . . . . . . . . . . . . . . . 16 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 102 9.2. Informative References . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction 107 A service provider with an IPv6-only network must also be able to 108 provide customers with access to the IPv4 Internet and other 109 IPv4-only services. IPv4 over IPv6 tunneling / translation 110 mechanisms are an obvious example of this, such as the ones described 111 in: 113 o [I-D.ietf-softwire-lw4over6] 115 o [I-D.ietf-softwire-map] 117 o [I-D.ietf-softwire-map-t] 119 In today's home networks, each residential user is allocated a single 120 global IPv4 address which is used for NAT44. Decentralizing NAT44 121 allows for much better scaling and, when combined with stateless 122 network functions, can simplify redundancy and logging. This results 123 in the need to provision a number of configuration parameters to the 124 CPE, such as the external public IPv4 address and a restricted port- 125 range to use for NAT. Other parameters may also be necessary, 126 depending on the underlying transport technology that is in use. In 127 IPv4 only networks, DHCPv4 has often been used to provide IPv4 128 configuration, but in an IPv6 only network, DHCPv4 messages cannot be 129 transported natively without either IPv6 encapsulation or 130 translation. 132 DHCPv4 messages can be transported, unmodified, over a broadcast 133 capable link-layer, depending on the underlying IPv4 in IPv6 134 technology, network topology and DHCPv4 client capabilities. A 135 functional description of how unmodified DHCPv4 can be used is 136 provided in Section 5. This approach is RECOMMENDED for service 137 providers whose network and clients can support this DHCPv4 138 architecture. 140 For the most simple IPv4 provisioning case, where the client only 141 needs to receive a static IPv4 address assignment (with no dynamic 142 address leasing or additional IPv4 configuration), DHCPv6 based 143 approaches (e.g. [I-D.ietf-softwire-map-dhcp]) may provide a suitable 144 solution. 146 This document is concerned with more complex IPv4 configuration 147 scenarios, to bring IPv4 configuration over IPv6-only networks in 148 line with the functionality offered by DHCPv4 in IPv4 native 149 networks. DHCPv4 options may also need to be conveyed to clients for 150 configuring IPv4 based services, e.g., SIP server addresses. 152 Although IPv4-in-IPv6 softwire tunnel and translation clients are 153 currently the only use-case for DHCP based configuration of IPv4 154 parameters in IPv6 only networks, a suitable approach must not be 155 limited to only supporting softwires configuration or be reliant on 156 specific underlying IPv4 over IPv6 architectures or mechanisms. 158 This document describes and compares four different methods which 159 have been proposed as solutions to this problem. 161 1.1. Overview of IPv4 Parameter Configuration Approaches 163 The following approaches for transporting IPv4 configuration 164 parameters over IPv6 only networks have been suggested: 166 1. Adapt DHCPv4 format messages to be transported over IPv6 as 167 described in [I-D.ietf-dhc-dhcpv4-over-ipv6]. For brevity, this 168 is referred to as DHCPv4o6. 170 2. Extend DHCPv6 to support IPv4 address leasing and other DHCPv4 171 options. 173 3. Use DHCPv6 as above for external IPv4 address and source port 174 configuration. Use DHCPv4 over IPv4 messages within an IPv6 175 softwire for configuring additional parameters. This is referred 176 to as DHCPv6 + Stateless DHCPv4oSW. 178 4. Use DHCPv4 format messages, transporting them within a new DHCPv6 179 message type as described in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. 180 This is referred to as DHCPv4oDHCPv6. 182 At the time of writing, working examples of the first two methods 183 have been developed and successfully tested in several different 184 operators networks. The remaining two methods are still theoretical. 186 The following sections provide describe each of the approaches in 187 more detail. 189 1.2. DHCPv4o6 Based Provisioning - Functional Overview 191 In order to receive IPv4 configuration parameters, IPv4-only clients 192 initiate and exchange DHCPv4 messages with the DHCPv4 server. To 193 adapt this for an IPv6-only network, an existing DHCPv4 client 194 implements a 'Host Client Relay' (HCRA) function, which takes DHCPv4 195 messages and puts them into UDPv6 and IPv6. 197 As the mechanism involves unicast based communications, the IPv6 198 address of the server must be provisioned to the client. A DHCPv6 199 option for provisioning client's with this address is described in 200 [I-D.mrugalski-softwire-dhcpv4-over-v6-option]. 202 The IPv6 Transport Server (TSV) provides an IPv6 interface to the 203 client. This interface may be directly on the server and/or via an 204 intermediary 'Transport Relay Agent' (TRA) device acting as the 205 gateway between the IPv4 and IPv6 domains. 207 For the dynamic allocation of IPv4 addresses, the DHCPv4 server 208 function needs to be extended to add DHCPv4o6 TSV capabilities, such 209 as the storing the IPv6 address of DHCPv4o6 clients and implementing 210 the CRA6ADDR option. 212 This approach currently uses functional elements for ingress and 213 egress of the IPv6-only transport domain - the HCRA on the host and 214 the TRA or TSV on the server. As a result, this approach has 215 sometimes been referred to as a tunneling approach. However, relay 216 agent encapsulation is not a tunnel, since it carries only DHCP 217 traffic; it would be more accurate to describe it as an encapsulation 218 based transport. 220 [I-D.ietf-dhc-dhcpv4-over-ipv6] also defines an On-Link Client Relay 221 agent (LCRA), which is a Client Relay Agent located on the same link 222 as an unmodified DHCPv4 client. It is worth noting that there is no 223 technical reason for using relay encapsulation for DHCPv4o6; this 224 approach was taken because the authors of the draft originally 225 imagined that it might be used to provide configuration information 226 for an unmodified DHCPv4 client. However, this turns out not to be a 227 viable approach: in order for this to work, there would have to be 228 IPv4 routing on the local link to which the client is connected. In 229 that case, there's no need for DHCPv4o6. 231 Given that this is the case, there is no technical reason why 232 DHCPv4o6 can't simply use the IPv6 transport directly, without any 233 relay encapsulation. This would greatly simplify the specification 234 and the implementation, and would still address the requirements 235 stated in this document. 237 [I-D.ietf-dhc-dhcpv4-over-ipv6] describes this solution in detail. 239 The protocol stack is as follows: 241 DHCPv4/UDPv6/IPv6 243 1.3. DHCPv6 Based Provisioning - Functional Overview 245 In this approach, DHCPv6 [RFC3315] would be extended with new DHCPv6 246 options for configuring all IPv4 based services and functions (i.e. 247 IPv4 address assignment and any necessary DHCPv4 options). DHCPv4 248 options needed by IPv4 clients connected to the IPv6 network are 249 updated as new DHCPv6 native options carrying IPv4 configuration 250 parameters. IPv4 address leasing would also need to be managed by 251 the DHCPv6 server. 253 At the time of writing, it is not known which or how many such 254 options would need to be ported from DHCPv4 to DHCPv6. 256 The protocol stack is as follows: 258 DHCPv6/UDPv6/IPv6 260 1.4. DHCPv6 + Stateless DHCPv4oSW Based Provisioning - Functional 261 Overview 263 In this approach, the configuration of IPv4 address and source ports 264 (if required) is carried out using DHCPv6, e.g. using 265 [I-D.ietf-softwire-map-dhcp]. Any additional IPv4 configuration 266 parameters that are required are then provisioned using DHCPv4 267 messages transported within IPv6 in the configured softwire in the 268 same manner as any other IPv4 based traffic. Broadcast based DHCPv4 269 DHCPDISCOVER messages (necessary for IPv4 address assignment) can not 270 be transported as they are not compatible with the existing, unicast 271 based softwire architecture. 273 On receipt by the tunnel concentrator (e.g. MAP Border Router or a 274 Lightweight 4over6 lwAFTR), the DHCPv4 message is extracted from the 275 IPv6 packet and forwarded to the DHCPv4 server in the same way as any 276 other IPv4 forwarding plane packet is handled. 278 As the client is already configured with its external IPv4 address 279 and source ports (using DHCPv6 or a well-known IPv4 address for DS- 280 Lite clients), the messages exchanged between the DHCPv4 client and 281 server would be strictly DHCPINFORM/DHCPACK messages. These would be 282 used for the configuration of any additional IPv4 parameters. 284 For this approach to function, a mechanism for the DHCPv4 client to 285 learn the IPv4 address of the DHCPv4 server is also required. This 286 could be via a well-known IPv4 address for the DHCPv4 server, a 287 DHCPv4 relay function within the tunnel concentrator or other 288 methods. 290 From a transport perspective, the key difference between this method 291 and DHCPv4o6 (described above) is the protocol stack. Here the 292 DHCPv4 message is first put into UDPv4 and IPv4 and then into the 293 IPv6 softwire, instead of placing the DHCPv4 message directly into 294 UDPv6 and IPv6. 296 Currently, this approach is only theoretical and does not have a 297 corresponding Internet Draft providing more detail. 299 The protocol stack used for obtaining an IPv4 address and source 300 ports (if required) is as follows: 302 DHCPv6/UDPv6/IPv6 304 The protocol stack used for obtaining additional IPv4 configuration 305 is as follows: 307 DHCPv4/UDPv4/IPv4/IPv6 309 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview 311 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes transporting DHCPv4 312 messages within two new DHCPv6 messages types: BOOTREQUESTV6 and 313 BOOTREPLYV6. These new messages types must be implemented in both 314 the DHCPv4oDHCPv6 client and server. 316 In this approach, the configuration of stateless IPv4 addresses and 317 source ports (if required) is carried out using DHCPv6 as described 318 in section 1.3 above. Dynamic IPv4 addressing, and/or any additional 319 IPv4 configuration, is provided using DHCPv4 messages carried 320 (without IPv4/UDPv4 headers) within a new OPTION_BOOTP_MSG DHCPv6 321 option. 323 OPTION_BOOTP_MSG enables the client and server to send BOOTP/DHCPv4 324 messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6 325 server receives a DHCPv6 request containing OPTION_BOOT_MSG within a 326 BOOTREQUESTV6 message, it passes it to the DHCPv4 server engine. 327 Likewise, the DHCPv4 server place its DHCPv4 response in the payload 328 of OPTION_BOOTP_MSG and puts this into a BOOTPRPLYV6 message. 330 DHCPv4 messages can be carried within DHCPv6 multicast messages, 331 using the All_DHCP_Relay_Agents_and_Servers multicast address. These 332 can be relayed in exactly the same way as any other DHCPv6 333 multicasted messages. 335 Optionally, DHCPv6 relays could be updated so that they forward the 336 BOOTREQUESTV6 message to a different destination address, allowing 337 for the separation of DHCPv4 and DHCPv6 provisioning infrastructure. 339 If the DHCPv4oDHCPv6 client is provision with a unicast IPv6 340 address(es) for the server(s), then an entirely unicast message flow 341 between the client and server is also possible without the need for 342 relaying. 344 The protocol stack used for obtaining dynamic v4 addressing or 345 additional IPv4 configuration is as follows: 347 DHCPv4/DHCPv6/UDPv6/IPv6 349 2. Requirements for the Solution Evaluation 351 The following requirements have been defined to evaluate the 352 different approaches: 354 1. Minimize the amount of work necessary to implement the solution 355 through re-use of existing standards and implementations as much 356 as possible. 358 2. Provide a method of supporting all DHCPv4 options so that they 359 can be utilized without the need for further standardization. 361 3. Allow for the dynamic leasing of IPv4 addresses to clients. This 362 allows for more efficient use of limited IPv4 resources. 364 4. Enable the separation of IPv4 and IPv6 host configuration 365 infrastructure, i.e. independent DHCPv4 and DHCPv6 server 366 functions to restrict provisioning domains to the relevant 367 protocol and allow the removal of IPv4 infrastructure in the 368 future. 370 5. Avoid leaving legacy IPv4 options in DHCPv6. 372 6. Provide a flexible architecture to give operators the option of 373 only deploying the functional elements necessary for their 374 specific requirements. 376 7. Not restricted to specific IPv4 over IPv6 transport mechanisms or 377 architectures. 379 3. Comparison of the Five Approaches 381 The table below provides a comparative evaluation showing how the 382 different approaches meet the solution requirements described above. 384 +--------+----------+--------+----------------------+---------------+ 385 | Req. | DHCPv4o6 | DHCPv6 | DHCPv6 + Stateless | DHCPv4oDHCPv6 | 386 | No. | | | DHCPv4oSW | | 387 +--------+----------+--------+----------------------+---------------+ 388 | 1 | No | Yes | No | Yes | 389 | 2 | Yes | No | Yes | Yes | 390 | 3 | Yes | No | No | Yes | 391 | 4 | Yes | No | Yes | Yes | 392 | 5 | Yes | No | Yes | Yes | 393 | 6 | No | No | Yes | Yes | 394 | 7 | Yes | Yes | No | Yes | 395 +--------+----------+--------+----------------------+---------------+ 397 Table 1: Approach Comparison 399 The following sections of the document provide more detail on the 400 pros and cons of each of the approaches. 402 3.1. DHCPv4o6 Based Provisioning 404 3.1.1. Pros 406 1. Implementation makes all existing DHCPv4 options available with 407 no further ongoing development work necessary. 409 2. IPv4 and IPv6 based provisioning can be separated from each other 410 if required, allowing flexibility in network design. 412 3. Easy to implement through minor adaptation of existing DHCPv4 413 client, relay and server code. 415 4. No additional functional elements are necessary except the 416 DHCPv4o6 client relay agent and server. If a TSV is used, then a 417 TRA is not required. 419 5. Suitable for dynamic IPv4 address leases where the IPv4 address 420 lifetime is not linked to the lifetime of a DHCPv6 lease. 422 6. Implementations already exist, proving that the approach works. 424 3.1.2. Cons 426 1. More new functional elements required within the architecture 427 (CRA, DHCPv4o6 server and optionally TRA) than are necessary in 428 DHCPv6 based provisioning. 430 2. A new DHCPv6 option is necessary in order to provision the IPv6 431 address of the DHCPv4 server to the end device. 433 3. The DHCPv4 client host needs to be updated to implement the IPv6 434 encapsulation and decapsulation function (i.e. An HCRA). 435 Otherwise a separate On-Link CRA (LCRA) functional element must 436 be deployed. 438 4. A DHCPv4 server must be deployed and maintained. 440 5. The DHCPv4 server needs to be updated to implement new DHCPv4o6 441 functionality. 443 3.2. DHCPv6 Based Provisioning 445 3.2.1. Pros 447 1. No additional functional elements are required except the DHCPv6 448 client and server. 450 2. A single protocol is used to deliver configuration information 451 for IPv4 and IPv6. 453 3. Single provisioning point for all configuration parameters. 455 4. Implementations already exist, proving that the approach works. 457 3.2.2. Cons 459 1. Any required DHCPv4 options must be ported to DHCPv6, which will 460 require re-development work for each option. 462 2. Means that DHCPv4 'legacy' options (which will be of decreasing 463 relevance in the future) will remain in DHCPv6 for the lifetime 464 of the protocol. 466 3. Each time that a DHCPv4 option is ported to DHCPv6, all clients 467 and servers and possibly relays would need to be updated to 468 implement the new option. 470 4. Architecture does not allow for the separation of IPv4 and IPv6 471 domains. 473 5. Does not provide a mechanism for dynamic IPv4 address leasing, 474 where the lifetime of IPv4 addresses is not linked to the 475 lifetime of a DHCPv6 lease. A DHCPv4 lease lifetime management 476 mechanism would need to be added to DHCPv6 to implement this. 478 3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning 480 3.3.1. Pros 482 1. Once implemented, all existing DHCPv4 options will be available 483 with no ongoing development work necessary. 485 2. Uses existing DHCPv4 and DHCPv6 architectures in order to provide 486 IPv4 configuration in an IPv6 only environment. 488 3. DHCPv4 and DHCPv6 based provisioning can be separated from each 489 other if required, allowing flexibility in network design. 491 3.3.2. Cons 493 1. More new functional elements required than are necessary in 494 DHCPv6 based provisioning. 496 2. IPv4 over IPv6 softwire approaches that distribute NAT to the CPE 497 and allow for IP address sharing (MAP-E & LW4o6) forbid the use 498 of reserved TCP/UDP ports (e.g. 0-1024). Every DHCPv4 client 499 sharing the same address needs to have a UDP listener running on 500 UDP port 68. To resolve this would require significant rework to 501 either the softwire mechanisms and/or the DHCPv4 client 502 implementation. 504 3. From the current specification, DHCPINFORM is not suitable for 505 use over a softwire. Additional work, such as the development of 506 'shims' would be necessary. 508 4. The current DHCPINFORM specification has a number of unclear 509 points, such as those described in 510 [I-D.ietf-dhc-dhcpinform-clarify]. Substantial work would be 511 required to resolve this. 513 5. Links the deployment of IPv4 configuration over IPv6 to a 514 softwire implementation (e.g. requiring a softwire concentrator 515 to act as a DHCPv4 relay). Whilst softwires are the only 516 application for this functionality at the moment, this may not be 517 the case in the future, meaning another solution may be required. 519 6. A new mechanism must be defined in order to provide the DHCPv4 520 client with the IPv4 address of the DHCPv4 server so that unicast 521 DHCPINFORM messages can be sent. 523 7. As only the DHCPINFORM/DHCPACK DHCPv4 message types are 524 supported, dynamic IPv4 address leasing (using DHCPDISCOVER 525 messages) cannot be used. 527 8. Restricted to underlying hub-and-spoke IPv4 over IPv6 528 architectures. The 'hub' is necessary for the location of the 529 DHCPv4 relay, as all traffic must pass through it. An underlying 530 mesh architecture does not have such a location to deploy the 531 relay function. 533 9. The approach is unproven as no existing implementations exist. 535 3.4. DHCPv4oSW Based Provisioning 537 3.4.1. Pros 539 1. Once implemented, all existing DHCPv4 options will be available 540 with no ongoing development work necessary. 542 2. Uses existing DHCPv4 architecture in order to provide IPv4 543 configuration in an IPv6 only environment. 545 3. DHCPv4 and DHCPv6 based provisioning can be separated from each 546 other if required, allowing flexibility in network design. 548 3.4.2. Cons 550 1. Requires the DHCPv4 client, DHCPv4 server and softwire 551 concentrator (or other relaying device) to be modified. 553 2. May require the DHCPv4 client and server to be updated to use 554 dynamic ports taken from the restricted port set allocated to the 555 client instead of the well-known DHCPv4 ports. 557 3. The DHCPv4 client must be modified to identify the properties of 558 the interface it is configuring and request parameters 559 accordingly (e.g. restricted port-sets cannot be used on Ethernet 560 transport interfaces but are allowed for a softwire transport) 562 4. Restricted to underlying hub-and-spoke IPv4 over IPv6 563 architectures. The 'hub' is necessary for the location of the 564 DHCPv4 relay, as all traffic, including DHCPDISCOVER messages 565 will pass through it. An underlying mesh architecture does not 566 have such a location to deploy the relay. 568 3.5. DHCPv4oDHCPv6 Based Provisioning 570 3.5.1. Pros 572 1. Once implemented, all existing DHCPv4 options will be available 573 with no ongoing development work necessary. 575 2. Uses existing DHCPv4 and DHCPv6 architectures in order to provide 576 IPv4 configuration in an IPv6 only environment. 578 3. DHCPv4 and DHCPv6 based provisioning can be separated from each 579 other if required, allowing flexibility in network design. 581 4. Suitable for the provisioning of dynamic IPv4 configuration as 582 the existing DHCPv4 leasing mechanism can be used. 584 3.5.2. Cons 586 1. More new functional elements within the architecture than are 587 necessary in DHCPv6 based provisioning. 589 2. DHCPv6 clients needs to be updated to implement the new DHCPv6 590 message types (BOOTPREQUESTv6 and BOOTPREPLYv6). 592 3. The DHCPv6 server needs to be updated to implement new 593 DHCPv4oDHCPv6 message types and functionality. 595 4. The approach is currently unproven as no existing implementations 596 exist. 598 4. Conclusion 600 Whilst all of the approaches described here will require some 601 development work to realize, it is clear from the above analysis that 602 the most sustainable approach capitalizes on existing DHCPv4 603 implementations and include them as new DHCPv6 message types. The 604 main rationale for this is that it enables all of DHCPv4's existing 605 options to be migrated for use over IPv6 in a single step. 607 Porting of all necessary DHCPv4 options to DHCPv6 would require 608 ongoing development work, re-implementing existing DHCPv4 609 functionality in DHCPv6. This will result in having legacy DHCPv4 610 options in DHCPv6, which will no longer be useful once IPv4 is 611 completely abandoned. 613 Therefore, the DHCPv6 approach is not suitable for delivering IPv4 614 configuration parameters in an efficient, ongoing manner. 616 The dynamic leasing of IPv4 addresses is fundamental to the efficient 617 use of remaining IPv4 resources. This will become increasingly 618 important in the future, so a mechanism which supports this is 619 necessary. DHCPv6 + Stateless DHCPv4oSW does not provide this 620 function and so is not recommended. 622 The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 623 functionality) for all deployment scenarios, even when DHCPv4 624 specific functionality (e.g. sending DHCPv4 options) is not required 625 by the operator. 627 Therefore, this memo recommends DHCPv4oDHCPv6 628 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] as the best underlying approach for 629 provisioning IPv4 parameters over an IPv6 only network. 631 5. Transporting Unmodified DHCPv4 Messages over an IPv6 Link Layer 633 DHCPv4 can be transported across a broadcast capable link layer, such 634 as a softwire. Functionally, a DHCPv4 client operates on the link 635 layer interface (e.g. the softwire tunnel interface). As the link 636 layer must support broadcasts, DHCPDISCOVER and other broadcast 637 DHCPv4 messages can be transported. The DHCPv4 message flow is then 638 the same as described in section 3.1 of [RFC2131]. 640 For an unmodified DHCPv4 client to function over an IPv6 native 641 network, the underlying IPv4 over IPv6 architecture must be based on 642 a point-to-point link between the client and a central point (i.e. a 643 hub or tunnel concentrator) which all client DHCPv4 broadcast 644 messages will pass through. This hub must function as either the 645 DHCPv4 server or a DHCPv4 relay. The relay forwards broadcast DHCPv4 646 DHCPDISCOVER/DHCPREQUEST messages to a separate DHCPv4 server. 648 5.1. Combined Hub and DHCPv4 Relay Required Functionality 650 When the DHCPv4 relay function is co-located with the IPv4 in IPv6 651 hub function, there are some implementation considerations and 652 requirements that must be fulfilled. The following list describes 653 these. 655 1. Depending on the underlying IPv4 over IPv6 mechanism that the hub 656 is based upon, it may be necessary to modify the encapsulation/ 657 decapsulation or IPv6/IPv4 translation packet validation policy 658 so that IPv4 payload packets sourced from the unspecified address 659 (0.0.0.0) are not dropped for broadcast DHCPv4 payload packets. 661 2. The DHCPv4 relay must use the DHCPv4 Relay Information Option 662 (option 82) Relay-ID sub-option (2) to convey the client's source 663 IPv6 address. This is used by the relay to route DHCPv4 response 664 packets sent by the DHCPv4 server to the correct client. 666 3. For some IPv4 in IPv6 transition technologies, a client may be 667 configured with an IPv4 address which is shared by other clients. 668 In these cases, clients using a single IPv4 address are 669 differentiated using the combination of the IPv4 address and a 670 range of restricted layer 4 source ports unique to each client 671 (used for NAPT). The DHCPv4 client L4 port (68) must not be 672 provisioned to any client for NAPT use. 674 4. The DHCPv4 relay must implement the Server Identifier Override 675 Suboption described in [RFC5107] to direct all DHCPv4 messages 676 through the DHCPv4 relay. As option 82 is being used to identify 677 the destination IPv6 address for messages from the DHCPv4 server 678 to the client, the L4 destination port is not required for the 679 return path lookup process and is left unchanged as port 68. 681 6. IANA Considerations 683 This document does not make any request from IANA. 685 Note to RFC Editor: this section may be removed on publication as an 686 RFC. 688 7. Security Considerations 690 The following sections provide pointers to the documented security 691 considerations associated with each approach. 693 7.1. DHCPv4oIPv6 695 Security considerations associated with this approach are described 696 in Section 8 of [I-D.ietf-dhc-dhcpv4-over-ipv6]. 698 7.2. DHCPv6 700 Security considerations associated with this approach are described 701 in Section 23 of [RFC3315]. 703 7.3. DHCPv6+DHCPv4oSW 705 There is currently no document describing this mechanism, so no 706 security considerations have been documented. 708 7.4. DHCPv4oDHCPv6 710 Security considerations associated with this approach are described 711 in Section 10 of [RFC3315]. 713 8. Acknowledgements 715 Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan and Francis Dupont 716 for their input and reviews. 718 9. References 720 9.1. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 9.2. Informative References 727 [I-D.ietf-dhc-dhcpinform-clarify] 728 Hankins, D., "Dynamic Host Configuration Protocol 729 DHCPINFORM Message Clarifications", draft-ietf-dhc- 730 dhcpinform-clarify-06 (work in progress), October 2011. 732 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 733 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 734 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 735 dhcpv4-over-dhcpv6-03 (work in progress), November 2013. 737 [I-D.ietf-dhc-dhcpv4-over-ipv6] 738 Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 739 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08 740 (work in progress), October 2013. 742 [I-D.ietf-softwire-lw4over6] 743 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 744 I. Farrer, "Lightweight 4over6: An Extension to the DS- 745 Lite Architecture", draft-ietf-softwire-lw4over6-03 (work 746 in progress), November 2013. 748 [I-D.ietf-softwire-map-dhcp] 749 Mrugalski, T., Troan, O., Dec, W., Bao, C., 750 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 751 for configuration of Softwire Address and Port Mapped 752 Clients", draft-ietf-softwire-map-dhcp-06 (work in 753 progress), November 2013. 755 [I-D.ietf-softwire-map-t] 756 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 757 T. Murakami, "Mapping of Address and Port using 758 Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work 759 in progress), September 2013. 761 [I-D.ietf-softwire-map] 762 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 763 Murakami, T., and T. Taylor, "Mapping of Address and Port 764 with Encapsulation (MAP)", draft-ietf-softwire-map-09 765 (work in progress), December 2013. 767 [I-D.mrugalski-softwire-dhcpv4-over-v6-option] 768 Mrugalski, T. and P. Wu, "Dynamic Host Configuration 769 Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6 770 Endpoint", draft-mrugalski-softwire- 771 dhcpv4-over-v6-option-01 (work in progress), September 772 2012. 774 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 775 2131, March 1997. 777 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 778 and M. Carney, "Dynamic Host Configuration Protocol for 779 IPv6 (DHCPv6)", RFC 3315, July 2003. 781 [RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 782 "DHCP Server Identifier Override Suboption", RFC 5107, 783 February 2008. 785 Authors' Addresses 787 Branimir Rajtar 788 Hrvatski Telekom 789 Zagreb 790 Croatia 792 Email: branimir.rajtar@t.ht.hr 794 Ian Farrer 795 Deutsche Telekom AG 796 Bonn 797 Germany 799 Email: ian.farrer@telekom.de