idnits 2.17.1 draft-ietf-dhc-dhcpv4-over-ipv6-07.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 21, 2013) is 3864 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: March 25, 2014 Tsinghua University 6 T. Lemon 7 Nominum, Inc. 8 September 21, 2013 10 DHCPv4 over IPv6 Transport 11 draft-ietf-dhc-dhcpv4-over-ipv6-07 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 25, 2014. 43 Copyright Notice 45 Copyright (c) 2013 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Client Relay Agent IPv6 Address Sub-option . . . . . . . . . . 5 64 5. Client Relay Agent Behavior . . . . . . . . . . . . . . . . . 6 65 6. IPv6-Transport Server Behavior . . . . . . . . . . . . . . . . 7 66 7. IPv6-Transport Relay Agent Behavior . . . . . . . . . . . . . 8 67 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 68 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 69 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 11.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Appendix A. Motivation for selecting this particular solution . . 10 74 A.1. Configuring IPv4 with DHCPv6 . . . . . . . . . . . . . . 10 75 A.2. Tunnel DHCPv4 over IPv6 . . . . . . . . . . . . . . . . . 11 76 A.3. DHCPv4 relayed over IPv6 . . . . . . . . . . . . . . . . 11 77 Appendix B. Discussion on One Host Retrieving Multiple 78 Addresses through One CRA . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 DHCPv4 [RFC2131] was not designed with IPv6 in mind: DHCPv4 cannot 84 operate on an IPv6 network. However, as dual-stack networks become a 85 reality, the need arises to allocate IPv4 addresses in an IPv6 86 environment. To meet this demand, this document extends the DHCPv4 87 protocol to allow the use of an IPv6 network for transport. 89 A typical scenario that probably requires this feature is IPv4-over- 90 IPv6 hub and spoke tunnel [RFC4925]. In this scenario, IPv4-over- 91 IPv6 tunnel is used to provide IPv4 connectivity to end users (hosts 92 or end networks) across an IPv6 network. If the IPv4 addresses of 93 the end users are provisioned by the concentrator side, then the 94 provisioning process should be able to cross the IPv6 network. One 95 such tunnel mechanism is demonstrated in 96 [I-D.ietf-softwire-public-4over6]. 98 2. Terminology 100 This document makes use of the following terms: 102 o DHCPv4: IPv4 Dynamic Host Configuration Protocol [RFC2131]. 104 o Client Relay Agent (CRA): a special DHCPv4 Relay Agent which 105 relays between DHCPv4 client and DHCPv4 server using an IPv6 106 network. A CRA either sits on the same, IPv6-accessible host with 107 the DHCPv4 client, or sits on the same link with the host running 108 DHCPv4 client. 110 o Host Client Relay Agent (HCRA): a CRA which sits on the same, 111 IPv6-accessible host with the DHCPv4 client. 113 o On-Link Client Relay Agent (LCRA): a CRA which sits on the same 114 link with the host that runs DHCPv4 client. 116 o IPv6-Transport Server (TSV): a DHCPv4 Server that supports IPv6 117 transport. The TSV listens on IPv6 for incoming DHCPv4 messages, 118 and sends DHCPv4 messages in IPv6 packets. 120 o IPv6-Transport Relay Agent (TRA): a DHCPv4 Relay Agent that 121 supports IPv6 transport. The TRA sits on a machine which has both 122 IPv6 and IPv4 connectivity, and relays DHCP messages between a CRA 123 and a regular DHCPv4 server. Unlike the CRA, the TRA sits on the 124 remote end of IPv6 network, and communicates with DHCPv4 server 125 through IPv4. 127 o Client Relay Agent IPv6 Address Sub-option (CRA6ADDR sub-option): 128 a new sub-option of the DHCP Relay Agent Information Option 129 [RFC3046], defined in this document, which is used to carry the 130 IPv6 address of the CRA. 132 3. Protocol Summary 134 The scenario for DHCPv4 over IPv6 transport is shown in Figure 1. 135 DHCPv4 clients and DHCPv4 server/relay are separated by an IPv6 136 network in the middle. DHCP messages between a client and the 137 server/relay cannot naturally be forwarded to each other because they 138 are IPv4 UDP packets, either unicast or broadcast. To bridge this 139 gap, both the client side and the server/relay side can enable DHCPv4 140 over IPv6 transport. More precisely, it is necessary for them to 141 support delivering and receiving DHCP messages in IPv6 UDP packets 142 and thereby traverse the IPv6 network. 144 On the client side, a special relay agent called Client Relay Agent 145 is placed on the same host with the client, or on the link of the 146 host. CRA is used to relay DHCP messages from the client to the 147 server, and from the server to the client. CRA sends DHCPv4 messages 148 to the server through unicast IPv6 UDP, and receives unicast IPv6 UDP 149 packets with the DHCPv4 messages from the server. By using CRA, no 150 extension is required on the DHCP client. 152 +-------------------------+ 153 +------+ | 154 |DHCPv4| | 155 |Client| +-------+ 156 +------+ |DHCPv4 | 157 | IPv6 Network |Server/| 158 +------+ |Relay | 159 |DHCPv4| +-------+ 160 |Client| | 161 +------+ | 162 +-------------------------+ 164 Figure 1 Scenario of DHCPv4 over IPv6 Transport 166 The IPv6-Transport DHCPv4 server can receive DHCP messages delivered 167 in IPv6 UDP from the CRA, and send out DHCP messages to the CRA using 168 IPv6 UDP (figure 2(a)). The TSV sends DHCP messages to the IPv6 169 address from which it receives relevant DHCP messages earlier. 171 When CRAs communicate with an IPv6-Transport Relay Agent rather than 172 with a server directly, the situation becomes a little more 173 complicated. Besides the IPv6 communication with a CRA, a TRA also 174 communicates with a regular DHCPv4 server through IPv4. Therefore, 175 when the TRA relays DHCP messages between a CRA and the DHCPv4 176 server, it receives DHCP message from the CRA in IPv6 and sends it to 177 the server in IPv4, as well as receives DHCP message from the server 178 in IPv4 and sends it to the CRA in IPv6. 180 The TRA sends the IPv6 address of the CRA to the DHCP server using 181 the Client Relay Agent IPv6 Address (CRA6ADDR) suboption, defined in 182 this document. The DHCP server returns this suboption to the TRA as 183 required in [RFC3046]. The TRA then uses the returned CRA6ADDR 184 suboption to determine the destination address to which to relay the 185 response. 187 +------+ +------+ 188 |client| IPv6 network |TSV | 189 |+HCRA |----------------| | 190 +------+ +------+ 192 +------+ +------+ +------+ 193 |client| |LCRA | IPv6 network |TSV | 194 | |--| |----------------| | 195 +------+ +------+ +------+ 196 (a)client--server case 198 +------+ +------+ +------+ 199 |client| IPv6 network |TRA | IPv4 network |server| 200 |+HCRA |----------------| |--------------| | 201 +------+ +------+ +------+ 203 +------+ +------+ +------+ +------+ 204 |client| |LCRA | IPv6 network |TRA | IPv4 network |server| 205 | |--| |----------------| |--------------| | 206 +------+ +------+ +------+ +------+ 208 (b)client--relay--server case 210 Figure 2 Protocol Summary 212 4. Client Relay Agent IPv6 Address Sub-option 214 The CRA6ADDR suboption is a suboption of the Relay Agent Information 215 Option [RFC3046]. It encodes the IPv6 address of the machine from 216 which a DHCPv4-in-IPv6 CRA-to-TRA message was received. It is used 217 by the TRA to relay DHCPv4 replies back to the proper CRA. The TRA 218 uses the IPv6 address encoded in this suboption as the destination 219 IPv6 address when relaying a DHCPv4 message from the DHCP server to 220 the CRA. 222 The CRA6ADDR sub-option has a fixed length of 18 octets. The SubOpt 223 code is tbd by IANA, the length field is 16, and the following 16 224 octets contain the CRA IPv6 address. 226 SubOpt Len Agent Remote ID 227 +------+------+------+------+------+- -+------+ 228 | tbd | 16 | a1 | a2 | a3 | ... | a16 | 229 +------+------+------+------+------+- -+------+ 231 Figure 3 Client Relay Agent IPv6 Address Sub-option format 233 5. Client Relay Agent Behavior 235 A Client Relay Agent sits on the same host with the DHCPv4 client 236 (HCRA), or on the same link as the host (LCRA). A CRA listens for 237 DHCP packets on IPv4 on port 67, and also listens for DHCP packets on 238 IPv6 on port 67. 240 A CRA is configured with one or more IPv6 addresses of TSV/TRA as the 241 destination(s). The CRA is also configured with a global IPv6 242 address before the DHCPv4 client starts, so that it can forward 243 DHCPv4 messages over IPv6. 245 When the CRA receives any DHCP message on IPv4 with BOOTP op field 246 set to 1, it forwards the message over UDP on IPv6 using a standard 247 DHCP message format, with source port 67 and destination port 67. 248 The CRA forwards the message to each TSV or TRA address with which it 249 is configured. 251 When the CRA receives any message on IPv6 with BOOTP op field set to 252 2, the CRA checks to see if the message contains option 82. If it 253 does, the CRA silently discards the message. Otherwise, it relays 254 the message to the DHCP client using IPv4. 256 When the CRA receives any message on IPv6 with BOOTP op field set to 257 4, it decapsulates the message as specified in DHCPv4 Relay Agent 258 Encapsulation [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. If the CRA 259 does not support encapsulation, it silently discards the message. 261 The LCRA or HCRA does not use the Relay Agent Information Option 263 [RFC3046]. If either type of CRA needs to send relay agent options, 264 it uses relay agent encapsulation as defined in 265 [I-D.ietf-dhc-dhcpv4-relay-encapsulation]. 267 An HCRA only serves the client inside the same host, while the LCRA 268 serves any client on the link. When the IPv6 address of TSV/TRA is 269 provisioned to the host running the DHCP client, it uses HCRA; else 270 the client depends on LCRA. A HCRA serves only one link; the 271 multiple-link case is handled by multiple HCRA instances. A LCRA 272 does not necessarily need an IPv4 address, though it may be 273 configured with one. 275 In HCRA case, the DHCPv6 client (or other IPv6 configuration 276 processes), DHCPv4 client and CRA run on the same physical interface. 277 In some cases, the host running the DHCPv4 client and CRA defers the 278 operation of the DHCPv4 client until an IPv6 address of the interface 279 has been acquired, as well as the TSV/TRA address information. If 280 this is not done, the DHCPv4 client may send several messages that 281 the CRA cannot relay, and this could result in long delays before the 282 DHCPv4 client actually gets an IPv4 address. 284 6. IPv6-Transport Server Behavior 286 To support IPv6 transport, the behavior of DHCPv4 server is extended. 287 The IPv6-Transport Server can listen on IPv6 port 67 for DHCPv4 288 messages, and send DHCPv4 messages through IPv6. 290 A TSV listens for DHCP messages on IPv6 UDP port 67 and IPv4 UDP port 291 67. When it receives a DHCP message on IPv6, it retains the IPv6 292 source address of that message until it has sent a response. When it 293 sends a response, it sends the response to this IPv6 address, with 294 destination port 67. 296 The TSV sends a server identifier option [RFC2132] containing an IPv4 297 address which will be reachable from the client once the residual 298 IPv4 service is set up. This follows the server id option 299 requirement in [RFC2131]. 301 The rest of TSV DHCP process is the same with normal DHCPv4 server. 302 A TSV also listens on IPv4 UDP port 67 like a normal DHCPv4 server, 303 and process IPv4 DHCPv4 messages normally. This requirement exists 304 because when a DHCPv4 client renews, it sends its renewal messages 305 directly to the server, rather than broadcasting them. 307 Because the CRA may use relay agent encapsulation 308 [I-D.ietf-dhc-dhcpv4-relay-encapsulation], the TSV supports it. A 309 TSV that does not support it will not interoperate with a CRA that 310 sends relay agent options. 312 7. IPv6-Transport Relay Agent Behavior 314 An IPv6-Transport Relay Agent sits between IPv6 network and IPv4 315 network, and relays DHCPv4 message between CRAs and IPv4-only DHCPv4 316 server. The communication between CRAs and the TRA uses IPv6, while 317 the communication between the TRA and the server uses IPv4. A TRA 318 listens on IPv6 UDP port 67 for DHCP messages with BOOTP op field set 319 to 1 or 3, as well as IPv4 UDP port 67 for DHCP messages with BOOTP 320 op field set to 2 or 4. 322 When relaying a DHCP message from CRA to server, the TRA adds a 323 CRA6ADDR suboption. The TRA sets the contents of this suboption to 324 the IPv6 source address of the message. The TRA also stores one its 325 own IPv4 addresses in the giaddr field of the DHCP message. The TRA 326 may include a Link Selection sub-option [RFC3527] to indicate to the 327 DHCP server which link to use when choosing an IP address. If the 328 received message is a RELAYFORWARD message, the TRA encapsulates the 329 message in a new RELAYFORWARD message and stores the CRA6ADDR in the 330 new relay segment. If it is some other message, the TRA appends a 331 Relay Agent Information Option as described in [RFC3046], but may 332 encapsulate it in the same way as RELAYFORWARD message instead, which 333 depends on the implementation. 335 When receiving a DHCP message from the DHCP server, if the message 336 contains no CRA6ADDR suboption, the TRA discards the message. 337 Otherwise, it processes it as required by [RFC3046] and 338 [I-D.ietf-dhc-dhcpv4-relay-encapsulation], and forwards it to the 339 IPv6 address recorded in the CRA6ADDR sub-option, with source port 67 340 and destination port number 67. 342 8. Security Consideration 344 This mechanism may rise a new form of DHCP protocol attack. A 345 malicious attacker in IPv6 can interference with the DHCPv4 process 346 by inject fake DHCPv4-in-IPv6 messages which will be handled by TSV 347 or TRA. However, the damage is the same with the known DHCPv4 attack 348 happened in IPv4. The only difference is the attacker and the victim 349 could locate in different address families. 351 Another impact is DHCP filtering. There are firewalls today capable 352 of filtering DHCP traffic (DHCPv4 over IPv4 and DHCPv6 over IPv6 353 packages). The DHCP messages with the new, DHCPv4-in-IPv6 style may 354 bypass these firewalls. Nevertheless it is not difficult for them to 355 make some slight modification and adapt to the new DHCPv4 message 356 pattern. 358 9. IANA Consideration 360 IANA is requested to assign one new sub-option code from the registry 361 of DHCP Agent Sub-Option Codes maintained in 362 http://www.iana.org/assignments/bootp-dhcp-parameters. This sub- 363 option code will be assigned to the Client Relay Agent IPv6 Address 364 Sub-option. 366 10. Contributors 368 The following gentlemen also contributed to the effort: 370 Francis Dupont 371 Internet Systems Consortium, Inc. 373 Email: fdupont@isc.org 375 Tomasz Mrugalski 376 Internet Systems Consortium, Inc. 378 Email: tomasz.mrugalski@gmail.com 380 Dmitry Anipko 381 Microsoft Corporation 383 Email: danipko@microsoft.com 385 11. References 387 11.1. Normative References 389 [I-D.ietf-dhc-dhcpv4-relay-encapsulation] 390 Lemon, T., Deng, H., and L. Huang, "Relay Agent 391 Encapsulation for DHCPv4", 392 draft-ietf-dhc-dhcpv4-relay-encapsulation-01 (work in 393 progress), July 2011. 395 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 396 RFC 2131, March 1997. 398 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 399 Extensions", RFC 2132, March 1997. 401 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 402 RFC 3046, January 2001. 404 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 405 "Link Selection sub-option for the Relay Agent Information 406 Option for DHCPv4", RFC 3527, April 2003. 408 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 409 Identifiers for Dynamic Host Configuration Protocol 410 Version Four (DHCPv4)", RFC 4361, February 2006. 412 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 413 Problem Statement", RFC 4925, July 2007. 415 [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client 416 Identifier Option in DHCP Server Replies", RFC 6842, 417 January 2013. 419 11.2. Informative References 421 [I-D.ietf-softwire-public-4over6] 422 Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 423 IPv4 over IPv6 Access Network", 424 draft-ietf-softwire-public-4over6-10 (work in progress), 425 July 2013. 427 Appendix A. Motivation for selecting this particular solution 429 We considered three possible solutions to the problem of configuring 430 IPv4 addresses on an IPv6 network. 432 A.1. Configuring IPv4 with DHCPv6 434 Use DHCPv6 instead of DHCPv4, to provision IPv4-related connectivity. 435 In DHCPv6, the provisioned IPv4 address can be embedded into IPv6 436 address, or carried within a new option. Along with that, dedicated 437 options are needed to convey IPv4-related information, such as the 438 IPv4 address of DNS server, NTP server, etc. Therefore it will put a 439 certain amount of IPv6-unrelated information into DHCPv6 protocol. 441 This solution was rejected for two reasons. First, the DHCPv6 442 protocol does not currently provide a mechanism for recording 443 bindings between IPv4 addresses and DHCPv6 clients. Extending DHCPv6 444 to provide this functionality would be a substantial change to the 445 existing protocol. 447 Second, a deliberate choice was made when the DHCPv6 protocol was 448 defined to avoid simply copying existing functionality from DHCPv4. 449 While it is possible, using DHCPv6, to deliver IPv4 addresses as 450 IPv6-encoded IPv4 addresses, it might be necessary to add additional 451 DHCPv6 options simply to support IPv4. These options would then 452 remain in the protocol, long after the need for IPv4 has gone. 454 By comparison, any extensions to DHCPv4 will naturally be forgotten 455 when DHCPv4 is no longer needed. This means that whatever extensions 456 we make to DHCPv4 to solve the problem, we can stop maintaining as 457 soon as IPv4 is no longer needed. 459 A.2. Tunnel DHCPv4 over IPv6 461 Use DHCPv4 for configuration, and tunnel DHCPv4-in-IPv4 messages over 462 IPv6. Unlike the previous approach where DHCPv6 is used for both 463 IPv4 and IPv6 connectivity, this approach preserves the separation 464 between IPv4 and IPv6 connectivity information. It maintains the 465 IPv4 service without major modifications to IPv6-related provisioning 466 resources, and sustains DHCPv4 to be the IPv4-related information 467 carrier. 469 This approach was not chosen because it adds a requirement for DHCPv4 470 to operate over an IPv4-in-IPv6 tunnel. DHCPv4 clients generally 471 operate on broadcast networks, not on tunnels. To make DHCPv4 472 operate over a tunnel would require substantial changes to the DHCPv4 473 client, as well as maintaining a tunnel over which to deliver DHCPv4 474 traffic. 476 This also creates a chicken-and-egg problem: how do we set up an IPv4 477 tunnel when we do not know our IPv4 address? Solutions to these 478 problems were proposed, but they require significant changes to the 479 DHCP client and significant additional work to make a tunnel that 480 could carry the DHCP packets. 482 A.3. DHCPv4 relayed over IPv6 484 Use DHCPv4 for configuration, and extend it to use an IPv6 transport 485 for relayed messages. Essentially this involves a single change to 486 the protocol, to allow DHCPv4 servers or relay agents to send and 487 receive packets using an IPv6 transport. No changes are required on 488 the client. 490 The working group chose this third solution because, of the three, it 491 required the fewest changes to the DHCP protocol, so that it was 492 easiest to specify and easiest to implement. 494 Appendix B. Discussion on One Host Retrieving Multiple Addresses 495 through One CRA 497 This document is written with the intention of supporting a use case 498 where a single DHCP client is configuring a single tunnel endpoint 499 per physical link. The technique described in this document could be 500 used by a host needing to configure more than one tunnel endpoint on 501 the same physical link, i.e., to retrieve multiple addresses through 502 the same CRA. However, the following additional behavior is required 503 to support this case. 505 DHCP server implementing this specification implements Client 506 Identifier Option in DHCP server replies [RFC6842]. 508 In general this specification is intended not to require modification 509 of DHCP clients. However, DHCP clients being used to configure 510 multiple tunnel endpoints have to be modified; otherwise there is no 511 way for such DHCP clients to differentiate between DHCP responses. 512 Therefore, in such case, the DHCP client using this specification 513 uses a different client identifier for each tunnel endpoint being 514 configured. Such DHCP clients examine the response from the DHCP 515 server and use the client identifier to differentiate between the 516 DHCP client state machines for each tunnel endpoint. 518 In order to satisfy the requirement that client identifiers be 519 unique, DHCP clients configuring multiple tunnel endpoints implement 520 Node-specific Client Identifiers for DHCPv4 [RFC4361]. Such clients 521 use a different IAID for each tunnel endpoint. 523 It is assumed here that every client state machine on a multiple- 524 tunnel-endpoint link can hear all the DHCP messages (and subsequently 525 accept the messages intended for it). How this is accomplished is 526 left to the implementor. However, implementations must follow this 527 requirement; otherwise, it will be impossible for multiple tunnel 528 endpoints to be successfully configured. The easiest way to 529 accomplish this is to have a single DHCP client process with multiple 530 DHCP state machines, and to dispatch each DHCP message to the correct 531 DHCP client state machine using the client identifier. However, this 532 is not required; any mechanism that results in client state machines 533 receiving the messages that are intended for them will suffice. 535 Authors' Addresses 537 Yong Cui 538 Tsinghua University 539 Department of Computer Science, Tsinghua University 540 Beijing 100084 541 P.R.China 543 Phone: +86-10-6260-3059 544 Email: yong@csnet1.cs.tsinghua.edu.cn 546 Peng Wu 547 Tsinghua University 548 Department of Computer Science, Tsinghua University 549 Beijing 100084 550 P.R.China 552 Phone: +86-10-6278-5822 553 Email: pengwu.thu@gmail.com 555 Jianping Wu 556 Tsinghua University 557 Department of Computer Science, Tsinghua University 558 Beijing 100084 559 P.R.China 561 Phone: +86-10-6278-5983 562 Email: jianping@cernet.edu.cn 564 Ted Lemon 565 Nominum, Inc. 566 2000 Seaport Blvd 567 Redwood City, CA 94063 568 USA 570 Phone: +1-650-381-6000 571 Email: mellon@nominum.com