idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-ipv6-09.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 (April 24, 2014) is 3655 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-07 == Outdated reference: A later version (-06) exists of draft-ietf-dhc-v4configuration-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft P. Wu 4 Intended status: Informational J. Wu 5 Expires: October 26, 2014 Tsinghua University 6 T. Lemon 7 Nominum, Inc. 8 Q. Sun 9 Tsinghua University 10 April 24, 2014 12 DHCPv4 over IPv6 Transport 13 draft-ietf-dhc-dhcpv4-over-ipv6-09 15 Abstract 17 In IPv6 networks, there remains a need to provide IPv4 service for 18 some residual devices. This document describes a mechanism for 19 allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 20 transport. It is done by putting a special relay agent function 21 (Client Relay Agent) on the client side, as well as extending the 22 behavior of the server; in the case where DHCP server only supports 23 IPv4 transport, a relay agent is extended to support IPv6 transport 24 (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, 25 with a new Relay Agent Information sub-option added to carry the IPv6 26 address of the Client Relay Agent. DHCPv4 over IPv6 has been 27 developed in the IETF, and some implementations and deployments have 28 been carried out. But this mechanism is not recommended for future 29 implementation or deployment. 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 October 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . 5 69 5. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6 70 6. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . 7 71 7. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 72 8. Security Consideration . . . . . . . . . . . . . . . . . . . 8 73 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 9 74 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 11.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Appendix A. Motivation for selecting this particular solution . 10 79 A.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 10 80 A.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11 81 A.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 11 82 Appendix B. Discussion on One Host Retrieving Multiple Addresses 83 through One CRA . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 DHCPv4 over IPv6 mechanism has been developed in the IETF. There 89 have been implementations from ISC, Juniper, Huawei, Tsinghua 90 University, etc. It is in active deployments in some networks, 91 including in the China Next Generation Internet (CNGI) and China 92 Education and Research Network 2 (CERNET2), Deutsche Telekom, and so 93 on. Documenting this mechanism is for the benefit of vendors and 94 operators of the existing implementations and deployments. According 95 to [I-D.ietf-dhc-v4configuration], future usage should reference 96 [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. 98 DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot 99 operate on an IPv6 network. However, as dual-stack networks become a 100 reality, the need arises to allocate IPv4 addresses in an IPv6 101 environment. To meet this demand, this document extends the DHCPv4 102 protocol to allow the use of an IPv6 network for transport. 104 A typical scenario that probably requires this feature is IPv4-over- 105 IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- 106 IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts 107 or end networks) across an IPv6 network. If the IPv4 addresses of 108 the end users are provisioned by the concentrator side, then the 109 provisioning process should be able to cross the IPv6 network. One 110 such tunnel mechanism is demonstrated in 111 [I-D.ietf-softwire-public-4over6]. 113 2. Terminology 115 This document makes use of the following terms: 117 o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. 119 o Client Relay Agent (CRA): a special DHCPv4 Relay Agent which 120 relays between DHCPv4 client and DHCPv4 server using an IPv6 121 network. A CRA either sits on the same, IPv6-accessible host with 122 the DHCPv4 client, or sits on the same link with the host running 123 DHCPv4 client. 125 o Host Client Relay Agent (HCRA): a CRA which sits on the same, 126 IPv6-accessible host with the DHCPv4 client. 128 o On-Link Client Relay Agent (LCRA): a CRA which sits on the same 129 link with the host that runs DHCPv4 client. 131 o IPv6-Transport Server (TSV): a DHCPv4 Server that supports IPv6 132 transport. The TSV listens on IPv6 for incoming DHCPv4 messages, 133 and sends DHCPv4 messages in IPv6 packets. 135 o IPv6-Transport Relay Agent (TRA): a DHCPv4 Relay Agent that 136 supports IPv6 transport. The TRA sits on a machine which has both 137 IPv6 and IPv4 connectivity, and relays DHCP messages between a CRA 138 and a regular DHCPv4 server. Unlike the CRA, the TRA sits on the 139 remote end of the IPv6 network, and communicates with the DHCPv4 140 server through IPv4. 142 o Client Relay Agent IPv6 Address sub-option (CRA6ADDR sub-option): 143 a new sub-option of the DHCP Relay Agent Information Option 144 [RFC3046], defined in this document, which is used to carry the 145 IPv6 address of the CRA. 147 3. Protocol Summary 149 The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. 150 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 151 network in the middle. DHCP messages between a client and the server 152 /relay cannot naturally be forwarded to each other because they are 153 IPv4 UDP packets, either unicast or broadcast. To bridge this gap, 154 both the client side and the server/relay side can enable DHCPv4 over 155 IPv6 transport. More precisely, it is necessary for them to support 156 delivering and receiving DHCP messages in IPv6 UDP packets and 157 thereby traverse the IPv6 network. 159 On the client side, a special relay agent called Client Relay Agent 160 is placed on the same host with the client, or on the link of the 161 host. The CRA is used to relay DHCP messages from the client to the 162 server, and from the server to the client. It sends DHCPv4 messages 163 to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP 164 packets with the DHCPv4 messages from the server. By using CRA, no 165 extension is required on the DHCP client. 167 +-------------------------+ 168 +------+ | 169 |DHCPv4| | 170 |Client| +-------+ 171 +------+ |DHCPv4 | 172 | IPv6 Network |Server/| 173 +------+ |Relay | 174 |DHCPv4| +-------+ 175 |Client| | 176 +------+ | 177 +-------------------------+ 179 Figure 1 Scenario of DHCPv4 over IPv6 Transport 181 The IPv6-Transport DHCPv4 server is able to receive DHCP messages 182 delivered in IPv6 UDP from the CRA, and send out DHCP messages to the 183 CRA using IPv6 UDP (figure 2(a)). The TSV sends DHCP messages to the 184 IPv6 address from which it receives relevant DHCP messages earlier. 186 When CRAs communicate with an IPv6-Transport Relay Agent rather than 187 with a server directly, the situation becomes a little more 188 complicated. Besides the IPv6 communication with a CRA, a TRA also 189 communicates with a regular DHCPv4 server through IPv4. Therefore, 190 when the TRA relays DHCP messages between a CRA and the DHCPv4 191 server, it receives a DHCP message from the CRA in IPv6 and sends it 192 to the server in IPv4, as well as receives a DHCP message from the 193 server in IPv4 and sends it to the CRA in IPv6. 195 The TRA sends the IPv6 address of the CRA to the DHCP server using 196 the Client Relay Agent IPv6 Address (CRA6ADDR) suboption, defined in 197 this document. The DHCP server returns this suboption to the TRA as 198 required in [RFC3046]. The TRA then uses the returned CRA6ADDR 199 suboption to determine the destination address to which to relay the 200 response. 202 +------+ +------+ 203 |client| IPv6 network |TSV | 204 |+HCRA |----------------| | 205 +------+ +------+ 207 +------+ +------+ +------+ 208 |client| |LCRA | IPv6 network |TSV | 209 | |--| |----------------| | 210 +------+ +------+ +------+ 211 (a)client--server case 213 +------+ +------+ +------+ 214 |client| IPv6 network |TRA | IPv4 network |server| 215 |+HCRA |----------------| |--------------| | 216 +------+ +------+ +------+ 218 +------+ +------+ +------+ +------+ 219 |client| |LCRA | IPv6 network |TRA | IPv4 network |server| 220 | |--| |----------------| |--------------| | 221 +------+ +------+ +------+ +------+ 223 (b)client--relay--server case 225 Figure 2 Protocol Summary 227 4. Client Relay Agent IPv6 Address Sub-option 229 The CRA6ADDR suboption is a suboption of the Relay Agent Information 230 Option [RFC3046]. It encodes the IPv6 address of the machine from 231 which a DHCPv4-in-IPv6 CRA-to-TRA message was received. It is used 232 by the TRA to relay DHCPv4 replies back to the proper CRA. The TRA 233 uses the IPv6 address encoded in this suboption as the destination 234 IPv6 address when relaying a DHCPv4 message from the DHCP server to 235 the CRA. 237 The CRA6ADDR sub-option has a fixed length of 18 octets. The SubOpt 238 code is tbd by IANA, the length field is 16, and the following 16 239 octets contain the CRA IPv6 address. 241 SubOpt Len Agent Remote ID 242 +------+------+------+------+------+- -+------+ 243 | tbd | 16 | a1 | a2 | a3 | ... | a16 | 244 +------+------+------+------+------+- -+------+ 246 Figure 3 Client Relay Agent IPv6 Address Sub-option format 248 5. Client Relay Agent Behavior 250 A Client Relay Agent sits on the same host with the DHCPv4 client 251 (HCRA), or on the same link as the host (LCRA). A CRA listens for 252 DHCP packets on IPv4 on port 67, and also listens for DHCP packets on 253 IPv6 on port 67. 255 A CRA is configured with one or more IPv6 addresses of TSV/TRA as the 256 destination(s). The CRA is also configured with a global IPv6 257 address before the DHCPv4 client starts, so that it can forward 258 DHCPv4 messages over IPv6. 260 When the CRA receives any DHCP message on IPv4 with BOOTP op field 261 set to 1, it forwards the message over UDP on IPv6 using a standard 262 DHCP message format, with source port 67 and destination port 67. 263 The CRA forwards the message to each TSV or TRA address with which it 264 is configured. 266 When the CRA receives any message on IPv6 with BOOTP op field set to 267 2, the CRA checks to see if the message contains option 82. If it 268 does, the CRA silently discards the message. Otherwise, it relays 269 the message to the DHCP client using IPv4. 271 When the CRA receives any message on IPv6 with BOOTP op field set to 272 4, it decapsulates the message as specified in DHCPv4 Relay Agent 273 Encapsulation [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. If the CRA 274 does not support encapsulation, it silently discards the message. 276 The LCRA or HCRA does not use the Relay Agent Information Option 277 [RFC3046]. If either type of CRA needs to send relay agent options, 278 it uses relay agent encapsulation as defined in 279 [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. 281 An HCRA only serves the client inside the same host, while the LCRA 282 serves any client on the link. When the IPv6 address of TSV/TRA is 283 provisioned to the host running the DHCP client, it uses HCRA; else 284 the client depends on LCRA. A HCRA serves only one link; the 285 multiple-link case is handled by multiple HCRA instances. A LCRA 286 does not necessarily need an IPv4 address, though it may be 287 configured with one. 289 In the HCRA case, the DHCPv6 client (or other IPv6 configuration 290 processes), DHCPv4 client and CRA run on the same physical interface. 291 In some cases, the host running the DHCPv4 client and CRA defers the 292 operation of the DHCPv4 client until an IPv6 address of the interface 293 has been acquired, as well as the TSV/TRA address information. If 294 this is not done, the DHCPv4 client may send several messages that 295 the CRA cannot relay, and this could result in long delays before the 296 DHCPv4 client actually gets an IPv4 address. 298 6. IPv6-Transport Server Behavior 300 To support IPv6 transport, the behavior of DHCPv4 server is extended. 301 The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4 302 messages, and send DHCPv4 messages through IPv6. 304 A TSV listens for DHCP messages on IPv6 UDP port 67 and IPv4 UDP port 305 67. When it receives a DHCP message on IPv6, it retains the IPv6 306 source address of that message until it has sent a response. The TSV 307 sends the response to this IPv6 address, with destination port 67. 309 The TSV is bound to send a server identifier option [RFC2132] 310 containing an IPv4 address which will be reachable from the client 311 once the residual IPv4 service is set up. This follows the server id 312 option requirement in [RFC2131]. 314 The rest of TSV DHCP process is the same with a normal DHCPv4 server. 315 A TSV also listens on IPv4 UDP port 67 like a normal DHCPv4 server, 316 and process IPv4 DHCPv4 messages normally. This requirement exists 317 because when a DHCPv4 client renews, it sends its renewal messages 318 directly to the server, rather than broadcasting them. 320 Because a CRA may use relay agent encapsulation 321 [I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV ought to support 322 it. A TSV that does not support it will not interoperate with a CRA 323 that sends relay agent options. 325 7. IPv6-Transport Relay Agent Behavior 327 An IPv6-Transport Relay Agent sits between an IPv6 network and an 328 IPv4 network, and relays DHCPv4 messages between CRAs and an 329 IPv4-only DHCPv4 server. The communication between CRAs and the TRA 330 uses IPv6, while the communication between the TRA and the server 331 uses IPv4. A TRA listens on IPv6 UDP port 67 for DHCP messages with 332 BOOTP op field set to 1 or 3, as well as IPv4 UDP port 67 for DHCP 333 messages with BOOTP op field set to 2 or 4. 335 When relaying a DHCP message from CRA to server, the TRA adds a 336 CRA6ADDR suboption. The TRA sets the contents of this suboption to 337 the IPv6 source address of the message. The TRA also stores one of 338 its own IPv4 addresses in the giaddr field of the DHCP message. The 339 TRA may include a Link Selection sub-option [RFC3527] to indicate to 340 the DHCP server which link to use when choosing an IP address. If 341 the received message is a RELAYFORWARD message, the TRA encapsulates 342 the message in a new RELAYFORWARD message and stores the CRA6ADDR in 343 the new relay segment. If it is some other message, the TRA appends 344 a Relay Agent Information Option as described in [RFC3046], but may 345 encapsulate it in the same way as RELAYFORWARD message instead, which 346 depends on the implementation. 348 When receiving a DHCP message from the DHCP server, if the message 349 contains no CRA6ADDR suboption, the TRA discards the message. 350 Otherwise, it processes it as required by [RFC3046] and 351 [I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the 352 IPv6 address recorded in the CRA6ADDR sub-option, with source port 67 353 and destination port 67. 355 8. Security Consideration 357 This mechanism may rise a new form of DHCP protocol attack. A 358 malicious attacker in IPv6 can interference with the DHCPv4 process 359 by injecting fake DHCPv4-in-IPv6 messages which will be handled by 360 TSV or TRA. However, the damage is the same with the known DHCPv4 361 attack happened in IPv4. The only difference is the attacker and the 362 victim could locate in different address families. 364 Another impact is DHCP filtering. There are firewalls today capable 365 of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 366 packets). The DHCP messages with the new, DHCPv4-in-IPv6 style may 367 bypass these firewalls. Nevertheless it is not difficult for them to 368 make some slight modification and adapt to the new DHCPv4 message 369 pattern. 371 9. IANA Consideration 373 IANA is requested to assign one new sub-option code from the registry 374 of DHCP Agent Sub-Option Codes maintained in http://www.iana.org/ 375 assignments/bootp-dhcp-parameters. This sub-option code will be 376 assigned to the Client Relay Agent IPv6 Address Sub-option. 378 10. Contributors 380 The following gentlemen also contributed to the effort: 382 Francis Dupont 384 Internet Systems Consortium, Inc. 386 Email: fdupont@isc.org 388 Tomasz Mrugalski 390 Internet Systems Consortium, Inc. 392 Email: tomasz.mrugalski@gmail.com 394 Dmitry Anipko 396 Microsoft Corporation 398 Email: danipko@microsoft.com 400 11. References 402 11.1. Normative References 404 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] 405 Lemon, T., Deng, H., and L. Huang, "Relay Agent 406 Encapsulation for DHCPv4", draft-ietf-dhc-dhcpv4-relay- 407 encapsulation-01 (work in progress), July 2011. 409 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 410 2131, March 1997. 412 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 413 Extensions", RFC 2132, March 1997. 415 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 416 3046, January 2001. 418 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 419 "Link Selection sub-option for the Relay Agent Information 420 Option for DHCPv4", RFC 3527, April 2003. 422 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 423 Identifiers for Dynamic Host Configuration Protocol 424 Version Four (DHCPv4)", RFC 4361, February 2006. 426 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 427 Problem Statement", RFC 4925, July 2007. 429 [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client 430 Identifier Option in DHCP Server Replies", RFC 6842, 431 January 2013. 433 11.2. Informative References 435 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 436 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 437 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 438 dhcpv4-over-dhcpv6-07 (work in progress), April 2014. 440 [I-D.ietf-dhc-v4configuration] 441 Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration 442 Over IPv6 Only Networks", draft-ietf-dhc- 443 v4configuration-05 (work in progress), February 2014. 445 [I-D.ietf-softwire-public-4over6] 446 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 447 IPv4 over IPv6 Access Network", draft-ietf-softwire- 448 public-4over6-10 (work in progress), July 2013. 450 Appendix A. Motivation for selecting this particular solution 452 We considered three possible solutions to the problem of configuring 453 IPv4 addresses on an IPv6 network. 455 A.1. Configuring IPv4 with DHCPv6 457 Use DHCPv6 instead of DHCPv4, to provision IPv4-related connectivity. 458 In DHCPv6, the provisioned IPv4 address can be embedded into IPv6 459 address, or carried within a new option. Along with that, dedicated 460 options are needed to convey IPv4-related information, such as the 461 IPv4 address of DNS server, NTP server, etc. Therefore it will put a 462 certain amount of IPv6-unrelated information into DHCPv6 protocol. 464 This solution was rejected for two reasons. First, the DHCPv6 465 protocol does not currently provide a mechanism for recording 466 bindings between IPv4 addresses and DHCPv6 clients. Extending DHCPv6 467 to provide this functionality would be a substantial change to the 468 existing protocol. 470 Second, a deliberate choice was made when the DHCPv6 protocol was 471 defined to avoid simply copying existing functionality from DHCPv4. 472 While it is possible, using DHCPv6, to deliver IPv4 addresses as 473 IPv6-encoded IPv4 addresses, it might be necessary to add additional 474 DHCPv6 options simply to support IPv4. These options would then 475 remain in the protocol, long after the need for IPv4 has gone. 477 By comparison, any extensions to DHCPv4 will naturally be forgotten 478 when DHCPv4 is no longer needed. This means that whatever extensions 479 we make to DHCPv4 to solve the problem, we can stop maintaining as 480 soon as IPv4 is no longer needed. 482 A.2. Tunnel DHCPv4 over IPv6 484 Use DHCPv4 for configuration, and tunnel DHCPv4-in-IPv4 messages over 485 IPv6. Unlike the previous approach where DHCPv6 is used for both 486 IPv4 and IPv6 connectivity, this approach preserves the separation 487 between IPv4 and IPv6 connectivity information. It maintains the 488 IPv4 service without major modifications to IPv6-related provisioning 489 resources, and sustains DHCPv4 to be the IPv4-related information 490 carrier. 492 This approach was not chosen because it adds a requirement for DHCPv4 493 to operate over an IPv4-in-IPv6 tunnel. DHCPv4 clients generally 494 operate on broadcast networks, not on tunnels. To make DHCPv4 495 operate over a tunnel would require substantial changes to the DHCPv4 496 client, as well as maintaining a tunnel over which to deliver DHCPv4 497 traffic. 499 This also creates a chicken-and-egg problem: how do we set up an IPv4 500 tunnel when we do not know our IPv4 address? Solutions to these 501 problems were proposed, but they require significant changes to the 502 DHCP client and significant additional work to make a tunnel that 503 could carry the DHCP packets. 505 A.3. DHCPv4 relayed over IPv6 507 Use DHCPv4 for configuration, and extend it to use an IPv6 transport 508 for relayed messages. Essentially this involves a single change to 509 the protocol, to allow DHCPv4 servers or relay agents to send and 510 receive packets using an IPv6 transport. No changes are required on 511 the client. 513 The working group chose this third solution because, of the three, it 514 required the fewest changes to the DHCP protocol, so that it was 515 easiest to specify and easiest to implement. 517 Appendix B. Discussion on One Host Retrieving Multiple Addresses 518 through One CRA 520 This document is written with the intention of supporting a use case 521 where a single DHCP client is configuring a single tunnel endpoint 522 per physical link. The technique described in this document could be 523 used by a host needing to configure more than one tunnel endpoint on 524 the same physical link, i.e., to retrieve multiple addresses through 525 the same CRA. 527 DHCP server implementing this specification implements Client 528 Identifier Option in DHCP server replies [RFC6842]. 530 In general this specification is intended not to require modification 531 of DHCP clients. However, DHCP clients being used to configure 532 multiple tunnel endpoints have to be modified; otherwise there is no 533 way for such DHCP clients to differentiate between DHCP responses. 534 Therefore, in such case, the DHCP client using this specification 535 uses a different client identifier for each tunnel endpoint being 536 configured. Such DHCP clients examine the response from the DHCP 537 server and use the client identifier to differentiate between the 538 DHCP client state machines for each tunnel endpoint. 540 In order to satisfy the requirement that client identifiers be 541 unique, DHCP clients configuring multiple tunnel endpoints implement 542 Node-specific Client Identifiers for DHCPv4 [RFC4361]. Such clients 543 use a different IAID for each tunnel endpoint. 545 It is assumed here that every client state machine on a multiple- 546 tunnel-endpoint link can hear all the DHCP messages (and subsequently 547 accept the messages intended for it). How this is accomplished is 548 left to the implementor. However, implementations must follow this 549 requirement; otherwise, it will be impossible for multiple tunnel 550 endpoints to be successfully configured. The easiest way to 551 accomplish this is to have a single DHCP client process with multiple 552 DHCP state machines, and to dispatch each DHCP message to the correct 553 DHCP client state machine using the client identifier. However, this 554 is not required; any mechanism that results in client state machines 555 receiving the messages that are intended for them will suffice. 557 Authors' Addresses 559 Yong Cui 560 Tsinghua University 561 Department of Computer Science, Tsinghua University 562 Beijing 100084 563 P.R.China 565 Phone: +86-10-6260-3059 566 Email: yong@csnet1.cs.tsinghua.edu.cn 568 Peng Wu 569 Tsinghua University 570 Department of Computer Science, Tsinghua University 571 Beijing 100084 572 P.R.China 574 Phone: +86-10-6278-5822 575 Email: pengwu.thu@gmail.com 577 Jianping Wu 578 Tsinghua University 579 Department of Computer Science, Tsinghua University 580 Beijing 100084 581 P.R.China 583 Phone: +86-10-6278-5983 584 Email: jianping@cernet.edu.cn 586 Ted Lemon 587 Nominum, Inc. 588 2000 Seaport Blvd 589 Redwood City, CA 94063 590 USA 592 Phone: +1-650-381-6000 593 Email: mellon@nominum.com 594 Qi Sun 595 Tsinghua University 596 Department of Computer Science, Tsinghua University 597 Beijing 100084 598 P.R.China 600 Phone: +86-10-6278-5822 601 Email: sunqi@csnet1.cs.tsinghua.edu.cn