idnits 2.17.1 draft-ietf-dhc-dual-stack-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2005) is 6751 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) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '2') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '4') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '5') (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Congiguration T. Chown 3 Internet-Draft University of Southampton 4 Expires: April 27, 2006 S. Venaas 5 UNINETT 6 C. Strauf 7 Technical University of Clausthal 8 October 24, 2005 10 DHCP: IPv4 and IPv6 Dual-Stack Issues 11 draft-ietf-dhc-dual-stack-04 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 27, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 A node may have support for communications using IPv4 and/or IPv6 45 protocols. Such a node may wish to obtain IPv4 and/or IPv6 46 configuration settings via the Dynamic Host Configuration Protocol 47 (DHCP). The original version of DHCP [1] designed for IPv4 has now 48 been complemented by a new DHCPv6 [4] for IPv6. This document 49 describes issues identified with dual IP version DHCP interactions, 50 the most important aspect of which is how to handle potential 51 problems in clients processing configuration information received 52 from both DHCPv4 and DHCPv6 servers. The document makes a 53 recommendation on the general strategy on how best to handle such 54 issues, and identifies future work to be undertaken. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Configuration scenarios . . . . . . . . . . . . . . . . . . . 3 60 3. Dual-stack issues . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1 Handling multiple responses . . . . . . . . . . . . . . . 4 62 3.2 Different administrative management . . . . . . . . . . . 5 63 3.3 Multiple interfaces . . . . . . . . . . . . . . . . . . . 5 64 3.4 DNS load balancing . . . . . . . . . . . . . . . . . . . . 5 65 3.5 DNS search path issues . . . . . . . . . . . . . . . . . . 5 66 3.6 Protocol startup sequence . . . . . . . . . . . . . . . . 6 67 3.7 DHCP option variations . . . . . . . . . . . . . . . . . . 6 68 3.8 Security issues . . . . . . . . . . . . . . . . . . . . . 6 69 4. Potential solutions . . . . . . . . . . . . . . . . . . . . . 6 70 4.1 Separate DHCP servers . . . . . . . . . . . . . . . . . . 7 71 4.2 Single DHCPv6 server . . . . . . . . . . . . . . . . . . . 8 72 4.3 Optimising for failure with lists of addresses . . . . . . 9 73 4.4 Administrative and other areas . . . . . . . . . . . . . . 9 74 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 80 Intellectual Property and Copyright Statements . . . . . . . . 14 82 1. Introduction 84 The original specification of the Dynamic Host Configuration Protocol 85 (DHCP) was made with only IPv4 in mind. That specification has been 86 subsequently revised, up to the latest version of DHCP [1]. With the 87 arrival of IPv6, a new DHCP specification for IPv6 has been designed, 88 and published as DHCPv6 [4]. 90 These protocols allow nodes to communicate via IPv4 or IPv6 to 91 retrieve configuration settings for operation in a managed 92 environment. While an IPv6 node may acquire address-related 93 configuration settings via IPv6 stateless address autoconfiguration 94 [2], such a node may wish to use stateless DHCPv6 [5] for other 95 administratively configured options, such as DNS or NTP. 97 In early IPv6 deployments, a dual-stack mode of operation is 98 typically used. There will thus be nodes that require both IPv4 and 99 IPv6 configuration settings. This document discusses issues with 100 obtaining such settings in a dual-stack environment. 102 While there is a more general multihoming issue to be solved for DHC, 103 in this text we focus on the specific issues for operating DHCP in a 104 mixed (typically dual-stack) IPv4 and IPv6 environment. 106 In this document, we refer to a "DHCP server" as a server 107 implementing the original DHCP [1], and a "DHCPv6 server" as a server 108 implementing DHCPv6 [4] or its stateless subset [5]. 110 2. Configuration scenarios 112 For a node in an IPv4-only or IPv6-only environment, the choice of 113 DHCP server is a straightforward one; a DHCP server for IPv4, or a 114 DHCPv6 server for IPv6. 116 In a dual-stack environment a node in a managed environment will need 117 to obtain both IPv4 and IPv6 configuration settings, e.g. 119 o IPv4 address 121 o IPv6 address 123 o NTP server 125 o DNS server 127 o NIS server 128 o DNS search path 130 While the format of address settings will be IP-specific, the node 131 may equally well acquire IPv4 or IPv6 addresses for some settings, 132 such as for DNS or NTP, if those services are available via IPv4 or 133 IPv6 transport. Currently, a DHCP server returns IPv4 data, while a 134 DHCPv6 server returns IPv6 data. 136 It is worth noting that in an IPv4 environment, with a DHCP server, 137 the choice of whether to use DHCP is made by the node. In an IPv6 138 environment, the use of the managed and other bits in the Router 139 Advertisement can offer a hint to the node whether or not to use full 140 DHCPv6 or its stateless variant. It is perhaps not clear whether a 141 dual-stack node should do DHCP for IPv4 if Managed and OtherConfig 142 flags in the Router Advertisement are both off; it seems most 143 appropriate that the decision to use DHCP for IPv4 or not should be 144 as if the host was IPv4-only. 146 3. Dual-stack issues 148 In this section we list issues that have been raised to date related 149 to dual-stack DHCP operation. 151 It has been noted from comments that the first four, and possibly 152 five, subsections here may also be viewed as multihoming issues. 154 3.1 Handling multiple responses 156 The general question is how to handle configuration information that 157 may be gathered from multiple sources. Where those sources are DHCP 158 and DHCPv6 servers (which may be two physical nodes or two servers 159 running on the same node) the client node needs to know whether to 160 use the most recent data, or whether to perform some merger or union 161 of the responses by certain rules. A method for merging lists of 162 addresses, for options that carry such information, may also be 163 required. A node may choose to ask a DHCPv6 server and only use a 164 DHCP server if no response is received. 166 Merging is possible, but is likely to be complex. There could be 167 some priority, so that if both DHCP and DHCPv6 servers offer a value, 168 only one is used. Or the node could choose to store and use both, in 169 some order of its choosing. Merging issues are discussed further 170 later in this document. 172 A node may also obtain information from other sources, such as a 173 manual configuration file (for example /etc/resolv.conf for DNS data 174 on many UNIX systems). A node configured manually to use an IPv6 DNS 175 server may lose that configuration if it is in a dual-stack 176 environment and uses DHCP to obtain IPv4 settings; the new IPv4 177 settings from the DHCP response may then overwrite the manual IPv6 178 DNS setting. 180 3.2 Different administrative management 182 In some deployments, the IPv4 and IPv6 services may not be 183 administered by the same organisation or people, such as in a 184 community wireless environment. This poses problems for consistency 185 of data offered by either DHCP version. 187 There may also be different connectivity for the protocols, and the 188 client may gain advantage from knowing which 'administrative domain' 189 is supplying which information. A client may need to use different 190 received information depending on which connectivity is being used. 191 In the example of the community wireless environment, the question of 192 which connectivity is 'better' is a separate issue. 194 3.3 Multiple interfaces 196 A node may have multiple interfaces and run IPv4 and IPv6 on 197 different interfaces. A question then is whether the settings are 198 per interface or per node? 200 Per interface settings can be complex because a client node needs to 201 know which interface system settings like NTP server came from. And 202 it may not be apparent which setting should be used, if e.g. an NTP 203 server option is received on multiple interfaces, potentially over 204 different protocols. 206 3.4 DNS load balancing 208 In some cases it is preferable to list DNS server information in an 209 ordered way per node for load balancing, giving different responses 210 to different clients. Responses from different DHCP and DHCPv6 211 servers may make such configuration problematic, if the knowledge of 212 the load balancing is not available to both servers. 214 3.5 DNS search path issues 216 The DNS search path may vary for administrative reasons. For 217 example, a site under the domain foo.com chooses to place an early 218 IPv6 deployment under the subdomain ipv6.foo.com, until it is 219 confident of offering a full dual-stack service under its main 220 domain. The subtlety here is that the DNS search path then affects 221 choice of protocol used, such as IPv6 for nodes in ipv6.foo.com. 223 3.6 Protocol startup sequence 225 In the dual-stack environment, one needs to consider what happens if, 226 for example, the IPv6 interface (transport) is started after DHCPv4 227 was used to configure the client. Should the client then simply 228 discard the current IPv4 information, or merge it with a subsequent 229 IPv6 response? It may also be possible that one protocol is shut 230 down or started while the system is running. There are similarities 231 here to issues when DHCP renewals have information that may appear 232 that previously was not available (or no longer carry information 233 that has been removed). 235 3.7 DHCP option variations 237 Some options in DHCP are not available in DHCPv6 and vice-versa. 238 Some IP-version limitations naturally apply, such as only IPv6 239 addresses can be in an IPv6 NTP option. The DHCP and DHCPv6 option 240 numbers may be different. 242 Some sites may choose to use IPv4-mapped addresses in DHCPv6-based 243 options. The merits and drawbacks of such an approach need 244 discussion. 246 A site administrator may wish to configure all their dual-stack nodes 247 with (say) two NTP servers, one of which has an IPv4 address, the 248 other an IPv6 address. In this case it may be desirable for an NTP 249 option to carry a list of addresses, where some may be IPv4 and some 250 may be IPv6. In general one could consider having DHCPv6 options 251 that can carry a mix of IPv4 and IPv6 addresses. 253 3.8 Security issues 255 This document does not introduce any new security issues per se. A 256 detailed analysis of DHCP and DHCPv6 security is out of scope for 257 this document. 259 While there is a specification for authentication for DHCP messages 260 [3], the standard seems to have very few, if any, implementations. 261 Thus DHCP and DHCPv6 servers are still liable to be spoofed. Adding 262 an additional protocol may give an extra avenue for attack, should an 263 attacker perhaps spoof a DHCPv6 server but not a DHCP server. 265 4. Potential solutions 267 Here we discuss the two broad solution strategies proposed within the 268 IETF dhc WG. The first is to run separate DHCP and DHCPv6 servers 269 (with the client merging information received from both where 270 necessary, or perhaps choosing to query a particular version first), 271 the second is to run only a DHCPv6 server, and relay IPv4 272 configuration information within (new) IPv4 configuration options. 274 4.1 Separate DHCP servers 276 One solution is to run separate DHCP and DHCPv6 servers. These may 277 or may not be run on the same physical node. The information served 278 from the DHCP servers could be generated from a single database 279 instance for consistency. One might have a single server instance 280 supporting both DHCPv4 and DHCPv6 protocols. 282 In this approach, some best practice guidance is required for how 283 multiple responses are handled or merged. Administrators have the 284 onus to maintain consistency (for example, scripts may generate 285 common DHCP and DHCPv6 configuration files). 287 In some cases, inconsistencies may not matter. In a simple case, an 288 NTP server will give the same time whether accessed by IPv4 or IPv6. 289 Even if different recursive DNS servers are offered via DHCP or 290 DHCPv6, then those name servers should provide the same response to a 291 given query. In cases where sites may be operating a 'two-faced DNS' 292 this will still hold true given the node is on the same topological 293 point on the network from an IPv4 or IPv6 perspective. The order of 294 DNS servers in a node's configuration is not important, unless DNS 295 load balancing is required. 297 In other cases, inconsistencies may be an issue, for example where 298 lists of values are returned, an algorithm is needed for list merger 299 (e.g. "alternate, DHCPv6 first"). Or there may be incompatible 300 configuration values where, for example, DHCPv6 supplies domain names 301 (such the SMTP or POP servers) whereas DHCPv4 provided only IPv4 302 addresses. 304 In the case of separate servers, there are some options like DNS 305 search path, that aren't used in a specific IP protocol context. 307 The multiple server approach will have some simplifications. The 308 DHCPv4 and DHCPv6 servers may provide the same value for a particular 309 parameter, in which case there is no conflict. In some cases the 310 value may be different, but the effect should be the same (such as an 311 NTP server). The crux of the issue is to identify where differences 312 may occur and where these differences will have an impact on node 313 behaviour. 315 One possible solution is to have per-host preferences, or an ordered 316 list of preferences, for example "use manually configured", "prefer 317 DHCPv4", or "prefer DHCPv6", assuming the host can act based upon 318 which protocol is used. It is then up to the site administrator to 319 ensure values returned from either DHCP are consistent (a principle 320 which extends if other methods are used, such as NIS or SLP). 322 4.2 Single DHCPv6 server 324 There is an argument for not having to configure and operate both 325 DHCP and DHCPv6 servers in a dual-stack site environment. The use of 326 both servers may also lead to some redundancy in the information 327 served. Thus one solution may be to modify DHCPv6 to be able to 328 return IPv4 information. This solution is hinted at in the DHCPv6 329 [4] specification: "If there is sufficient interest and demand, 330 integration can be specified in a document that extends DHCPv6 to 331 carry IPv4 addresses and configuration information." This solution 332 may allow DHCP for IPv4 to be completely replaced by DHCPv6 with 333 additional IPv4 information options, for dual-stack nodes. 335 A general argument is that which DHCP protocol is used (whether it's 336 over IPv4 or IPv6) shouldn't affect what kind of addresses you can 337 get configured with it, and that simplicity and predicatability comes 338 from using a single server over a single transport. IPv4-capable 339 hosts will likely remain for at least 10 years, probably much longer; 340 do we want dual-stack hosts (which will become the norm) to do both 341 DHCPv4 and DHCPv6 forever while dual-stack? If you need both servers 342 to configure interfaces with addresses, and get other configuration, 343 then you rely on two separate protocols to work (servers and relays, 344 etc) in order for the host to behave correctly. 346 This approach may require the listing of a mix of IPv4 and IPv6 347 addresses for an option. This could then be considered when new IPv6 348 options are introduced. There could be just two options needed, one 349 new option for the address delegation, and one for doing 350 encapsulation. 352 Also, there are a number of paradigms in DHCPv6 that we miss in 353 DHCPv4. An example is movement away from using MAC addresses for 354 per-host address assignment and instead using DHCP Unique Identifier 355 (DUIDs) or Identity Association Identifiers (IAIDs). As stated in 356 Section 9 of RFC3315, DHCPv6 servers use DUIDs to identify clients 357 for the selection of configuration parameters and in the association 358 of IAs with clients. DHCPv6 clients use DUIDs to identify a server 359 in messages where a server needs to be identified. There is now also 360 a specification for DUIDs for DHCPv4 [6]. 362 However, there are a number of potential problems with this approach: 364 o IPv4-only nodes would not have any DHCP service available to them; 365 such an approach is only possible in a fully dual-stack 366 environment. 368 o The client node may then be IPv6-only and receiving IPv4 369 configuration settings that it does not want or be able to 370 meaningfully handle. 372 o The DHCPv4 servers need to be configured anyway to support IPv4- 373 only hosts, so there is still duplication of information. 375 o What happens if there are DHCPv6 servers that don't return IPv4 376 information? Does this mean the client can't run IPv4 (since it 377 won't do DHCPv4)? 379 o If IPv4 information is served from a DHCPv6 server as well as an 380 IPv4 DHCP server, IPv4 address space will need to be allocated to 381 both servers, fragmenting the potentially precious IPv4 global 382 address resource for the site. 384 4.3 Optimising for failure with lists of addresses 386 There is a generic issue with any option that includes a list of 387 addresses of servers (such as DNS server addresses). The list is 388 offered to cater for resilience, such as whether the listed server 389 itself fails, or connectivity to the server fails. If the client 390 does not know the cause of failure, its optimal strategy is to try a 391 different server, via a different protocol. The problem today is 392 that the IPv4 list is returned via DHCPv4 and the IPv6 list via 393 DHCPv6, and the client has no way to really "try a different server", 394 since that information is lost by the protocol, even though it may be 395 known by the server. 397 Just putting merging heuristics in the client cannot provide the best 398 behaviour, since information is lost. By comparison, if IPv4-mapped 399 addresses were included in the DHCPv6 option along with IPv6 400 addresses, the DHCP server can give an intelligent order that takes 401 into account which addresses are of the same DNS/whatever server. 402 IPv6-only clients have to know to discard the IPv4-mapped addresses 403 in this solution, and it's much easier to solve this in the combined- 404 DHCP-server case than in the two-server case. 406 One can argue this is only an optimisation, and in many cases the 407 list has only two elements, so the "next" choice is forced. However, 408 this particular issue highlights the subtleties of merging responses 409 from separate servers. 411 4.4 Administrative and other areas 413 There are also administrative issues or best practice that could be 414 promoted. For example, it may be recommended that sites do not split 415 their DNS name space for IPv6-specific testbeds. 417 It may be worth considering whether separate manual configuration 418 files should be kept for IPv4 and IPv6 settings, such as separate 419 /etc/resolv.conf files for DNS settings on UNIX systems. However, 420 this seems a complex solution that should be better solved by other 421 more generalised methods. 423 It may be important at times to be able to distinguish DHCP clients 424 and server identities. DHCPv6 introduces the idea of a DHCP Unique 425 Identifier (DUID). The DUID concept has also been retrofitted to 426 DHCPv4 [6], and thus it may form the basis of part of the solution 427 space for the problem at hand. 429 Some differences in DHCP and DHCPv6 may not be reconciled, but may 430 not need to be, such as different ways to assign addresses by DUID in 431 DHCPv6, or the lack of a comparable option in both DHCP versions. 433 5. Summary 435 There are a number of issues in the operation of DHCP and DHCPv6 436 servers for nodes in dual-stack environments that should be 437 clarified. While some differences in the protocols may not be 438 reconciled, there may not be a need to do so. However, with DHCPv6 439 deployment growing, there is an operational requirement to determine 440 best practice for DHCP server provision in dual-stack environments, 441 which may or may not imply additional protocol requirements. The 442 principle operational choice is whether separate DHCP and DHCPv6 443 servers should be maintained by a site, or whether DHCPv6 should be 444 extended to carry IPv4 configuration settings for dual-stack nodes. 446 It can certainly be argued that until a site is completely dual- 447 stack, an IPv4 DHCP service will always be required (for example 448 while there are still legacy printers, IP webcams or devices which 449 still configure via DHCPv4), and a single IPv6 transport DHCP server 450 offering configuration information for both protocols will then not 451 be sufficient. In that case, IPv4 DHCP is required, and thus there 452 is a good rationale for focusing effort on how to combine the 453 information received from separate IPv4 DHCP and (stateless) DHCPv6 454 servers. 456 In theory, it should be relatively straightforward to write a 457 configuration manager that would accept a single configuration 458 specification from the service manager and distribute the correct 459 (and consistent) configurations to the DHCPv4 and DHCPv6 servers 460 (whether on the same host or not). In this case, maintaining 461 coordinated configurations in two servers is an interface issue, not 462 a protocol issue. The question then is whether the client has all 463 the information it needs to make reasonable choices. We are aware of 464 one implementation of separate DHCPv4 and DHCPv6 clients that is 465 using a preference option for assisting client-side merging of the 466 received information. 468 Another issue for discussion is whether a combined DHCP service only 469 available over IPv6 transport is a desirable longer-term goal for 470 networks containing only dual-stack or IPv6-only nodes (or IPv4-only 471 nodes where DHCPv4 is not needed). The transition to the long-term 472 position may easily take more than 10 years. 474 On reflection on the above observations, it was the strong consensus 475 of the dhc WG to adopt the two-server approach (separate DHCP and 476 DHCPv6 servers) in favour to a combined, single server returning IPv4 477 information over IPv6. The two servers may be co-located on a single 478 node, and may have consistent configuration information generated 479 from a single asset database. 481 It should be noted that deployment experience of DHCPv6 is still in 482 its infancy, thus a full understanding of the issues may only develop 483 with time, but we feel we have reached best consensus given the 484 current status. Having reached this concensus, future work is now 485 required to determine best practice for merging information from 486 multiple servers, including merger of lists of addresses where 487 options carry such information. 489 As a footnote, we note that this work has overlap with multihoming 490 and multi-interface configuration issues. It is also interwoven with 491 the Detecting Network Attachment area, for example where a node may 492 move from an IPv4-only network to a dual-stack network, or vice 493 versa. Both aspects may be best abstracted for discussion and 494 progression in the respective IETF multi6, shim6 and dna WGs, in 495 parallel with the two-server progression in the dhc WG. 497 6. IANA Considerations 499 There are no IANA considerations for this document. 501 7. Security Considerations 503 There are no security considerations in this problem statement per 504 se, as it does not propose a new protocol. 506 8. Acknowledgements 508 The authors thank the following people for input to this document: 509 Bernie Volz, AK Vijayabhaskar, Ted Lemon, Ralph Droms, Robert Elz, 510 Changming Liu, Margaret Wasserman, Dave Thaler, Mark Hollinger and 511 Greg Daley. The document may not necessarily fully reflect the views 512 of each of these individuals. 514 The authors would also like to thank colleagues on the 6NET project 515 for contributions to this document. 517 9. Informative References 519 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 520 March 1997. 522 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 523 Autoconfiguration", RFC 2462, December 1998. 525 [3] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 526 RFC 3118, June 2001. 528 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 529 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 530 RFC 3315, July 2003. 532 [5] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 533 Service for IPv6", RFC 3736, April 2004. 535 [6] Sommerfeld, B. and T. Lemon, "Node-Specific Client Identifiers 536 for DHCPv4", draft-ietf-dhc-3315id-for-v4-05 (work in progress), 537 June 2005. 539 Authors' Addresses 541 Tim Chown 542 University of Southampton 543 School of Electronics and Computer Science 544 Southampton, Hampshire SO17 1BJ 545 United Kingdom 547 Email: tjc@ecs.soton.ac.uk 549 Stig Venaas 550 UNINETT 551 Trondheim NO 7465 552 Norway 554 Email: venaas@uninett.no 555 Christian Strauf 556 Technical University of Clausthal 557 Erzstr. 51 558 Clausthal-Zellerfeld D-38678 559 Germany 561 Email: strauf@rz.tu-clausthal.de 563 Intellectual Property Statement 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed to 567 pertain to the implementation or use of the technology described in 568 this document or the extent to which any license under such rights 569 might or might not be available; nor does it represent that it has 570 made any independent effort to identify any such rights. Information 571 on the procedures with respect to rights in RFC documents can be 572 found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use of 577 such proprietary rights by implementers or users of this 578 specification can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at 585 ietf-ipr@ietf.org. 587 Disclaimer of Validity 589 This document and the information contained herein are provided on an 590 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 591 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 592 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 593 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 594 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 595 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 597 Copyright Statement 599 Copyright (C) The Internet Society (2005). This document is subject 600 to the rights, licenses and restrictions contained in BCP 78, and 601 except as set forth therein, the authors retain all their rights. 603 Acknowledgment 605 Funding for the RFC Editor function is currently provided by the 606 Internet Society.