idnits 2.17.1 draft-ietf-dhc-v4configuration-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2014) is 3726 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-04 == 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-06 == 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-05 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 -- 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: August 16, 2014 Deutsche Telekom AG 6 February 12, 2014 8 Provisioning IPv4 Configuration Over IPv6 Only Networks 9 draft-ietf-dhc-v4configuration-05 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 approaches to be used as 23 the basis for future deployment and development. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Overview of IPv4 Parameter Configuration Approaches . . . 4 61 1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 4 62 1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 6 63 1.4. DHCPv6 + Stateless DHCPv4oSW Based Provisioning - 64 Functional Overview . . . . . . . . . . . . . . . . . . . 6 65 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 7 66 2. Requirements for the Solution Evaluation . . . . . . . . . . 8 67 3. Comparison of the Four Approaches . . . . . . . . . . . . . . 9 68 3.1. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 9 69 3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.2. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 10 72 3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning . . . . . 11 75 3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11 76 3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.4. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 12 78 3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 12 79 3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5. Transporting Unmodified DHCPv4 Messages over an IPv6 Link 82 Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.1. Combined Hub and DHCPv4 Relay Required Functionality . . 14 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 7.1. DHCPv4oIPv6 . . . . . . . . . . . . . . . . . . . . . . . 15 87 7.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7.3. DHCPv6+DHCPv4oSW . . . . . . . . . . . . . . . . . . . . 15 89 7.4. DHCPv4oDHCPv6 . . . . . . . . . . . . . . . . . . . . . . 15 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 9. Informative References . . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 A service provider with an IPv6-only network must also be able to 97 provide customers with access to the IPv4 Internet and other 98 IPv4-only services. IPv4 over IPv6 tunneling / translation 99 mechanisms are an obvious example of this, such as the ones described 100 in: 102 o [I-D.ietf-softwire-lw4over6] 104 o [I-D.ietf-softwire-map] 106 o [I-D.ietf-softwire-map-t] 108 In today's home networks, each residential user is allocated a single 109 global IPv4 address which is used for NAT44. Decentralizing NAT44 110 allows for much better scaling and, when combined with stateless 111 network functions, can simplify redundancy and logging when compared 112 to centralized Carrier Grade NAT architectures. This results in the 113 need to provision a number of configuration parameters to the CPE, 114 such as the external public IPv4 address and a restricted port-range 115 to use for NAT. Other parameters may also be necessary, depending on 116 the underlying transport technology that is in use. In IPv4 only 117 networks, DHCPv4 has often been used to provide IPv4 configuration, 118 but in an IPv6 only network, DHCPv4 messages cannot be transported 119 natively without either IPv6 encapsulation or translation. 121 DHCPv4 messages can be transported, unmodified, over a broadcast 122 capable link-layer, depending on the underlying IPv4 in IPv6 123 technology, network topology and DHCPv4 client capabilities. A 124 functional description of how unmodified DHCPv4 can be used is 125 provided in Section 5. This approach is recommended for service 126 providers whose network and clients can support this DHCPv4 127 architecture. 129 For the most simple IPv4 provisioning case, where the client only 130 needs to receive a static IPv4 address assignment (with no dynamic 131 address leasing or additional IPv4 configuration), a DHCPv6 based 132 approach (e.g. [I-D.ietf-softwire-map-dhcp]) may provide a suitable 133 solution. 135 This document is concerned with more complex IPv4 configuration 136 scenarios, to bring IPv4 configuration over IPv6-only networks in 137 line with the functionality offered by DHCPv4 in IPv4 native 138 networks. DHCPv4 options may also need to be conveyed to clients for 139 configuring IPv4 based services, e.g., SIP server addresses. 141 Although IPv4-in-IPv6 softwire tunnel and translation clients are 142 currently the only use-case for DHCP based configuration of IPv4 143 parameters in IPv6 only networks, a suitable IPv4 provisioning 144 solution should not be limited to only supporting the configuration 145 of softwires, or be bound to specific IPv4 over IPv6 architectures or 146 mechanisms. The solution needs to be flexible enough to support new 147 IPv4 over IPv6 technologies as they are developed. 149 This document describes and compares four different methods which 150 have been proposed as solutions to this problem. 152 1.1. Overview of IPv4 Parameter Configuration Approaches 154 The following approaches for transporting IPv4 configuration 155 parameters over IPv6 only networks have been suggested: 157 1. Adapt DHCPv4 format messages to be transported over IPv6 as 158 described in [I-D.ietf-dhc-dhcpv4-over-ipv6]. For brevity, this 159 is referred to as DHCPv4o6. 161 2. Extend DHCPv6 to support IPv4 address leasing and other DHCPv4 162 options. 164 3. Use DHCPv6 for external IPv4 address and source port 165 configuration (e.g. [I-D.ietf-softwire-map-dhcp]. Use DHCPv4 166 over IPv4 messages within an IPv6 softwire for configuring 167 additional parameters. This is referred to as DHCPv6 + Stateless 168 DHCPv4oSW. 170 4. Use DHCPv4 format messages, transporting them within a new DHCPv6 171 message type as described in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. 172 This is referred to as DHCPv4oDHCPv6. 174 At the time of writing, working examples of the first two methods 175 have been developed and successfully tested in several different 176 operators networks. 178 The following sections provide describe each of the approaches in 179 more detail. 181 1.2. DHCPv4o6 Based Provisioning - Functional Overview 183 In order to receive IPv4 configuration parameters, IPv4-only clients 184 initiate and exchange DHCPv4 messages with the DHCPv4 server. To 185 adapt this for an IPv6-only network, an existing DHCPv4 client 186 implements a Host Client Relay Agent (HCRA) function, which takes 187 DHCPv4 messages and puts them into UDP and IPv6. 189 As the mechanism involves unicast IPv6 based communications, the IPv6 190 address of the server must be provisioned to the client. A DHCPv6 191 option for provisioning clients with this address is described in 192 [I-D.mrugalski-softwire-dhcpv4-over-v6-option]. 194 The IPv6 Transport Server (TSV) provides an IPv6 interface to the 195 client. This interface may be implemented directly on the server and 196 /or via an intermediary 'Transport Relay Agent' (TRA) device which 197 acts as the gateway between the IPv4 and IPv6 domains. 199 For the dynamic allocation of IPv4 addresses, the DHCPv4 server 200 function needs to be extended to add DHCPv4o6 TSV capabilities, such 201 as the storing the IPv6 address of DHCPv4o6 clients and implementing 202 the CRA6ADDR option. 204 This approach currently uses functional elements for ingress and 205 egress of the IPv6-only transport domain - the HCRA on the host and 206 the TRA or TSV on the server. As a result, this has sometimes been 207 referred to as a tunneling approach. However, relay agent 208 encapsulation is not a tunnel, since it carries only DHCP traffic; it 209 would be more accurate to describe it as an encapsulation based 210 transport. 212 [I-D.ietf-dhc-dhcpv4-over-ipv6] also defines an On-Link Client Relay 213 Agent (LCRA), which is a Client Relay Agent located on the same link 214 as an unmodified DHCPv4 client. It is worth noting that there is no 215 technical reason for using relay encapsulation for DHCPv4o6; this 216 approach was taken because the authors of the draft originally 217 imagined that it might be used to provide configuration information 218 for an unmodified DHCPv4 client. However, this turns out not to be a 219 viable approach: in order for this to work, there would have to be 220 IPv4 routing on the local link to which the client is connected. In 221 that case, there's no need for DHCPv4o6. 223 Given that this is the case, there is no technical reason why 224 DHCPv4o6 can't simply use the IPv6 transport directly, without any 225 relay encapsulation. This would greatly simplify the specification 226 and the implementation, and would still address the requirements 227 stated in this document. 229 [I-D.ietf-dhc-dhcpv4-over-ipv6] describes this solution in detail. 231 The protocol stack for provisioning IPv4/IPv6 tunneling and 232 translation mechanisms is as follows: 234 DHCPv4/UDP/IPv6 236 1.3. DHCPv6 Based Provisioning - Functional Overview 238 In this approach, DHCPv6 [RFC3315] would be extended with new DHCPv6 239 options for configuring all IPv4 based services and functions (i.e. 240 IPv4 address assignment and any necessary DHCPv4 options). DHCPv4 241 options needed by IPv4 clients connected to the IPv6 network are 242 updated as new DHCPv6 native options carrying IPv4 configuration 243 parameters. IPv4 address leasing would also need to be managed by 244 the DHCPv6 server. 246 At the time of writing, it is not known which or how many such 247 options would need to be ported from DHCPv4 to DHCPv6. 249 The protocol stack for provisioning IPv4/IPv6 tunneling and 250 translation mechanisms is as follows: 252 DHCPv6/UDP/IPv6 254 1.4. DHCPv6 + Stateless DHCPv4oSW Based Provisioning - Functional 255 Overview 257 In this approach, configuration of the IPv4 address and source ports 258 (if required) is carried out using DHCPv6, e.g. using 259 [I-D.ietf-softwire-map-dhcp]. Any additional IPv4 configuration 260 parameters that are required are then provisioned using DHCPv4 261 messages transported, within IPv6, through the configured softwire in 262 the same manner as any other IPv4 based traffic. Broadcast based 263 DHCPv4 DHCPDISCOVER messages (necessary for IPv4 address assignment) 264 can not be transported as some softwire mechanisms implement NBMA 265 links, where broadcast isn't supported. Additionally, there is a 266 more general issue with the use of fixed L4 ports in A+P [RFC6346] 267 based approaches. Here, a single IPv4 address is shared among 268 multiple users, each using a unique set of ports for differentiation 269 meaning that it is not possible for every client to be allocated a 270 fixed L4 within its unique port set. 272 On receipt by the tunnel concentrator (e.g. MAP Border Router or a 273 Lightweight 4over6 lwAFTR), the DHCPv4 message is extracted from the 274 IPv6 packet and forwarded to the DHCPv4 server in the same way as any 275 other IPv4 forwarding plane packet is handled. 277 As the client is already configured with its external IPv4 address 278 and source ports (using DHCPv6 or a well-known IPv4 address for DS- 279 Lite clients), the messages exchanged between the DHCPv4 client and 280 server would be strictly DHCPINFORM/DHCPACK messages. These can be 281 used for conveying additional DHCPv4 based options. 283 For this approach to function, a mechanism for the DHCPv4 client to 284 learn the IPv4 address of the DHCPv4 server is also required. This 285 could be via a well-known IPv4 address for the DHCPv4 server, a 286 DHCPv4 relay function within the tunnel concentrator or other 287 methods. 289 From a transport perspective, the key difference between this method 290 and DHCPv4o6 (described above) is the protocol stack. Here the 291 DHCPv4 message is first put into UDP and IPv4 and then into the IPv6 292 softwire, instead of placing the DHCPv4 message directly into UDP and 293 IPv6. 295 Currently, this approach is only theoretical and does not have a 296 corresponding Internet Draft providing more detail. 298 For IPv4/IPv6 tunneling and translation mechanism, the protocol stack 299 used for obtaining an IPv4 address and source ports (if required) is 300 as follows: 302 DHCPv6/UDP/IPv6 304 For provisioning IPv4/IPv6 tunneling mechanisms, the protocol stack 305 for obtaining additional IPv4 configuration is: 307 DHCPv4/UDP/IPv4 309 NB: The encapsulating IPv6 tunneling header is not shown as it is 310 functionally a layer 2 header. 312 And for provisioning IPv4/IPv6 translation mechanisms: 314 DHCPv4/UDP/IPv6 316 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview 318 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes transporting DHCPv4 319 messages within two new DHCPv6 messages types: DHCPV4-QUERY and 320 DHCPV4-RESPONSE. These new messages types must be implemented in 321 both the DHCPv4oDHCPv6 client and server. 323 In this approach, the configuration of stateless IPv4 addresses and 324 source ports (if required) is carried out using DHCPv6 as described 325 in section 1.3 above. Dynamic IPv4 addressing, and/or any additional 326 IPv4 configuration, is provided using DHCPv4 messages carried 327 (without IPv4/UDP headers) within a new OPTION_DHCPV4_MSG DHCPv6 328 option. 330 OPTION_DHCPV4_MSG enables the client and server to send BOOTP/DHCPv4 331 messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6 332 server receives a DHCPv6 request containing OPTION_BOOT_MSG within a 333 DHCPV4-QUERY message, it passes it to the DHCPv4 server engine. 334 Likewise, the DHCPv4 server place its DHCPv4 response in the payload 335 of OPTION_DHCPV4_MSG and puts this into a DHCPV4-RESPONSE message. 337 DHCPv4 messages can be carried within DHCPv6 multicast messages, 338 using the All_DHCP_Relay_Agents_and_Servers multicast address. These 339 can be relayed in exactly the same way as any other DHCPv6 340 multicasted messages. 342 Optionally, DHCPv6 relays could be updated so that they forward the 343 DHCPV4-QUERY message to a different destination address, allowing for 344 the separation of DHCPv4 and DHCPv6 provisioning infrastructure. 346 If the DHCPv4oDHCPv6 client is provisioned with a unicast IPv6 347 address(es) for the server(s), then an entirely unicast message flow 348 between the client and server is also possible without the need for 349 relaying. 351 For provisioning IPv4/IPv6 tunneling and translation mechanisms, the 352 protocol stack used for obtaining dynamic v4 addressing and/or 353 additional IPv4 configuration is as follows: 355 DHCPv4/DHCPv6/UDP/IPv6 357 2. Requirements for the Solution Evaluation 359 The following requirements have been defined to evaluate the 360 different approaches: 362 1. Minimize the amount of work necessary to implement the solution 363 through re-use of existing standards and implementations as much 364 as possible. 366 2. Provide a method of supporting all DHCPv4 options so that they 367 can be utilized without the need for further standardization. 369 3. Allow for the dynamic leasing of IPv4 addresses to clients. This 370 allows for more efficient use of limited IPv4 resources. 372 4. Enable the separation of IPv4 and IPv6 host configuration 373 infrastructure, i.e. independent DHCPv4 and DHCPv6 server 374 functions to restrict provisioning domains to the relevant 375 protocol and allow the removal of IPv4 infrastructure in the 376 future. 378 5. Avoid leaving legacy IPv4 options in DHCPv6. 380 6. Provide a flexible architecture to give operators the option of 381 only deploying the functional elements necessary for their 382 specific requirements. 384 7. Not be restricted to specific underlying IPv4 over IPv6 transport 385 mechanisms or architectures. The solution needs to be flexible 386 enough to support new IPv4 over IPv6 technologies as they are 387 developed. 389 3. Comparison of the Four Approaches 391 The table below provides a comparative evaluation showing how the 392 different approaches meet the solution requirements described above. 394 +--------+----------+--------+----------------------+---------------+ 395 | Req. | DHCPv4o6 | DHCPv6 | DHCPv6 + Stateless | DHCPv4oDHCPv6 | 396 | No. | | | DHCPv4oSW | | 397 +--------+----------+--------+----------------------+---------------+ 398 | 1 | No | Yes | No | Yes | 399 | 2 | Yes | No | Yes | Yes | 400 | 3 | Yes | No | No | Yes | 401 | 4 | Yes | No | Yes | Yes | 402 | 5 | Yes | No | Yes | Yes | 403 | 6 | No | No | Yes | Yes | 404 | 7 | Yes | Yes | No | Yes | 405 +--------+----------+--------+----------------------+---------------+ 407 Table 1: Approach Comparison 409 The following sections of the document provide more detail on the 410 pros and cons of each of the approaches. 412 3.1. DHCPv4o6 Based Provisioning 414 3.1.1. Pros 416 1. Implementation makes all existing DHCPv4 options available with 417 no further ongoing development work necessary. 419 2. IPv4 and IPv6 based provisioning can be separated from each other 420 if required, allowing flexibility in network design. 422 3. Easy to implement through minor adaptation of existing DHCPv4 423 client, relay and server code. 425 4. Suitable for dynamic IPv4 address leases where the IPv4 address 426 lifetime is not linked to the lifetime of a DHCPv6 lease. 428 5. Implementations already exist, proving that the approach works. 430 3.1.2. Cons 432 1. More new functional elements required within the architecture 433 (CRA, DHCPv4o6 server and optionally TRA) than are necessary in 434 DHCPv6 based provisioning. 436 2. A new DHCPv6 option is necessary in order to provision the IPv6 437 address of the DHCPv4 server to the end device. 439 3. The DHCPv4 client host needs to be updated to implement the IPv6 440 encapsulation and decapsulation function (i.e., an HCRA). 441 Otherwise a separate On-Link CRA (LCRA) functional element must 442 be deployed. 444 4. A DHCPv4 server must be deployed and maintained. 446 5. The DHCPv4 server needs to be updated to implement new DHCPv4o6 447 functionality. 449 3.2. DHCPv6 Based Provisioning 451 3.2.1. Pros 453 1. No additional functional elements are required except the DHCPv6 454 client and server. 456 2. A single protocol is used to deliver configuration information 457 for IPv4 and IPv6. 459 3. Single provisioning point for all configuration parameters. 461 3.2.2. Cons 463 1. Any required DHCPv4 options must be ported to DHCPv6, which will 464 require re-development work for each option. 466 2. Means that DHCPv4 'legacy' options (which will be of decreasing 467 relevance in the future) will remain in DHCPv6 for the lifetime 468 of the protocol. 470 3. Each time that a DHCPv4 option is ported to DHCPv6, all clients, 471 servers and possibly relays would need to be updated to implement 472 the new option. 474 4. Architecture does not allow for the separation of IPv4 and IPv6 475 domains. 477 5. Does not provide a mechanism for dynamic IPv4 address leasing. 478 The lifetime of the IPv4 address is linked to the lifetime of a 479 DHCPv6 address lease (i.e. the IPv4 address can only be changed 480 when a DHCPv6 RENEW/REBIND message is sent). To remove this 481 interdependency, a new DHCPv4 lease management mechanism would 482 need to be added to DHCPv6 (e.g. a new Identity Association 483 solely for IPv4 address leasing). 485 3.3. DHCPv6 + Stateless DHCPv4oSW Based Provisioning 487 3.3.1. Pros 489 1. Once implemented, all existing DHCPv4 options will be available 490 with no ongoing development work required. 492 2. Uses existing DHCPv4 and DHCPv6 architectures in order to provide 493 IPv4 configuration in an IPv6 only environment. 495 3. If required, DHCPv4 and DHCPv6 based provisioning can be 496 separated from each other, allowing flexibility in network 497 design. 499 3.3.2. Cons 501 1. More new functional elements required than are necessary with 502 DHCPv6 based provisioning. 504 2. IPv4 over IPv6 softwire approaches that distribute the NAT44 505 function to the CPE and allow for IP address sharing (MAP-E & 506 LW4o6) forbid the use of reserved TCP/UDP ports (e.g. 0-1024). 507 Every DHCPv4 client sharing the same address needs to have a UDP 508 listener running on UDP port 68. To resolve this would require 509 significant rework to either the softwire mechanisms and/or the 510 DHCPv4 client implementation. 512 3. From the current specification, DHCPINFORM is not suitable for 513 use over a softwire. Additional work, such as the development of 514 'shims' would be necessary. 516 4. The current DHCPINFORM specification has a number of unclear 517 points, such as those described in 518 [I-D.ietf-dhc-dhcpinform-clarify]. Substantial work would be 519 required to resolve this. 521 5. Links the deployment of IPv4 configuration over IPv6 to a 522 softwire implementation (e.g. requiring a softwire concentrator 523 to act as a DHCPv4 relay). Whilst softwires are the only 524 application for this functionality at the moment, this may not be 525 the case in the future, meaning another solution may be required. 527 6. A new mechanism must be defined in order to provide the DHCPv4 528 client with the IPv4 address of the DHCPv4 server so that unicast 529 DHCPINFORM messages can be sent. 531 7. As only the DHCPINFORM/DHCPACK DHCPv4 message types are 532 supported, dynamic IPv4 address leasing (using DHCPDISCOVER 533 messages) cannot be used. 535 8. Restricted to underlying hub-and-spoke IPv4 over IPv6 536 architectures. The hub is necessary to locate the DHCPv4 relay 537 function, as all traffic must pass through it. An underlying 538 mesh architecture does not have such a location to deploy the 539 relay function. 541 9. The approach is currently unproven. Although existing 542 implementations may currently exist, the approach has not been 543 demonstrated. 545 3.4. DHCPv4oDHCPv6 Based Provisioning 547 3.4.1. Pros 549 1. Once implemented, all existing DHCPv4 options will be available 550 with no ongoing development work necessary. 552 2. Uses existing DHCPv4 and DHCPv6 architectures in order to provide 553 IPv4 configuration in an IPv6 only environment. 555 3. If required, DHCPv4 and DHCPv6 based provisioning can be 556 separated from each other, allowing flexibility in network 557 design. 559 4. Suitable for the provisioning of dynamic IPv4 configuration as 560 the existing DHCPv4 leasing mechanism can be used. 562 3.4.2. Cons 564 1. More new functional elements within the architecture than are 565 necessary in DHCPv6 based provisioning. 567 2. DHCPv6 clients need to be updated to implement the new DHCPv6 568 message types (BOOTPREQUESTv6 and BOOTPREPLYv6). 570 3. The DHCPv6 server needs to be updated to implement the new 571 DHCPv4oDHCPv6 message types and functionality. 573 4. The approach is currently unproven as no existing implementations 574 exist. 576 4. Conclusion 578 Whilst all of the approaches described here will require some 579 development work to realize, it is clear from the above analysis that 580 the most sustainable approach capitalizes on existing DHCPv4 581 implementations and include them as new DHCPv6 message types. The 582 main rationale for this is that it enables all of DHCPv4's existing 583 options to be migrated for use over IPv6 in a single step. 585 Porting of all necessary DHCPv4 options to DHCPv6 would require 586 ongoing development work, re-implementing existing DHCPv4 587 functionality in DHCPv6. This will result in having legacy DHCPv4 588 options in DHCPv6, which will no longer be useful once IPv4 is 589 completely abandoned. 591 Therefore, the DHCPv6 approach is not suitable for delivering IPv4 592 configuration parameters in an efficient, ongoing manner. 594 The dynamic leasing of IPv4 addresses is fundamental to the efficient 595 use of remaining IPv4 resources. This will become increasingly 596 important in the future, so a mechanism which supports this is 597 necessary. DHCPv6 + Stateless DHCPv4oSW does not provide this 598 function and so is not recommended. 600 The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 601 functionality) for all deployment scenarios, even when DHCPv4 602 specific functionality (e.g. sending DHCPv4 options) is not required 603 by the operator. 605 Therefore, this memo recommends DHCPv4oDHCPv6 606 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] as the best underlying approach for 607 provisioning IPv4 parameters over an IPv6 only network. 609 5. Transporting Unmodified DHCPv4 Messages over an IPv6 Link Layer 611 DHCPv4 can be transported across a broadcast capable link layer, such 612 as a softwire. Functionally, a DHCPv4 client operates on the link 613 layer interface (e.g. the softwire tunnel interface). As the link 614 layer must support broadcasts, DHCPDISCOVER and other broadcast 615 DHCPv4 messages can be transported. The DHCPv4 message flow is then 616 the same as described in section 3.1 of [RFC2131]. 618 For an unmodified DHCPv4 client to function over an IPv6 native 619 network, the underlying IPv4 over IPv6 architecture must be based on 620 a point-to-point link between the client and a central point (i.e. a 621 hub or tunnel concentrator) which all client DHCPv4 broadcast 622 messages will pass through. This hub must function as either the 623 DHCPv4 server or a DHCPv4 relay. The relay forwards broadcast DHCPv4 624 DHCPDISCOVER/DHCPREQUEST messages to a separate DHCPv4 server. 626 5.1. Combined Hub and DHCPv4 Relay Required Functionality 628 When the DHCPv4 relay function is co-located with the IPv4 in IPv6 629 hub function, there are some implementation considerations and 630 requirements that must be fulfilled. The following list describes 631 these. 633 1. Depending on the underlying IPv4 over IPv6 mechanism that the hub 634 is based upon, it may be necessary to modify the encapsulation/ 635 decapsulation or IPv6/IPv4 translation packet validation policy 636 so that IPv4 payload packets sourced from the unspecified address 637 (0.0.0.0) are not dropped for broadcast DHCPv4 payload packets. 639 2. The DHCPv4 relay must use the DHCPv4 Relay Information Option 640 (option 82) Relay-ID sub-option (2) to convey the client's source 641 IPv6 address. This is used by the relay to route DHCPv4 response 642 packets sent by the DHCPv4 server to the correct client. 644 3. For some IPv4 in IPv6 transition technologies, a client may be 645 configured with an IPv4 address which is shared by other clients. 646 In these cases, clients using a single IPv4 address are 647 differentiated using the combination of the IPv4 address and a 648 range of restricted layer 4 source ports unique to each client 649 (used for NAPT). The DHCPv4 client L4 port (68) must not be 650 provisioned to any client for NAPT use. 652 4. The DHCPv4 relay must implement the Server Identifier Override 653 Sub-option described in [RFC5107] to direct all DHCPv4 messages 654 through the DHCPv4 relay. As option 82 is being used to identify 655 the destination IPv6 address for messages from the DHCPv4 server 656 to the client, the L4 destination port is not required for the 657 return path lookup process and is left unchanged as port 68. 659 6. IANA Considerations 661 This document does not make any request from IANA. 663 Note to RFC Editor: this section may be removed on publication as an 664 RFC. 666 7. Security Considerations 668 This document analyzes various solutions and doesn't introduce any 669 new capabilities necessitating additional security considerations. 670 The following sub-sections provide pointers to the documented 671 security considerations associated with each approach. 673 7.1. DHCPv4oIPv6 675 Security considerations associated with this approach are described 676 in Section 8 of [I-D.ietf-dhc-dhcpv4-over-ipv6]. 678 7.2. DHCPv6 680 Security considerations associated with this approach are described 681 in Section 23 of [RFC3315]. 683 7.3. DHCPv6+DHCPv4oSW 685 There is currently no document describing this mechanism, so no 686 security considerations have been documented. 688 7.4. DHCPv4oDHCPv6 690 Security considerations associated with this approach are described 691 in Section 11 of [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. 693 8. Acknowledgements 695 Thanks to Ted Lemon, Tomek Mrugalski, Ole Troan, Bernie Volz and 696 Francis Dupont for their input and reviews. 698 9. Informative References 700 [I-D.ietf-dhc-dhcpinform-clarify] 701 Hankins, D., "Dynamic Host Configuration Protocol 702 DHCPINFORM Message Clarifications", draft-ietf-dhc- 703 dhcpinform-clarify-06 (work in progress), October 2011. 705 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 706 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 707 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 708 dhcpv4-over-dhcpv6-04 (work in progress), January 2014. 710 [I-D.ietf-dhc-dhcpv4-over-ipv6] 711 Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 712 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08 713 (work in progress), October 2013. 715 [I-D.ietf-softwire-lw4over6] 716 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 717 I. Farrer, "Lightweight 4over6: An Extension to the DS- 718 Lite Architecture", draft-ietf-softwire-lw4over6-06 (work 719 in progress), February 2014. 721 [I-D.ietf-softwire-map-dhcp] 722 Mrugalski, T., Troan, O., Dec, W., Bao, C., 723 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 724 for configuration of Softwire Address and Port Mapped 725 Clients", draft-ietf-softwire-map-dhcp-06 (work in 726 progress), November 2013. 728 [I-D.ietf-softwire-map-t] 729 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 730 T. Murakami, "Mapping of Address and Port using 731 Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work 732 in progress), February 2014. 734 [I-D.ietf-softwire-map] 735 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 736 Murakami, T., and T. Taylor, "Mapping of Address and Port 737 with Encapsulation (MAP)", draft-ietf-softwire-map-10 738 (work in progress), January 2014. 740 [I-D.mrugalski-softwire-dhcpv4-over-v6-option] 741 Mrugalski, T. and P. Wu, "Dynamic Host Configuration 742 Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6 743 Endpoint", draft-mrugalski-softwire- 744 dhcpv4-over-v6-option-01 (work in progress), September 745 2012. 747 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 748 2131, March 1997. 750 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 751 and M. Carney, "Dynamic Host Configuration Protocol for 752 IPv6 (DHCPv6)", RFC 3315, July 2003. 754 [RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 755 "DHCP Server Identifier Override Suboption", RFC 5107, 756 February 2008. 758 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 759 IPv4 Address Shortage", RFC 6346, August 2011. 761 Authors' Addresses 763 Branimir Rajtar 764 Hrvatski Telekom 765 Zagreb 766 Croatia 768 Email: branimir.rajtar@t.ht.hr 770 Ian Farrer 771 Deutsche Telekom AG 772 Bonn 773 Germany 775 Email: ian.farrer@telekom.de