idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-ipv6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2012) is 4243 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4925 == Outdated reference: A later version (-07) exists of draft-ietf-dhc-client-id-05 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-public-4over6-03 Summary: 1 error (**), 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: Standards Track J. Wu 5 Expires: March 17, 2013 Tsinghua University 6 T. Lemon 7 Nominum, Inc. 8 September 13, 2012 10 DHCPv4 over IPv6 Transport 11 draft-ietf-dhc-dhcpv4-over-ipv6-04 13 Abstract 15 In IPv6 networks, there remains a need to provide IPv4 service for 16 some residual devices. This document describes a mechanism for 17 allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 18 transport. It is done by putting a special relay agent function 19 (Client Relay Agent) on the client side, as well as extending the 20 behavior of the server; in the case where DHCP server only supports 21 IPv4 transport, a relay agent is extended to support IPv6 transport 22 (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, 23 with a new Relay Agent Information sub-option added to carry the IPv6 24 address of the Client Relay Agent. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 17, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 6 65 6. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6 66 7. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 67 8. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 68 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 69 10. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9 70 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 12.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Appendix 1. Motivation for selecting this particular solution . . 11 75 1.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 11 76 1.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11 77 1.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 12 78 Appendix 2. Discussion on One Host Retrieving Multiple 79 Addresses through One CRA . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot 85 operate on an IPv6 network. However, as dual-stack networks become a 86 reality, the need arises to allocate IPv4 addresses in an IPv6 87 environment. To meet this demand, this document extends the DHCPv4 88 protocol to allow the use of an IPv6 network for transport. 90 A typical scenario that probably requires this feature is IPv4-over- 91 IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- 92 IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts 93 or end networks) across an IPv6 network. If the IPv4 addresses of 94 the end users are provisioned by the concentrator side, then the 95 provisioning process should be able to cross the IPv6 network. One 96 such tunnel mechanism is demonstrated in 97 [I-D.ietf-softwire-public-4over6]. DHCPv4 over IPv6 would be a 98 generic solution for this scenario. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Terminology 108 This document makes use of the following terms: 110 o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. 112 o Client Relay Agent(CRA): a special DHCPv4 Relay Agent which relays 113 between DHCPv4 client and DHCPv4 server using an IPv6 network. A 114 CRA either sits on the same, IPv6-accessable host with the DHCPv4 115 client, or sits on the same link with the host. 117 o Host Client Relay Agent(HCRA): a CRA which sits on the same, IPv6- 118 accessible host with the DHCPv4 client. 120 o On-Link Client Relay Agent(LCRA): a CRA which sits on the same 121 link with the host that runs DHCPv4 client. 123 o IPv6-Transport Server(TSV): a DHCPv4 Server that supports IPv6 124 transport. TSV listens on IPv6 for incoming DHCPv4 messages, and 125 sends DHCPv4 messages in IPv6 packets. 127 o IPv6-Transport Relay Agent(TRA): a DHCPv4 Relay Agent that 128 supports IPv6 transport. TRA sits on a machine which has both 129 IPv6 and IPv4 connectivity, and relays DHCP messages between CRA 130 and regular DHCPv4 server. Unlike CRA, TRA sits on the remote end 131 of IPv6 network, and communicates with DHCPv4 server through IPv4. 133 o Client Relay Agent IPv6 Address Sub-option (CRA6ADDR sub-option): 134 a new sub-option of the DHCP Relay Agent Information Option 135 [RFC3046], defined in this document, which is used to carry the 136 IPv6 address of the CRA. 138 4. Protocol Summary 140 The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. 141 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 142 network in the middle. DHCP messages between a client and the 143 server/relay cannot naturally be forwarded to each other because they 144 are IPv4 UDP packets, either unicast or broadcast. To bridge this 145 gap, both the client side and the server/relay side must enable 146 DHCPv4 over IPv6 transport. More precisely, they must support 147 delivering and receiving DHCP messages in IPv6 UDP packets and 148 thereby traverse the IPv6 network. 150 On the client side, a special relay agent called Client Relay Agent 151 is placed on the same host with the client, or on the link of the 152 host. CRA is used to relay DHCP messages from the client to the 153 server, and from the server to the client. CRA sends DHCPv4 messages 154 to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP 155 packets with the DHCPv4 messages from the server. By using CRA, no 156 extension is required on the DHCP client. 158 +-------------------------+ 159 +------+ | 160 |DHCPv4| | 161 |Client| +-------+ 162 +------+ |DHCPv4 | 163 | IPv6 Network |Server/| 164 +------+ |Relay | 165 |DHCPv4| +-------+ 166 |Client| | 167 +------+ | 168 +-------------------------+ 170 Figure 1 Scenario of DHCPv4 over IPv6 Transport 171 The IPv6-Transport DHCPv4 server can receive DHCP messages delivered 172 in IPv6 UDP from CRA, and send out DHCP messages to CRA using IPv6 173 UDP (figure 2(a)). TSV should send DHCP messages to the IPv6 address 174 from which it receives relevant DHCP messages earlier. 176 When CRAs communicate with an IPv6-Transport Relay Agent rather than 177 with a server directly, the situation becomes a little more 178 complicated. Besides the IPv6 communication with CRA, TRA also 179 communicates with a regular DHCPv4 server through IPv4. Therefore, 180 when TRA relays DHCP messages between a CRA and the DHCPv4 server, it 181 receives DHCP message from the CRA in IPv6 and sends it to the server 182 in IPv4, as well as receives DHCP message from the server in IPv4 and 183 sends it to the CRA in IPv6. 185 TRA sends the IPv6 address of the CRA to the DHCP server using the 186 Client Relay Agent IPv6 Address suboption, defined in this document. 187 The DHCP server returns this suboption to the TRA as required in 188 [RFC3046]. The TRA then uses the returned CRA6ADDR suboption to 189 determine the destination address to which to relay the response. 191 +------+ +------+ 192 |client| IPv6 network |TSV | 193 |+HCRA |----------------| | 194 +------+ +------+ 196 +------+ +------+ +------+ 197 |client| |LCRA | IPv6 network |TSV | 198 | |--| |----------------| | 199 +------+ +------+ +------+ 200 (a)client--server case 202 +------+ +------+ +------+ 203 |client| IPv6 network |TRA | IPv4 network |server| 204 |+HCRA |----------------| |--------------| | 205 +------+ +------+ +------+ 207 +------+ +------+ +------+ +------+ 208 |client| |LCRA | IPv6 network |TRA | IPv4 network |server| 209 | |--| |----------------| |--------------| | 210 +------+ +------+ +------+ +------+ 212 (b)client--relay--server case 214 Figure 2 Protocol Summary 216 5. Client Relay Agent IPv6 Address Sub-option 218 The CRA6ADDR suboption is a suboption of the Relay Agent Information 219 Option [RFC3046]. It encodes the IPv6 address of the machine from 220 which a DHCPv4-in-IPv6 CRA-to-TRA message was received. It is used 221 by the TRA to relay DHCPv4 replies back to the proper CRA. The TRA 222 uses the IPv6 address encoded in this suboption as the destination 223 IPv6 address when relaying a DHCPv4 message from the DHCP server to 224 the CRA. 226 The CRA6ADDR sub-option has a fixed length of 18 octets. The SubOpt 227 code is tbd by IANA, the length field is 16, and the following 16 228 octets contain the CRA IPv6 address. 230 SubOpt Len Agent Remote ID 231 +------+------+------+------+------+- -+------+ 232 | tbd | 16 | a1 | a2 | a3 | ... | a16 | 233 +------+------+------+------+------+- -+------+ 235 Figure 3 Client Relay Agent IPv6 Address Sub-option format 237 6. Client Relay Agent Behavior 239 A Client Relay Agent sits on the same host with the DHCPv4 client 240 (HCRA), or on the same link as the host (LCRA). CRA listens for DHCP 241 packets on IPv4 on port 67, and also listens for DHCP packets on IPv6 242 on port 67. 244 A CRA is configured with one or more IPv6 addresses of TSV/TRA, using 245 a DHCPv6 option or some other mechanism. The CRA cannot forward 246 DHCPv4 messages before it is configured with an IPv6 address itself, 247 so to function properly, the IPv6 address for the CRA SHOULD be 248 configured before the DHCPv4 client starts. The CRA SHOULD use a 249 global IPv6 address. 251 When the CRA receives any DHCP message on IPv4 with BOOTP op field 252 set to 1, it forwards the message over UDP on IPv6 using a standard 253 DHCP message format, with source port 67 and destination port 67. 254 The CRA forwards the message to each TSV or TRA address with which it 255 is configured. 257 When the CRA receives any message on IPv6 with BOOTP op field set to 258 2, the CRA checks to see if the message contains option 82. If it 259 does, the CRA silently discards the message. Otherwise, it relays 260 the message to the DHCP client using IPv4. 262 When the CRA receives any message on IPv6 with BOOTP op field set to 263 4, it decapsulates the message as specified in DHCPv4 Relay Agent 264 Encapsulation [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. If the CRA 265 does not support encapsulation, it MUST silently discard the message. 267 The LCRA or HCRA MUST NOT use the Relay Agent Information Option 268 [RFC3046]. If either type of CRA needs to send relay agent options, 269 it MUST use relay agent encapsulation as defined in 270 [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. In that case, the TRA and 271 the DHCPv4 server for the TRA MUST support relay agent encapsulation; 272 TSV SHOULD support relay agent encapsulation as well. 274 An HCRA MUST only serve the client inside the same host, while the 275 LCRA SHOULD serve any client on the link. When the IPv6 address of 276 TSV/TRA is provisioned to the host running the DHCP client, it uses 277 HCRA; else the client depends on LCRA. A HCRA serves only one link; 278 the multiple link case MUST be handled by multiple HCRA instances. A 279 LCRA does not necessarily need an IPv4 address, though it may be 280 configured with one. 282 In HCRA case, the DHCPv6 client (or other IPv6 configuration 283 processes), DHCPv4 client and CRA runs on the same physical 284 interface. If possible, the host running the DHCPv4 client and CRA 285 SHOULD defer the operation of the DHCPv4 client until an IPv6 address 286 of the interface has been acquired, as well as the TSV/TRA address 287 information. If this is not done, the DHCPv4 client may send several 288 messages that the CRA cannot relay, and this could result in long 289 delays before the DHCPv4 client actually gets an IPv4 address. 291 7. IPv6-Transport Server Behavior 293 To support IPv6 transport, the behavior of DHCPv4 server is extended. 294 The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4 295 messages, and send DHCPv4 messages through IPv6. 297 A TSV listens for DHCP messages on IPv6 UDP port 67 and IPv4 UDP port 298 67. When it receives a DHCP message on IPv6, it MUST retain the IPv6 299 source address of that message until it has sent a response. When it 300 sends a response, it MUST send the response to this IPv6 address, 301 with destination port 67. 303 The TSV MUST send a server identifier option [RFC2132] containing an 304 IPv4 address which will be reachable from the client once the 305 residual IPv4 service is set up. This follows the server id option 306 requirement in [RFC2131]. 308 The rest of TSV DHCP process is the same with normal DHCPv4 server. 310 A TSV MUST also listen on IPv4 UDP port 67 like a normal DHCPv4 311 server, and process IPv4 DHCPv4 messages normally. This requirement 312 exists because when a DHCPv4 client renews, it sends its renewal 313 messages directly to the server, rather than broadcasting them. 315 Because the CRA may use relay agent encapsulation 316 [I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV SHOULD support it. 317 A TSV that does not support it will not interoperate with a CRA that 318 sends relay agent options. 320 8. IPv6-Transport Relay Agent Behavior 322 An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 323 network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 324 server. The communication between CRAs and the TRA uses IPv6, while 325 the communication between the TRA and the server uses IPv4. A TRA 326 listens on IPv6 UDP port 67 for DHCP messages with BOOTP op field set 327 to 1 or 3, as well as IPv4 UDP port 67 for DHCP messages with BOOTP 328 op field set to 2 or 4. 330 When relaying a DHCP message from CRA to server, TRA MUST add a 331 CRA6ADDR suboption. The TRA sets the contents of this suboption to 332 the IPv6 source address of the message. The TRA MUST also store one 333 its own IPv4 addresses in the giaddr field of the DHCP message. The 334 TRA MAY include a Link Selection sub-option [RFC3527] to indicate to 335 the DHCP server which link to use when choosing an IP address. If 336 the received message is a RELAYFORWARD message, the TRA MUST 337 encapsulate the message in a new RELAYFORWARD message and store the 338 CRA6ADDR in the new relay segment. If it is some other message, the 339 TRA SHOULD append a Relay Agent Information Option as described in 340 [RFC3046], but MAY encapsulate it in the same way as RELAYFORWARD 341 message instead. 343 When receiving a DHCP message from the DHCP server, if the message 344 contains no CRA6ADDR suboption, the TRA MUST discard the message. 345 Otherwise, it processes it as required by [RFC3046] and 346 [I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the 347 IPv6 address recorded in the CRA6ADDR sub-option, with source port 67 348 and destination port number 67. 350 9. Security Consideration 352 This mechanism may rise a new form of DHCP protocol attack. A 353 malicious attacker in IPv6 can interference with the DHCPv4 process 354 by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV 355 or TRA. However, the damage is the same with the known DHCPv4 attack 356 happened in IPv4. The only difference is the attacker and the victim 357 could locate in different address families. 359 Another impact is DHCP filtering. There are firewalls today capable 360 of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 361 packages). The DHCP messages with the new, DHCPv4-in-IPv6 style may 362 bypass these firewalls. Nevertheless it is not difficult for them to 363 make some slight modification and adapt to the new DHCPv4 message 364 pattern. 366 10. IANA consideration 368 IANA is requested to assign one new sub-option code from the registry 369 of DHCP Agent Sub-Option Codes maintained in 370 http://www.iana.org/assignments/bootp-dhcp-parameters. This sub- 371 option code will be assigned to the Client Relay Agent IPv6 Address 372 Sub-option. 374 11. Contributors 376 The following gentlemen also contributed to the effort: 378 Francis Dupont 379 Internet Systems Consortium, Inc. 381 Email: fdupont@isc.org 383 Tomasz Mrugalski 384 Internet Systems Consortium, Inc. 386 Email: tomasz.mrugalski@gmail.com 388 Dmitry Anipko 389 Microsoft Corporation 391 Email: danipko@microsoft.com 393 12. References 394 12.1. Normative References 396 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] 397 Lemon, T., Deng, H., and L. Huang, "Relay Agent 398 Encapsulation for DHCPv4", 399 draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in 400 progress), July 2011. 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 406 RFC 2131, March 1997. 408 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 409 Extensions", RFC 2132, March 1997. 411 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 412 RFC 3046, January 2001. 414 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 415 "Link Selection sub-option for the Relay Agent Information 416 Option for DHCPv4", RFC 3527, April 2003. 418 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 419 Identifiers for Dynamic Host Configuration Protocol 420 Version Four (DHCPv4)", RFC 4361, February 2006. 422 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 423 Problem Statement", RFC 4925, July 2007. 425 12.2. Informative References 427 [I-D.ietf-dhc-client-id] 428 Swamy, N., Halwasia, G., and S. Unit, "Client Identifier 429 Option in DHCP Server Replies", 430 draft-ietf-dhc-client-id-05 (work in progress), 431 September 2012. 433 [I-D.ietf-softwire-public-4over6] 434 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 435 IPv4 over IPv6 Access Network", 436 draft-ietf-softwire-public-4over6-03 (work in progress), 437 August 2012. 439 1. Motivation for selecting this particular solution 441 We considered three possible solutions to the problem of configuring 442 IPv4 addresses on an IPv6 network. 444 1.1. Configuring IPv4 with DHCPv6 446 Use DHCPv6 instead of DHCPv4, to provision IPv4-related connectivity. 447 In DHCPv6, the provisioned IPv4 address can be embedded into IPv6 448 address, or carried within a new option. Along with that, dedicated 449 options are needed to convey IPv4-related information, such as the 450 IPv4 address of DNS server, NTP server, etc. Therefore it will put a 451 certain amount of IPv6-unrelated information into DHCPv6 protocol. 453 This solution was rejected for two reasons. First, the DHCPv6 454 protocol does not currently provide a mechanism for recording 455 bindings between IPv4 addresses and DHCPv6 clients. Extending DHCPv6 456 to provide this functionality would be a substantial change to the 457 existing protocol. 459 Second, a deliberate choice was made when the DHCPv6 protocol was 460 defined to avoid simply copying existing functionality from DHCPv4. 461 While it is possible, using DHCPv6, to deliver IPv4 addresses as 462 IPv6-encoded IPv4 addresses, it might be necessary to add additional 463 DHCPv6 options simply to support IPv4. These options would then 464 remain in the protocol, long after the need for IPv4 has gone. 466 By comparison, any extensions to DHCPv4 will naturally be forgotten 467 when DHCPv4 is no longer needed. This means that whatever extensions 468 we make to DHCPv4 to solve the problem, we can stop maintaining as 469 soon as IPv4 is no longer needed. 471 1.2. Tunnel DHCPv4 over IPv6 473 Use DHCPv4 for configuration, and tunnel DHCPv4-in-IPv4 messages over 474 IPv6. Unlike the previous approach where DHCPv6 is used for both 475 IPv4 and IPv6 connectivity, this approach preserves the separation 476 between IPv4 and IPv6 connectivity information. It maintains the 477 IPv4 service without major modifications to IPv6-related provisioning 478 resources, and sustains DHCPv4 to be the IPv4-related information 479 carrier. 481 This approach was not chosen because it adds a requirement for DHCPv4 482 to operate over an IPv4-in-IPv6 tunnel. DHCPv4 clients generally 483 operate on broadcast networks, not on tunnels. To make DHCPv4 484 operate over a tunnel would require substantial changes to the DHCPv4 485 client, as well as maintaining a tunnel over which to deliver DHCPv4 486 traffic. 488 This also creates a chicken-and-egg problem: how do we set up an IPv4 489 tunnel when we do not know our IPv4 address? Solutions to these 490 problems were proposed, but they require significant changes to the 491 DHCP client and significant additional work to make a tunnel that 492 could carry the DHCP packets. 494 1.3. DHCPv4 relayed over IPv6 496 Use DHCPv4 for configuration, and extend it to use an IPv6 transport 497 for relayed messages. Essentially this involves a single change to 498 the protocol, to allow DHCPv4 servers or relay agents to send and 499 receive packets using an IPv6 transport. No changes are required on 500 the client. 502 The working group chose this third solution because, of the three, it 503 required the fewest changes to the DHCP protocol, so that it was 504 easiest to specify and easiest to implement. 506 2. Discussion on One Host Retrieving Multiple Addresses through One CRA 508 This document is written with the intention of supporting a use case 509 where a single DHCP client is configuring a single tunnel endpoint 510 per physical link. The technique described in this document could be 511 used by a host needing to configure more than one tunnel endpoint on 512 the same physical link, i.e., to retrieve multiple addresses through 513 the same CRA. However, the following additional behavior is REQUIRED 514 to support this case. 516 DHCP server implementing this specification MUST implement Client 517 Identifier Option in DHCP server replies [I-D.ietf-dhc-client-id]. 519 In general this specification is intended not to require modification 520 of DHCP clients. However, DHCP clients being used to configure 521 multiple tunnel endpoints have to be modified; otherwise there is no 522 way for such DHCP clients to differentiate between DHCP responses. 523 Therefore, in such case, the DHCP client using this specification 524 MUST use a different client identifier for each tunnel endpoint being 525 configured. Such DHCP clients MUST examine the response from the 526 DHCP server and use the client identifier to differentiate between 527 the DHCP client state machines for each tunnel endpoint. 529 In order to satisfy the requirement that client identifiers be 530 unique, DHCP clients configuring multiple tunnel endpoints MUST 531 implement Node-specific Client Identifiers for DHCPv4 [RFC4361]. 532 Such clients MUST use a different IAID for each tunnel endpoint. 534 It is assumed here that every client state machine on a multiple- 535 tunnel-endpoint link can hear all the DHCP messages (and subsequently 536 accept the messages intended for it). How this is accomplished is 537 left to the implementor. However, implementations MUST follow this 538 requirement; otherwise, it will be impossible for multiple tunnel 539 endpoints to be successfully configured. The easiest way to 540 accomplish this is to have a single DHCP client process with multiple 541 DHCP state machines, and to dispatch each DHCP message to the correct 542 DHCP client state machine using the client identifier. However, this 543 is not REQUIRED; any mechanism that results in client state machines 544 receiving the messages that are intended for them will suffice. 546 Authors' Addresses 548 Yong Cui 549 Tsinghua University 550 Department of Computer Science, Tsinghua University 551 Beijing 100084 552 P.R.China 554 Phone: +86-10-6260-3059 555 Email: yong@csnet1.cs.tsinghua.edu.cn 557 Peng Wu 558 Tsinghua University 559 Department of Computer Science, Tsinghua University 560 Beijing 100084 561 P.R.China 563 Phone: +86-10-6278-5822 564 Email: pengwu.thu@gmail.com 566 Jianping Wu 567 Tsinghua University 568 Department of Computer Science, Tsinghua University 569 Beijing 100084 570 P.R.China 572 Phone: +86-10-6278-5983 573 Email: jianping@cernet.edu.cn 574 Ted Lemon 575 Nominum, Inc. 576 2000 Seaport Blvd 577 Redwood City, CA 94063 578 USA 580 Phone: +1-650-381-6000 581 Email: mellon@nominum.com