idnits 2.17.1 draft-ietf-dhc-v4configuration-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 28, 2013) is 3985 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-00 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-06 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-00 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-03 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-06 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-unified-cpe-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: November 29, 2013 Deutsche Telekom AG 6 May 28, 2013 8 Provisioning IPv4 Configuration Over IPv6 Only Networks 9 draft-ietf-dhc-v4configuration-01 11 Abstract 13 As IPv6 becomes more widely adopted, some service providers are 14 taking the approach of deploying IPv6 only networks, without dual- 15 stack functionality for IPv4. However, access to IPv4 based services 16 is still an ongoing requirement and approaches such as IPv4-in-IPv6 17 softwire tunnels are being developed to meet this need. 19 In order to provision end-user's hosts with the necessary IPv4 20 configuration, a number of different mechanisms have been proposed. 21 This memo discusses the benefits and drawbacks of each, with the aim 22 of recommending a single approach as the basis for future work. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 29, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Overview of IPv4 Parameter Configuration Approaches . . . 3 65 1.2. DHCPv4o6 Based Provisioning - Functional Overview . . . . 4 66 1.3. DHCPv6 Based Provisioning - Functional Overview . . . . . 5 67 1.4. DHCPv4oSW Based Provisioning - Functional Overview . . . 5 68 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview . 6 69 2. Requirements for the Solution Evaluation . . . . . . . . . . 7 70 3. Comparison of the Four Approaches . . . . . . . . . . . . . . 8 71 3.1. DHCPv6 Based Provisioning . . . . . . . . . . . . . . . . 8 72 3.1.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2. DHCPv4o6 Based Provisioning . . . . . . . . . . . . . . . 9 75 3.2.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.3. DHCPv4oSW Based Provisioning . . . . . . . . . . . . . . 10 78 3.3.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.3.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.4. DHCPv4oDHCPv6 Based Provisioning . . . . . . . . . . . . 11 81 3.4.1. Pros . . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.4.2. Cons . . . . . . . . . . . . . . . . . . . . . . . . 11 83 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 89 8.2. Informative References . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 A service provider with an IPv6-only network must also be able to 95 provide customers with access to the Internet and other services over 96 IPv4. Softwire based IPv4-in-IPv6 tunneling mechanisms are an 97 obvious example of this, such as the ones described in: 99 o [I-D.ietf-softwire-lw4over6] 101 o [I-D.ietf-softwire-map] 103 o [I-D.ietf-softwire-unified-cpe] 105 A general trend here is to relocate NAT44 functionality and IPv4 106 address sharing from the centralized tunnel concentrator to the CPE 107 in order to achieve better scalability. This results in the need to 108 provision a number of configuration parameters to the CPE, such as 109 the external public IPv4 address and a restricted port-range to use 110 for NAT. 112 In order to configure customer's devices for softwire functionality, 113 a dynamic provisioning mechanism is necessary. In IPv4 only 114 networks, DHCPv4 has often been used to provide configuration, but in 115 an IPv6 only network, DHCPv4 messages cannot be transported natively. 117 Although softwire mechanisms are currently the only use-case for dhcp 118 based configuration of IPv4 parameters in IPv6 only networks, a 119 suitable approach must not be limited to only supporting softwire 120 configuration. 122 This document compares four different approaches which have been 123 proposed for resolving this problem. 125 1.1. Overview of IPv4 Parameter Configuration Approaches 127 In order to resolve the problem described above, the following 128 approaches for transporting IPv4 configuration parameters have been 129 suggested: 131 1. Adapt DHCPv4 format messages to be transported over IPv6 as 132 described in [I-D.ietf-dhc-dhcpv4-over-ipv6]. For brevity, this 133 is referred to as DHCPv4o6. 135 2. Extend DHCPv6 with new options for IPv4 configuration, such as 136 [I-D.ietf-softwire-map-dhcp] describes. 138 3. Use DHCPv6 as above for external IPv4 address and source port 139 configuration. Use DHCPv4 over IPv4 messages within an IPv6 140 softwire for configuring additional parameters. This is referred 141 to as DHCPv4oSW. 143 4. Use DHCPv4 format messages, transporting them within a new DHCPv6 144 message type as described in [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. 145 This is referred to as DHCPv4oDHCPv6. 147 At the time of writing, working examples of the first two approaches 148 have been developed and successfully tested in several different 149 operators networks. The third and fourth methods are still 150 theoretical. 152 The following sections provide more detail for each approach. 154 1.2. DHCPv4o6 Based Provisioning - Functional Overview 156 In order to receive IPv4 configuration parameters, IPv4-only clients 157 initiate and exchange DHCPv4 messages with the DHCPv4 server. In 158 order adapt this to an IPv6-only network, an existing DHCPv4 client 159 implements a 'Client Relay' (CRA) function, which takes DHCPv4 160 messages and puts them into UDPv6 and IPv6. 162 As the mechanism involves unicast based communications, the IPv6 163 address of the server must be provisioned to the client. This option 164 is described in [I-D.mrugalski-softwire-dhcpv4-over-v6-option]. 166 The DHCPv4o6 server must either provide an IPv6 interface to the 167 client, or an intermediary 'Transport Relay Agent' device can act as 168 the gateway between the IPv4 and IPv6 domains. 170 For the dynamic allocation of IPv4 addresses, the DHCPv4o6 server 171 needs to be extended to support the new functionality, such as 172 storing the IPv6 address of DHCPv4o6 clients. The CRA6ADDR option 173 must also be implemented. 175 This approach currently uses functional elements for ingress and 176 egress of the IPv6-only transport domain--the CRA on the host and the 177 TRA or TSV on the server. As a result, this approach has sometimes 178 been referred to as a tunneling approach. However, relay agent 179 encapsulation is not a tunnel, since it carries only DHCP traffic; it 180 would be more accurate to describe it as an encapsulation. 182 It is worth noting that there is no technical reason for using relay 183 encapsulation for DHCPv4o6; this approach was taken because the 184 authors of the draft originally imagined that it might be used to 185 provide configuration information for an unmodified DHCPv4 client. 186 However, this turns out not to be a viable approach: in order for 187 this to work, there would have to be IPv4 routing on the local link 188 to which the client is connected. In that case, there's no need for 189 DHCPv4o6. 191 Given that this is the case, there is no technical reason why 192 DHCPv4o6 can't simply use the IPv6 transport directly, without any 193 relay encapsulation. This would greatly simplify the specification 194 and the implementation, and would still address the requirements 195 stated in this document. 197 [I-D.ietf-dhc-dhcpv4-over-ipv6] decribes this solution in detail. 199 The protocol stack is as follows: 201 DHCPv4/UDPv6/IPv6 203 1.3. DHCPv6 Based Provisioning - Functional Overview 205 In this approach, DHCPv6 would be extended with new DHCPv6 options 206 for configuring all IPv4 based services and functions. Any DHCPv4 207 options needed by IPv4 clients connected to the IPV6 network are 208 updated as new DHCPv6 native options carrying IPv4 configuration 209 parameters. 211 At the time of writing, it is not known how many such options would 212 need to be ported from DHCPv4 to DHCPv6. 214 An example of this approach is described in 215 [I-D.ietf-softwire-map-dhcp], where a DHCPv6 message is used to 216 convey the parameters necessary for IPv4 in IPv6 softwire 217 configuration. 219 The protocol stack is as follows: 221 DHCPv6/UDPv6/IPv6 223 1.4. DHCPv4oSW Based Provisioning - Functional Overview 225 In this approach, the configuration of IPv4 address and source ports 226 (if required) is carried out using DHCPv6 as described in section 1.3 227 above. Any additional IPv4 configuration parameters which are 228 required are then provisioned using a DHCPv4 messages transported 229 within IPv6 in the configured softwire in the same manner as any 230 other IPv4 based traffic. 232 On receipt at the tunnel concentrator (e.g. MAP Border Router or a 233 Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the 234 softwire and forwarded to the DHCPv4 server in the same way as any 235 other IPv4 packet is handled. 237 As the client is already configured with its external IPv4 address 238 and source ports (using DHCPv6), the messages exchanged between the 239 DHCPv4 client and server would be strictly DHCPINFORM/DHCPACK 240 messages, for the configuration of additional IPv4 parameters. 241 Broadcast based DHCPDISCOVER messages can not be transported as they 242 are not compatible with the softwire architecture. 244 For this approach to function, a mechanism for the DHCPv4 client to 245 learn the IPv4 address of the DHCPv4 server is needed. This could be 246 done by defining a well-known IPv4 address for the DHCPv4 server, 247 implementing a DHCPv4 relay function within the tunnel concentrator 248 or other configuration methods. 250 From a transport perspective, the key difference between this method 251 and DHCPv4o6 (described above) is that here, the DHCPv4 message is 252 put into UDPv4 and IPv4 and then put into the IPv6 softwire, instead 253 of directly placing the DHCPv4 message into UDPv6 and IPv6. 255 Currently, this approach is only theoretical and does not have a 256 corresponding Internet Draft providing more detail. 258 The protocol stack that would be used for obtaining additional IPv4 259 configuraion is as follows: 261 DHCPv4/UDPv4/IPv4/IPv6 263 1.5. DHCPv4oDHCPv6 Based Provisioning - Functional Overview 265 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes the transport of DHCPv4 266 messages within two new DHCPv6 messages types: BOOTREQUESTV6 and 267 BOOTREPLYV6. These messages types must be implemented in both the 268 DHCPv4oDHCPv6 client and server. 270 In this approach, the configuration of stateless IPv4 addresses and 271 source ports (if required) is carried out using DHCPv6 as described 272 in section 1.3 above. Dynamic IPv4 addressing, and/or any additional 273 IPv4 configuration, is provided using DHCPv4 messages carried 274 (without IPv4/UDPv4 headers) within a new OPTION_BOOTP_MSG DHCPv6 275 option. 277 OPTION_BOOTP_MSG enables the client and server to send BOOTP/DHCPv4 278 messages verbatim across the IPv6 network. When a DHCPv4oDHCPv6 279 server receives a DHCPv6 request containing OPTION_BOOT_MSG within a 280 BOOTREQUESTV6 message, it passes it to the DHCPv4 server engine. 281 Likewise, the DHCPv4 server place its DHCPv4 response in the payload 282 of OPTION_BOOTP_MSG and puts this into a BOOTPRPLYV6 message. 284 As the DHCPv4 messages are carried within DHCPv6 multicast messages, 285 using the All_DHCP_Relay_Agents_and_Servers, they can be relayed in 286 exactly the same way as any other DHCPv6 multicasted message. 288 Optionally, DHCPv6 relays could be updated so that they forward the 289 BOOTREQUESTV6 message to a different destination address, allowing 290 for the separation of DHCPv4 and DHCPv6 provisioning infrastructure. 292 The protocol stack used for obtaining dynamic v4 addressing or 293 additional IPv4 configuraion is as follows: 295 DHCPv4/DHCPv6/UDPv6/IPv6 297 2. Requirements for the Solution Evaluation 299 The following requirements have been defined for the evalution of the 300 different approaches: 302 1. Minimize the amount of work necessary to implement the solution 303 through re-use of existing standards and implementations as much 304 as possible. 306 2. Provide a method of supporting all existing DHCPv4 options so 307 that they can be utilised without the need for further 308 standardation. 310 3. Allow for the dynamic leasing of IPv4 addresses to clients. This 311 allows for more efficient use of limited IPv4 resources. 313 4. Enable the separation of IPv4 and IPv6 host configuration 314 infrastructure, i.e. independent DHCPv4 and DHCPv6 servers. 316 5. Avoid leaving legacy IPv4 options in DHCPv6. 318 6. Provide a flexible architecture to give operators the option of 319 only deploying the functional elements necessary for their 320 specific requirements. 322 3. Comparison of the Four Approaches 324 The table below shows a comparison of how the different approaches 325 meet the solution requirements described above. 327 +----------+----------+--------+-----------+---------------+ 328 | Req. No. | DHCPv4o6 | DHCPv6 | DHCPv4oSW | DHCPv4oDHCPv6 | 329 +----------+----------+--------+-----------+---------------+ 330 | 1 | No | Yes | No | Yes | 331 | 2 | Yes | No | Yes | Yes | 332 | 3 | Yes | No | No | Yes | 333 | 4 | Yes | No | Yes | Yes | 334 | 5 | Yes | No | Yes | Yes | 335 | 6 | No | No | Yes | Yes | 336 +----------+----------+--------+-----------+---------------+ 338 Table 1: Approach Comparison 340 The following sections of the document provide more details of the 341 pros and cons relevant to each of the approaches. 343 3.1. DHCPv6 Based Provisioning 345 3.1.1. Pros 347 1. Simpler, in that no additional functional elements are required 348 except the DHCPv6 client and server. 350 2. A single protocol is used to deliver configuration information 351 for IPv4 and IPv6. 353 3. A single provisioning point for all configuration parameters. 355 4. Implementations already exist, proving that the approach works. 357 3.1.2. Cons 359 1. Any required DHCPv4 options must be ported to DHCPv6, which will 360 require re-development work for each option. All functional 361 elements in the DHCPv6 implementation (clients, servers, relays) 362 would need to be updated for each change. 364 2. Means that DHCPv4 'legacy' options, which will be of decreasing 365 relevance in the future will remain in DHCPv6 for the lifetime of 366 the protocol. 368 3. Each time that a DHCPv4 option is ported to DHCPv6, all clients 369 and servers would need to be updated to implement the new option. 371 4. Does not provide an architecture for keeping IPv4 and IPv6 372 domains separated. 374 5. Does not provide a mechanism for dynamic IPv4 address leasing. A 375 DHCPv4 lease lifetime mechanism would need to be added to DHCPv6 376 for this. 378 3.2. DHCPv4o6 Based Provisioning 380 3.2.1. Pros 382 1. Once implemented, all existing DHCPv4 options will be available 383 with no further ongoing development work necessary. 385 2. IPv4 and IPv6 based provisioning can be separated from each other 386 if required, allowing flexibility in network design. 388 3. Easy to implement through minor adaptation of existing DHCPv4 389 client/server code. 391 4. Simple, in that no additional functional elements are necessary 392 except the DHCPv4o6 client and server. The Transport Relay Agent 393 is completely optional. 395 5. Suitable for the provisioning of dynamic IPv4 configuration as 396 the existing DHCPv4 leasing mechanism can be used. 398 6. Implementations already exist, proving that the approach works. 400 3.2.2. Cons 402 1. More complex, in that there are more new functional elements 403 (CRA, DHCPv4o6 server and optionally TRA) within the architecture 404 than are necessary in DHCPv6 based provisioning. 406 2. A new DHCPv6 option is necessary in order to provision the IPv6 407 address of the DHCPv4 server to the end device. 409 3. For a Host CRA (HCRA), DHCPv4 client host needs to be updated to 410 implement the IPv6 encapsulation and decapsulation function. 411 Otherwise a physically separate On-Link CRA (LCRA) functional 412 element must be deployed. 414 4. A DHCPv4 server must be deployed and maintained. 416 5. The DHCPv4 server needs to be updated to implement new DHCPv4o6 417 functionality. 419 3.3. DHCPv4oSW Based Provisioning 421 3.3.1. Pros 423 1. Once implemented, all existing DHCPv4 options will be be 424 available with no further ongoing development work necessary. 426 2. Uses the existing DHCPv4 and DHCPv6 architectures in order to 427 provide IPv4 configuration in an IPv6 only environment. 429 3. DHCPv4 and DHCPv6 based provisioning can be separated from each 430 other if required, allowing flexibility in network design. 432 3.3.2. Cons 434 1. More complex, in that there are more new functional elements 435 within the architecture than are necessary in DHCPv6 based 436 provisioning. 438 2. IPv4 over IPv6 softwire approaches which distribute NAT to the 439 CPE and allow for IP address sharing (MAP-E & LW4o6) forbid the 440 use of reserved TCP/UDP ports (e.g. 0-1024). Every DHCPv4 441 client sharing the same address needs to have a UDP listener 442 running on UDP port 68. To resolve this would require 443 significant rework to either the softwire mechanisms and/or the 444 DHCPv4 client implementation. 446 3. From the current specification, DHCPINFORM is not suitable for 447 use over a softwire. Additional work, such as the development of 448 'shims' would be necessary 450 4. The current DHCPINFORM specification has a number of unclear 451 points, such as those described in 452 [I-D.ietf-dhc-dhcpinform-clarify]. Substantial work would be 453 required to resolve this. 455 5. Links the deployment of IPv4 configuration over IPv6 to a 456 softwire implementation (e.g. requiring a softwire concentrator 457 to act as a DHCPv4 relay). Whilst softwires are the only 458 application for this functionality at the moment, this may not 459 always be the case. 461 6. A new mechanism must be defined in order to provide the DHCPv4 462 client with the IPv4 address of the DHCPv4 server so that unicast 463 DHCPINFORM messages can be sent. 465 7. As only DHCPINFORM/DHCPACK DHCPv4 message types are supported, 466 dynamic IPv4 address leasing (using DHCPDISCOVER messages) can 467 not be used. 469 8. The approach is unproven as no existing implementations exist. 471 3.4. DHCPv4oDHCPv6 Based Provisioning 473 3.4.1. Pros 475 1. Once implemented, all existing DHCPv4 options will be be 476 available with no further ongoing development work necessary. 478 2. Uses the existing DHCPv4 and DHCPv6 architectures in order to 479 provide IPv4 configuration in an IPv6 only environment. 481 3. DHCPv4 and DHCPv6 based provisioning can be separated from each 482 other if required, allowing flexibility in network design. 484 4. Suitable for the provisioning of dynamic IPv4 configuration as 485 the existing DHCPv4 leasing mechanism can be used. 487 3.4.2. Cons 489 1. More complex, in that there are more new functional elements 490 within the architecture than are necessary in DHCPv6 based 491 provisioning. 493 2. DHCPv6 clients needs to be updated to implement the new DHCPv6 494 message types (BOOTPREQUESTv6 and BOOTPREPLYv6). 496 3. The DHCPv6 server needs to be updated to implement new 497 DHCPv4oDHCPv6 message types and functionality. 499 4. If separation of DHCPv4 and DHCPv6 provisioning infrastructure is 500 required, DHCPv6 relay agents need to be updated to implement 501 dedicated forwarding destinations based on message type. 503 5. The approach is currently unproven as no existing implementations 504 exist. 506 4. Conclusion 507 Whilst all of the approaches described here will require some 508 development work in order to realize, it is clear from the above 509 analysis that the most sustainable approach capitalizes on existing 510 DHCPv4 implementations and include them as new DHCPv6 message types. 511 The main rationale for this is that it enables all of DHCPv4's 512 existing options to be migrated for use over IPv6 in a single step. 514 Porting of all necessary DHCPv4 options to DHCPv6 would require 515 ongoing development work, re-implementing existing DHCPv4 516 functionality in DHCPv6. This will result in having legacy DHCPv4 517 options in DHCPv6, which will no longer be useful once IPv4 is 518 completely abandoned. 520 Therefore, the DHCPv6 approach is not suitable for delivering IPv4 521 configuration parameters in an efficient, ongoing manner. 523 The dynamic leasing of IPv4 addresses is fundamental to the efficient 524 use of remaining IPv4 resources. This will become increasingly 525 important in the future, so a mechanism which supports this is 526 necessary. DHCPv4oSW does not provide this function and so is not 527 recommended. 529 The DHCPv4o6 approach requires a DHCPv4 server (with DHCPv4o6 530 functionality) for all deployment scenarios, even when DHCPv4 531 specific functionality is not required by the operator. 533 Therefore, this memo recommends DHCPv4oDHCPv6 534 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] as the best underlying approach for 535 provisioning IPv4 parameters over an IPv6 only network. 537 5. IANA Considerations 539 This document makes no request of IANA. 541 Note to RFC Editor: this section may be removed on publication as an 542 RFC. 544 6. Security Considerations 546 7. Acknowledgements 548 Thanks to Ted Lemon and Tomek Mrugalski for their input and reviews. 550 8. References 552 8.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 8.2. Informative References 559 [I-D.ietf-dhc-dhcpinform-clarify] 560 Hankins, D., "Dynamic Host Configuration Protocol 561 DHCPINFORM Message Clarifications", draft-ietf-dhc- 562 dhcpinform-clarify-06 (work in progress), October 2011. 564 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 565 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 566 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 567 dhcpv4-over-dhcpv6-00 (work in progress), April 2013. 569 [I-D.ietf-dhc-dhcpv4-over-ipv6] 570 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 571 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in 572 progress), March 2013. 574 [I-D.ietf-softwire-lw4over6] 575 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 576 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 577 Architecture", draft-ietf-softwire-lw4over6-00 (work in 578 progress), April 2013. 580 [I-D.ietf-softwire-map-dhcp] 581 Mrugalski, T., Troan, O., Dec, W., Bao, C., 582 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 583 for Mapping of Address and Port", draft-ietf-softwire-map- 584 dhcp-03 (work in progress), February 2013. 586 [I-D.ietf-softwire-map] 587 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 588 Murakami, T., and T. Taylor, "Mapping of Address and Port 589 with Encapsulation (MAP)", draft-ietf-softwire-map-06 590 (work in progress), May 2013. 592 [I-D.ietf-softwire-unified-cpe] 593 Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 594 Softwire CPE", draft-ietf-softwire-unified-cpe-00 (work in 595 progress), March 2013. 597 [I-D.mrugalski-softwire-dhcpv4-over-v6-option] 598 Mrugalski, T. and P. Wu, "Dynamic Host Configuration 599 Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6 600 Endpoint", draft-mrugalski-softwire- 601 dhcpv4-over-v6-option-01 (work in progress), September 602 2012. 604 Authors' Addresses 606 Branimir Rajtar 607 Hrvatski Telekom 608 Zagreb 609 Croatia 611 Email: branimir.rajtar@t.ht.hr 613 Ian Farrer 614 Deutsche Telekom AG 615 Bonn 616 Germany 618 Email: ian.farrer@telekom.de