idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-ipv6-08.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 (October 21, 2013) is 3811 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-02 == Outdated reference: A later version (-06) exists of draft-ietf-dhc-v4configuration-02 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: April 24, 2014 Tsinghua University 6 T. Lemon 7 Nominum, Inc. 8 Q. Sun 9 Tsinghua University 10 October 21, 2013 12 DHCPv4 over IPv6 Transport 13 draft-ietf-dhc-dhcpv4-over-ipv6-08 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 April 24, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 68 5. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6 69 6. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 70 7. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 71 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 72 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 73 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 11.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Appendix A. Motivation for selecting this particular solution . . 11 78 A.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 11 79 A.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11 80 A.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 12 81 Appendix B. Discussion on One Host Retrieving Multiple 82 Addresses through One CRA . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 DHCPv4 over IPv6 mechanism has been developed in the IETF. There 88 have been implementations from ISC, Juniper, Huawei, Tsinghua 89 University, etc. It is in active deployments in some networks, 90 including in the China Next Generation Internet (CNGI) and China 91 Education and Research Network 2 (CERNET2), Deutsche Telekom, and so 92 on. Documenting this mechanism is for the benefit of vendors and 93 operators of the existing implementations and deployments. According 94 to [I-D.ietf-dhc-v4configuration], future usage should reference 95 [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. 97 DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot 98 operate on an IPv6 network. However, as dual-stack networks become a 99 reality, the need arises to allocate IPv4 addresses in an IPv6 100 environment. To meet this demand, this document extends the DHCPv4 101 protocol to allow the use of an IPv6 network for transport. 103 A typical scenario that probably requires this feature is IPv4-over- 104 IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- 105 IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts 106 or end networks) across an IPv6 network. If the IPv4 addresses of 107 the end users are provisioned by the concentrator side, then the 108 provisioning process should be able to cross the IPv6 network. One 109 such tunnel mechanism is demonstrated in 110 [I-D.ietf-softwire-public-4over6]. 112 2. Terminology 114 This document makes use of the following terms: 116 o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. 118 o Client Relay Agent (CRA): a special DHCPv4 Relay Agent which 119 relays between DHCPv4 client and DHCPv4 server using an IPv6 120 network. A CRA either sits on the same, IPv6-accessible host with 121 the DHCPv4 client, or sits on the same link with the host running 122 DHCPv4 client. 124 o Host Client Relay Agent (HCRA): a CRA which sits on the same, 125 IPv6-accessible host with the DHCPv4 client. 127 o On-Link Client Relay Agent (LCRA): a CRA which sits on the same 128 link with the host that runs DHCPv4 client. 130 o IPv6-Transport Server (TSV): a DHCPv4 Server that supports IPv6 131 transport. The TSV listens on IPv6 for incoming DHCPv4 messages, 132 and sends DHCPv4 messages in IPv6 packets. 134 o IPv6-Transport Relay Agent (TRA): a DHCPv4 Relay Agent that 135 supports IPv6 transport. The TRA sits on a machine which has both 136 IPv6 and IPv4 connectivity, and relays DHCP messages between a CRA 137 and a regular DHCPv4 server. Unlike the CRA, the TRA sits on the 138 remote end of IPv6 network, and communicates with DHCPv4 server 139 through IPv4. 141 o Client Relay Agent IPv6 Address Sub-option (CRA6ADDR sub-option): 142 a new sub-option of the DHCP Relay Agent Information Option 143 [RFC3046], defined in this document, which is used to carry the 144 IPv6 address of the CRA. 146 3. Protocol Summary 148 The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. 149 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 150 network in the middle. DHCP messages between a client and the 151 server/relay cannot naturally be forwarded to each other because they 152 are IPv4 UDP packets, either unicast or broadcast. To bridge this 153 gap, both the client side and the server/relay side can enable DHCPv4 154 over IPv6 transport. More precisely, it is necessary for them to 155 support delivering and receiving DHCP messages in IPv6 UDP packets 156 and thereby traverse the IPv6 network. 158 On the client side, a special relay agent called Client Relay Agent 159 is placed on the same host with the client, or on the link of the 160 host. CRA is used to relay DHCP messages from the client to the 161 server, and from the server to the client. CRA sends DHCPv4 messages 162 to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP 163 packets with the DHCPv4 messages from the server. By using CRA, no 164 extension is required on the DHCP client. 166 +-------------------------+ 167 +------+ | 168 |DHCPv4| | 169 |Client| +-------+ 170 +------+ |DHCPv4 | 171 | IPv6 Network |Server/| 172 +------+ |Relay | 173 |DHCPv4| +-------+ 174 |Client| | 175 +------+ | 176 +-------------------------+ 178 Figure 1 Scenario of DHCPv4 over IPv6 Transport 180 The IPv6-Transport DHCPv4 server is able to receive DHCP messages 181 delivered in IPv6 UDP from the CRA, and send out DHCP messages to the 182 CRA using IPv6 UDP (figure 2(a)). The TSV sends DHCP messages to the 183 IPv6 address from which it receives relevant DHCP messages earlier. 185 When CRAs communicate with an IPv6-Transport Relay Agent rather than 186 with a server directly, the situation becomes a little more 187 complicated. Besides the IPv6 communication with a CRA, a TRA also 188 communicates with a regular DHCPv4 server through IPv4. Therefore, 189 when the TRA relays DHCP messages between a CRA and the DHCPv4 190 server, it receives DHCP message from the CRA in IPv6 and sends it to 191 the server in IPv4, as well as receives DHCP message from the server 192 in IPv4 and sends it to the CRA in IPv6. 194 The TRA sends the IPv6 address of the CRA to the DHCP server using 195 the Client Relay Agent IPv6 Address (CRA6ADDR) suboption, defined in 196 this document. The DHCP server returns this suboption to the TRA as 197 required in [RFC3046]. The TRA then uses the returned CRA6ADDR 198 suboption to determine the destination address to which to relay the 199 response. 201 +------+ +------+ 202 |client| IPv6 network |TSV | 203 |+HCRA |----------------| | 204 +------+ +------+ 206 +------+ +------+ +------+ 207 |client| |LCRA | IPv6 network |TSV | 208 | |--| |----------------| | 209 +------+ +------+ +------+ 210 (a)client--server case 212 +------+ +------+ +------+ 213 |client| IPv6 network |TRA | IPv4 network |server| 214 |+HCRA |----------------| |--------------| | 215 +------+ +------+ +------+ 217 +------+ +------+ +------+ +------+ 218 |client| |LCRA | IPv6 network |TRA | IPv4 network |server| 219 | |--| |----------------| |--------------| | 220 +------+ +------+ +------+ +------+ 222 (b)client--relay--server case 224 Figure 2 Protocol Summary 226 4. Client Relay Agent IPv6 Address Sub-option 228 The CRA6ADDR suboption is a suboption of the Relay Agent Information 229 Option [RFC3046]. It encodes the IPv6 address of the machine from 230 which a DHCPv4-in-IPv6 CRA-to-TRA message was received. It is used 231 by the TRA to relay DHCPv4 replies back to the proper CRA. The TRA 232 uses the IPv6 address encoded in this suboption as the destination 233 IPv6 address when relaying a DHCPv4 message from the DHCP server to 234 the CRA. 236 The CRA6ADDR sub-option has a fixed length of 18 octets. The SubOpt 237 code is tbd by IANA, the length field is 16, and the following 16 238 octets contain the CRA IPv6 address. 240 SubOpt Len Agent Remote ID 241 +------+------+------+------+------+- -+------+ 242 | tbd | 16 | a1 | a2 | a3 | ... | a16 | 243 +------+------+------+------+------+- -+------+ 245 Figure 3 Client Relay Agent IPv6 Address Sub-option format 247 5. Client Relay Agent Behavior 249 A Client Relay Agent sits on the same host with the DHCPv4 client 250 (HCRA), or on the same link as the host (LCRA). A CRA listens for 251 DHCP packets on IPv4 on port 67, and also listens for DHCP packets on 252 IPv6 on port 67. 254 A CRA is configured with one or more IPv6 addresses of TSV/TRA as the 255 destination(s). The CRA is also configured with a global IPv6 256 address before the DHCPv4 client starts, so that it can forward 257 DHCPv4 messages over IPv6. 259 When the CRA receives any DHCP message on IPv4 with BOOTP op field 260 set to 1, it forwards the message over UDP on IPv6 using a standard 261 DHCP message format, with source port 67 and destination port 67. 262 The CRA forwards the message to each TSV or TRA address with which it 263 is configured. 265 When the CRA receives any message on IPv6 with BOOTP op field set to 266 2, the CRA checks to see if the message contains option 82. If it 267 does, the CRA silently discards the message. Otherwise, it relays 268 the message to the DHCP client using IPv4. 270 When the CRA receives any message on IPv6 with BOOTP op field set to 271 4, it decapsulates the message as specified in DHCPv4 Relay Agent 272 Encapsulation [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. If the CRA 273 does not support encapsulation, it silently discards the message. 275 The LCRA or HCRA does not use the Relay Agent Information Option 276 [RFC3046]. If either type of CRA needs to send relay agent options, 277 it uses relay agent encapsulation as defined in 278 [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. 280 An HCRA only serves the client inside the same host, while the LCRA 281 serves any client on the link. When the IPv6 address of TSV/TRA is 282 provisioned to the host running the DHCP client, it uses HCRA; else 283 the client depends on LCRA. A HCRA serves only one link; the 284 multiple-link case is handled by multiple HCRA instances. A LCRA 285 does not necessarily need an IPv4 address, though it may be 286 configured with one. 288 In the HCRA case, the DHCPv6 client (or other IPv6 configuration 289 processes), DHCPv4 client and CRA run on the same physical interface. 290 In some cases, the host running the DHCPv4 client and CRA defers the 291 operation of the DHCPv4 client until an IPv6 address of the interface 292 has been acquired, as well as the TSV/TRA address information. If 293 this is not done, the DHCPv4 client may send several messages that 294 the CRA cannot relay, and this could result in long delays before the 295 DHCPv4 client actually gets an IPv4 address. 297 6. IPv6-Transport Server Behavior 299 To support IPv6 transport, the behavior of DHCPv4 server is extended. 300 The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4 301 messages, and send DHCPv4 messages through IPv6. 303 A TSV listens for DHCP messages on IPv6 UDP port 67 and IPv4 UDP port 304 67. When it receives a DHCP message on IPv6, it retains the IPv6 305 source address of that message until it has sent a response. When it 306 sends a response, it sends the response to this IPv6 address, with 307 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. 316 A TSV also listens on IPv4 UDP port 67 like a normal DHCPv4 server, 317 and process IPv4 DHCPv4 messages normally. This requirement exists 318 because when a DHCPv4 client renews, it sends its renewal messages 319 directly to the server, rather than broadcasting them. 321 Because a CRA may use relay agent encapsulation 322 [I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV ought to support 323 it. A TSV that does not support it will not interoperate with a CRA 324 that sends relay agent options. 326 7. IPv6-Transport Relay Agent Behavior 328 An IPv6-Transport Relay Agent sits between an IPv6 network and an 329 IPv4 network, and relays DHCPv4 messages between CRAs and an IPv4- 330 only DHCPv4 server. The communication between CRAs and the TRA uses 331 IPv6, while the communication between the TRA and the server uses 332 IPv4. A TRA listens on IPv6 UDP port 67 for DHCP messages with BOOTP 333 op field set to 1 or 3, as well as IPv4 UDP port 67 for DHCP messages 334 with BOOTP op field set to 2 or 4. 336 When relaying a DHCP message from CRA to server, the TRA adds a 337 CRA6ADDR suboption. The TRA sets the contents of this suboption to 338 the IPv6 source address of the message. The TRA also stores one its 339 own IPv4 addresses in the giaddr field of the DHCP message. The TRA 340 may include a Link Selection sub-option [RFC3527] to indicate to the 341 DHCP server which link to use when choosing an IP address. If the 342 received message is a RELAYFORWARD message, the TRA encapsulates the 343 message in a new RELAYFORWARD message and stores the CRA6ADDR in the 344 new relay segment. If it is some other message, the TRA appends a 345 Relay Agent Information Option as described in [RFC3046], but may 346 encapsulate it in the same way as RELAYFORWARD message instead, which 347 depends on the implementation. 349 When receiving a DHCP message from the DHCP server, if the message 350 contains no CRA6ADDR suboption, the TRA discards the message. 351 Otherwise, it processes it as required by [RFC3046] and 352 [I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the 353 IPv6 address recorded in the CRA6ADDR sub-option, with source port 67 354 and destination port 67. 356 8. Security Consideration 358 This mechanism may rise a new form of DHCP protocol attack. A 359 malicious attacker in IPv6 can interference with the DHCPv4 process 360 by injecting fake DHCPv4-in-IPv6 messages which will be handled by 361 TSV or TRA. However, the damage is the same with the known DHCPv4 362 attack happened in IPv4. The only difference is the attacker and the 363 victim could locate in different address families. 365 Another impact is DHCP filtering. There are firewalls today capable 366 of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 367 packets). The DHCP messages with the new, DHCPv4-in-IPv6 style may 368 bypass these firewalls. Nevertheless it is not difficult for them to 369 make some slight modification and adapt to the new DHCPv4 message 370 pattern. 372 9. IANA Consideration 374 IANA is requested to assign one new sub-option code from the registry 375 of DHCP Agent Sub-Option Codes maintained in 376 http://www.iana.org/assignments/bootp-dhcp-parameters. This sub- 377 option code will be assigned to the Client Relay Agent IPv6 Address 378 Sub-option. 380 10. Contributors 382 The following gentlemen also contributed to the effort: 384 Francis Dupont 385 Internet Systems Consortium, Inc. 387 Email: fdupont@isc.org 389 Tomasz Mrugalski 390 Internet Systems Consortium, Inc. 392 Email: tomasz.mrugalski@gmail.com 394 Dmitry Anipko 395 Microsoft Corporation 397 Email: danipko@microsoft.com 399 11. References 400 11.1. Normative References 402 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] 403 Lemon, T., Deng, H., and L. Huang, "Relay Agent 404 Encapsulation for DHCPv4", 405 draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in 406 progress), July 2011. 408 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 409 RFC 2131, March 1997. 411 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 412 Extensions", RFC 2132, March 1997. 414 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 415 RFC 3046, January 2001. 417 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 418 "Link Selection sub-option for the Relay Agent Information 419 Option for DHCPv4", RFC 3527, April 2003. 421 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 422 Identifiers for Dynamic Host Configuration Protocol 423 Version Four (DHCPv4)", RFC 4361, February 2006. 425 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 426 Problem Statement", RFC 4925, July 2007. 428 [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client 429 Identifier Option in DHCP Server Replies", RFC 6842, 430 January 2013. 432 11.2. Informative References 434 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 435 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 436 Farrer, "DHCPv4 over DHCPv6 Transport", 437 draft-ietf-dhc-dhcpv4-over-dhcpv6-02 (work in progress), 438 October 2013. 440 [I-D.ietf-dhc-v4configuration] 441 Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration 442 Over IPv6 Only Networks", 443 draft-ietf-dhc-v4configuration-02 (work in progress), 444 September 2013. 446 [I-D.ietf-softwire-public-4over6] 447 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 448 IPv4 over IPv6 Access Network", 449 draft-ietf-softwire-public-4over6-10 (work in progress), 450 July 2013. 452 Appendix A. Motivation for selecting this particular solution 454 We considered three possible solutions to the problem of configuring 455 IPv4 addresses on an IPv6 network. 457 A.1. Configuring IPv4 with DHCPv6 459 Use DHCPv6 instead of DHCPv4, to provision IPv4-related connectivity. 460 In DHCPv6, the provisioned IPv4 address can be embedded into IPv6 461 address, or carried within a new option. Along with that, dedicated 462 options are needed to convey IPv4-related information, such as the 463 IPv4 address of DNS server, NTP server, etc. Therefore it will put a 464 certain amount of IPv6-unrelated information into DHCPv6 protocol. 466 This solution was rejected for two reasons. First, the DHCPv6 467 protocol does not currently provide a mechanism for recording 468 bindings between IPv4 addresses and DHCPv6 clients. Extending DHCPv6 469 to provide this functionality would be a substantial change to the 470 existing protocol. 472 Second, a deliberate choice was made when the DHCPv6 protocol was 473 defined to avoid simply copying existing functionality from DHCPv4. 474 While it is possible, using DHCPv6, to deliver IPv4 addresses as 475 IPv6-encoded IPv4 addresses, it might be necessary to add additional 476 DHCPv6 options simply to support IPv4. These options would then 477 remain in the protocol, long after the need for IPv4 has gone. 479 By comparison, any extensions to DHCPv4 will naturally be forgotten 480 when DHCPv4 is no longer needed. This means that whatever extensions 481 we make to DHCPv4 to solve the problem, we can stop maintaining as 482 soon as IPv4 is no longer needed. 484 A.2. Tunnel DHCPv4 over IPv6 486 Use DHCPv4 for configuration, and tunnel DHCPv4-in-IPv4 messages over 487 IPv6. Unlike the previous approach where DHCPv6 is used for both 488 IPv4 and IPv6 connectivity, this approach preserves the separation 489 between IPv4 and IPv6 connectivity information. It maintains the 490 IPv4 service without major modifications to IPv6-related provisioning 491 resources, and sustains DHCPv4 to be the IPv4-related information 492 carrier. 494 This approach was not chosen because it adds a requirement for DHCPv4 495 to operate over an IPv4-in-IPv6 tunnel. DHCPv4 clients generally 496 operate on broadcast networks, not on tunnels. To make DHCPv4 497 operate over a tunnel would require substantial changes to the DHCPv4 498 client, as well as maintaining a tunnel over which to deliver DHCPv4 499 traffic. 501 This also creates a chicken-and-egg problem: how do we set up an IPv4 502 tunnel when we do not know our IPv4 address? Solutions to these 503 problems were proposed, but they require significant changes to the 504 DHCP client and significant additional work to make a tunnel that 505 could carry the DHCP packets. 507 A.3. DHCPv4 relayed over IPv6 509 Use DHCPv4 for configuration, and extend it to use an IPv6 transport 510 for relayed messages. Essentially this involves a single change to 511 the protocol, to allow DHCPv4 servers or relay agents to send and 512 receive packets using an IPv6 transport. No changes are required on 513 the client. 515 The working group chose this third solution because, of the three, it 516 required the fewest changes to the DHCP protocol, so that it was 517 easiest to specify and easiest to implement. 519 Appendix B. Discussion on One Host Retrieving Multiple Addresses 520 through One CRA 522 This document is written with the intention of supporting a use case 523 where a single DHCP client is configuring a single tunnel endpoint 524 per physical link. The technique described in this document could be 525 used by a host needing to configure more than one tunnel endpoint on 526 the same physical link, i.e., to retrieve multiple addresses through 527 the same CRA. 529 DHCP server implementing this specification implements Client 530 Identifier Option in DHCP server replies [RFC6842]. 532 In general this specification is intended not to require modification 533 of DHCP clients. However, DHCP clients being used to configure 534 multiple tunnel endpoints have to be modified; otherwise there is no 535 way for such DHCP clients to differentiate between DHCP responses. 536 Therefore, in such case, the DHCP client using this specification 537 uses a different client identifier for each tunnel endpoint being 538 configured. Such DHCP clients examine the response from the DHCP 539 server and use the client identifier to differentiate between the 540 DHCP client state machines for each tunnel endpoint. 542 In order to satisfy the requirement that client identifiers be 543 unique, DHCP clients configuring multiple tunnel endpoints implement 544 Node-specific Client Identifiers for DHCPv4 [RFC4361]. Such clients 545 use a different IAID for each tunnel endpoint. 547 It is assumed here that every client state machine on a multiple- 548 tunnel-endpoint link can hear all the DHCP messages (and subsequently 549 accept the messages intended for it). How this is accomplished is 550 left to the implementor. However, implementations must follow this 551 requirement; otherwise, it will be impossible for multiple tunnel 552 endpoints to be successfully configured. The easiest way to 553 accomplish this is to have a single DHCP client process with multiple 554 DHCP state machines, and to dispatch each DHCP message to the correct 555 DHCP client state machine using the client identifier. However, this 556 is not required; any mechanism that results in client state machines 557 receiving the messages that are intended for them will suffice. 559 Authors' Addresses 561 Yong Cui 562 Tsinghua University 563 Department of Computer Science, Tsinghua University 564 Beijing 100084 565 P.R.China 567 Phone: +86-10-6260-3059 568 Email: yong@csnet1.cs.tsinghua.edu.cn 570 Peng Wu 571 Tsinghua University 572 Department of Computer Science, Tsinghua University 573 Beijing 100084 574 P.R.China 576 Phone: +86-10-6278-5822 577 Email: pengwu.thu@gmail.com 578 Jianping Wu 579 Tsinghua University 580 Department of Computer Science, Tsinghua University 581 Beijing 100084 582 P.R.China 584 Phone: +86-10-6278-5983 585 Email: jianping@cernet.edu.cn 587 Ted Lemon 588 Nominum, Inc. 589 2000 Seaport Blvd 590 Redwood City, CA 94063 591 USA 593 Phone: +1-650-381-6000 594 Email: mellon@nominum.com 596 Qi Sun 597 Tsinghua University 598 Department of Computer Science, Tsinghua University 599 Beijing 100084 600 P.R.China 602 Phone: +86-10-6278-5822 603 Email: sunqi@csnet1.cs.tsinghua.edu.cn