idnits 2.17.00 (12 Aug 2021) /tmp/idnits42271/draft-chown-dhc-dual-stack-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 (February 9, 2004) is 6669 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 normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (ref. '4') (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-dhc-dhcpv6-stateless has been published as RFC 3736 == Outdated reference: draft-ietf-dhc-3315id-for-v4 has been published as RFC 4361 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Dynamic Host Congiguration T. Chown 2 Internet-Draft University of Southampton 3 Expires: August 9, 2004 S. Venaas 4 UNINETT 5 C. Strauf 6 JOIN (University of Muenster) 7 February 9, 2004 9 IPv4 and IPv6 Dual-Stack Issues for DHCPv6 10 draft-chown-dhc-dual-stack-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 9, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 A node may have support for communications using IPv4 and/or IPv6 41 protocols. Such a node may wish to obtain IPv4 and/or IPv6 42 configuration settings via the Dynamic Host Configuration Protocol 43 (DHCP). The original version of DHCP [1] designed for IPv4 has now 44 been complemented by a new DHCPv6 [4] for IPv6. This document 45 describes issues identified with dual IP version DHCP interactions. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Configuration scenarios . . . . . . . . . . . . . . . . . . . 3 51 3. Dual-stack issues . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1 Handling multiple responses . . . . . . . . . . . . . . . . . 4 53 3.2 Multiple interfaces . . . . . . . . . . . . . . . . . . . . . 4 54 3.3 DNS load balancing . . . . . . . . . . . . . . . . . . . . . . 5 55 3.4 DNS search path issues . . . . . . . . . . . . . . . . . . . . 5 56 3.5 Administrative management . . . . . . . . . . . . . . . . . . 5 57 3.6 DHCP option variations . . . . . . . . . . . . . . . . . . . . 5 58 3.7 Security issues . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Potential solutions . . . . . . . . . . . . . . . . . . . . . 6 60 4.1 Separate DHCP servers . . . . . . . . . . . . . . . . . . . . 6 61 4.2 Single DHCPv6 server . . . . . . . . . . . . . . . . . . . . . 6 62 4.3 Administrative and other areas . . . . . . . . . . . . . . . . 7 63 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 Normative References . . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 67 Intellectual Property and Copyright Statements . . . . . . . . 9 69 1. Introduction 71 The original specification of the Dynamic Host Configuration Protocol 72 (DHCP) was made with only IPv4 in mind. That specification has been 73 subsequently revised, up to the latest version of DHCP [1]. With 74 the arrival of IPv6, a new DHCP specification for IPv6 has been 75 designed, and published as DHCPv6 [4]. 77 These protocols allow nodes to communicate via IPv4 or IPv6 to 78 retrieve configuration settings for operation in a managed 79 environment. While an IPv6 node may acquire address-related 80 configuration settings via IPv6 stateless address autoconfiguration 81 [2], such a node may wish to use stateless DHCPv6 [5] for other 82 administratively configured options (e.g. DNS, NTP). 84 In early IPv6 deployments, a dual-stack mode of operation is 85 typically used. There will thus be nodes that require both IPv4 and 86 IPv6 configuration settings. This document discusses issues with 87 obtaining such settings in a dual-stack environment. 89 In this document, we refer to a "DHCP server" as a server 90 implementing the original DHCP [1], and a "DHCPv6 server" as a server 91 implementing DHCPv6 [4] or its stateless subset. 93 2. Configuration scenarios 95 For a node in an IPv4-only or IPv6-only environment, the choice of 96 DHCP server is a straightforward one; a DHCP server for IPv4, or a 97 DHCPv6 server for IPv6. 99 In a dual-stack environment a node in a managed environment will need 100 to obtain both IPv4 and IPv6 configuration settings, e.g. 102 o IPv4 address 104 o IPv6 address 106 o NTP server 108 o DNS server 110 o NIS server 112 o DNS search path 114 While the format of address settings will be IP-specific, the node 115 may equally well acquire IPv4 or IPv6 addresses for some settings, 116 e.g. for DNS or NTP, if those services are available via IPv4 or IPv6 117 transport. Currently, a DHCP server returns IPv4 data, while a 118 DHCPv6 server returns IPv6 data. 120 It is worth noting that in an IPv4 environment, with a DHCP server, 121 the choice of whether to use DHCP is made by the node. In an IPv6 122 environment, the use of the managed and other bits in the Router 123 Advertisement can tell the node whether or not to use DHCPv6. It is 124 perhaps not clear whether a dual-stack node should do DHCP for IPv4 125 if Managed and OtherConfig flags in the Router Advertisement are both 126 off; it seems most appropriate that the decision to use DHCP for IPv4 127 or not should be as if the host was IPv4-only. 129 3. Dual-stack issues 131 In this section we list issues that have been raised to date related 132 to dual-stack DHCP operation. 134 3.1 Handling multiple responses 136 The general question is how to handle configuration information that 137 may be gathered from multiple sources. Where those sources are DHCP 138 and DHCPv6 servers (which may be two physical nodes or two servers 139 running on the same node) the client node needs to know whether to 140 use the most recent data, or whether to perform some merger or union 141 of the responses by certain rules. A node may choose to ask a DHCPv6 142 server and only use a DHCP server if no response is received. 144 Merging is possible, but is likely to be complex. There could be 145 some priority, so that if both DHCP and DHCPv6 servers offer a value, 146 only one is used. Or the node could choose to store and use both, 147 in some order of its choosing. 149 A node may also obtain information from other sources, e.g. a manual 150 configuration file (e.g. /etc/resolv.conf for DNS data on many Unix 151 systems). A node configured manually to use an IPv6 DNS server via 152 such manual configuration may lose that configuration if it then uses 153 DHCP to obtain IPv4 settings if in a dual-stack environment; that 154 IPv4 configuration may then overwrite the manual IPv6 DNS setting 155 with new IPv4 settings from the DHCP response. 157 3.2 Multiple interfaces 159 A node may have multiple interfaces and run IPv4 and IPv6 on 160 different interfaces. A question then is whether the settings are 161 per interface or per node? DHCPv6 introduces the idea of a DHCP 162 Unique Indentifer (DUID) which does not yet exist for DHCP; some 163 effort is being made to retrofit the concept to DHCP [6]. 165 Per interface settings can be complex because a client node needs to 166 know from which interface system settings like NTP server came from. 167 And it may not be apparent which setting should be used, if e.g. an 168 NTP server option is received on multiple interfaces, potentially 169 over different protocols. 171 3.3 DNS load balancing 173 In some cases it is preferable to list DNS server information in an 174 ordered way per node for load balancing, giving different responses 175 to different clients. Responses from different DHCP and DHCPv6 176 servers may make such configuration problematic. 178 3.4 DNS search path issues 180 The DNS search path may vary for administrative reasons. For 181 example, a site under the domain foo.com chooses to place an early 182 IPv6 deployment under the subdomain ipv6.foo.com, until it is 183 confident of offering a full dual-stack service under its main 184 domain. The subtlety here is that the DNS search path then affects 185 choice of protocol used, e.g. IPv6 for nodes in ipv6.foo.com. 187 3.5 Administrative management 189 In some deployments, the IPv4 and IPv6 services may not be 190 administered by the same organisation or people, e.g. in a community 191 wireless environment. This poses problems for consistency of data 192 offered by either DHCP version. 194 3.6 DHCP option variations 196 Some options in DHCP are not available in DHCPv6 and vice-versa. Some 197 IP-version limitations naturally apply, e.g. only IPv6 addresses can 198 be in an IPv6 NTP option. The DHCP and DHCPv6 option numbers may be 199 different. 201 A site administrator may wish to configure all their dual-stack nodes 202 with (say) two NTP servers, one of which has an IPv4 address, the 203 other an IPv6 address. In this case it may be desirable for an NTP 204 option to carry a list of addresses, where some may be IPv4 and some 205 may be IPv6. In general one could consider having DHCPv6 options 206 that can carry mix of IPv4 and IPv6 addresses. 208 3.7 Security issues 210 At this stage in the formation of this draft no specific security 211 issues have been raised. The authors welcome comments on this, 212 should such issues exist. 214 While there is a specification for authentiation for DHCP messages 215 [3], the standard seems to have very few, if any, implementations. 216 Thus DHCP and DHCPv6 servers are still liable to be spoofed. Adding 217 an additional protocol may give an extra avenue for attack, should an 218 attacker perhaps spoof a DHCPv6 server but not a DHCP server. 220 4. Potential solutions 222 While this document did not originally intend to have solutions in 223 its scope, we discuss potential solution spaces in brief here in 224 order to provoke some discussion of the issues. If separate 225 solution document(s) emerge, these notes may be removed from this 226 document; alternatively this document could be expanded to become a 227 best practice guide. Comments on this are welcomed. 229 4.1 Separate DHCP servers 231 One solution is to run separate DHCP and DHCPv6 servers. These may 232 or may not be run on the same physical node. 234 In this approach, some best practice guidance is required for how 235 multiple responses are handled or merged. Administrators have the 236 onus to maintain consistency (e.g. scripts may generate common DHCP 237 and DHCPv6 configuration files). 239 In some cases, inconsistencies may not matter. In a simple case, an 240 NTP server will give the same time whether accessed by IPv4 or IPv6. 241 Even if different recursive DNS servers are offered via DHCP or 242 DHCPv6, those name servers will provide the same response to a given 243 query. The order of DNS servers in a node's configuration is not 244 important, unless DNS load balancing is required. 246 In the case of separate servers, there are some options like DNS 247 search path, that aren't used in a specific IP protocol context. 249 It is worth noting that there has been little effort to date to agree 250 a common method for IPv6 nodes to acquire non-address settings via 251 DHCPv6 because in most dual-stack environments a node will acquire 252 its DNS settings via DHCP and query a local (perhaps dual-stack) 253 resolver. 255 4.2 Single DHCPv6 server 257 There is an argument for not having to configure and operate both 258 DHCP and DHCPv6 servers. The use of both servers may also lead to 259 some redundancy in the information served. Thus one solution may be 260 to modify DHCPv6 to be able to return IPv4 information. This 261 solution is hinted at in the DHCPv6 [4] specification: "If there is 262 sufficient interest and demand, integration can be specified in a 263 document that extends DHCPv6 to carry IPv4 addresses and 264 configuration information." This solution may allow DHCP for IPv4 to 265 be completely replaced by DHCPv6 with additional IPv4 information 266 options, for dual-stack nodes. 268 This approach may require the listing of a mix of IPv4 and IPv6 269 addresses for an option. This should be considered when new IPv6 270 options are introduced. 272 One problem with this approach is that the client node may then be 273 IPv6-only and receiving IPv4 configuration settings that it does not 274 want or be able to meaningfully handle. 276 4.3 Administrative and other areas 278 There are also administrative issues or best practice that could be 279 promoted. For example, it may be recommended that sites do not 280 split their DNS name space for IPv6-specific testbeds. 282 It may be worth considering whether separate manual configuration 283 files should be kept for IPv4 and IPv6 settings, e.g. separate /etc/ 284 resolv.conf files for DNS settings on Unix systems. However, this 285 seems a complex solution that should be better solved by other more 286 generalised methods. 288 Some differences in DHCP and DHCPv6 may not be reconciled, but may 289 not need to be, e.g. different ways to assign addresses by DUID in 290 DHCPv6, or the non-aligned option numbers for DHCP and DHCPv6. 292 5. Summary 294 There are a number of issues in the operation of DHCP and DHCPv6 295 servers for nodes in dual-stack environments that should be 296 clarified. While some differences in the protocols may not be 297 reconciled, there may not be a need to do so. However, for general 298 operation some best practice should be agreed, the principle choice 299 being whether separate DHCP and DHCPv6 servers should be maintained 300 by a site, or whether DHCPv6 should be extended to carry IPv4 301 configuration settings for dual-stack nodes. 303 6. Security Considerations 305 There are no security considerations in this problem statemement per 306 se, as it does not propose a new protocol. 308 Normative References 310 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 311 March 1997. 313 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 314 Autoconfiguration", RFC 2462, December 1998. 316 [3] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 317 RFC 3118, June 2001. 319 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 320 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 321 RFC 3315, July 2003. 323 [5] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", 324 draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October 325 2003. 327 [6] Lemon, T., "Node-Specific Client Identifiers for DHCPv4", 328 draft-ietf-dhc-3315id-for-v4-00 (work in progress), October 329 2003. 331 Authors' Addresses 333 Tim Chown 334 University of Southampton 335 School of Electronics and Computer Science 336 Southampton, Hampshire SO17 1BJ 337 United Kingdom 339 EMail: tjc@ecs.soton.ac.uk 341 Stig Venaas 342 UNINETT 343 Trondheim NO 7465 344 Norway 346 EMail: venaas@uninett.no 348 Christian Strauf 349 JOIN (University of Muenster) 350 Roentgenstr. 9-13 351 Muenster D-48149 352 Germany 354 EMail: strauf@uni-muenster.de 356 Intellectual Property Statement 358 The IETF takes no position regarding the validity or scope of any 359 intellectual property or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; neither does it represent that it 363 has made any effort to identify any such rights. Information on the 364 IETF's procedures with respect to rights in standards-track and 365 standards-related documentation can be found in BCP-11. Copies of 366 claims of rights made available for publication and any assurances of 367 licenses to be made available, or the result of an attempt made to 368 obtain a general license or permission for the use of such 369 proprietary rights by implementors or users of this specification can 370 be obtained from the IETF Secretariat. 372 The IETF invites any interested party to bring to its attention any 373 copyrights, patents or patent applications, or other proprietary 374 rights which may cover technology that may be required to practice 375 this standard. Please address the information to the IETF Executive 376 Director. 378 Full Copyright Statement 380 Copyright (C) The Internet Society (2004). All Rights Reserved. 382 This document and translations of it may be copied and furnished to 383 others, and derivative works that comment on or otherwise explain it 384 or assist in its implementation may be prepared, copied, published 385 and distributed, in whole or in part, without restriction of any 386 kind, provided that the above copyright notice and this paragraph are 387 included on all such copies and derivative works. However, this 388 document itself may not be modified in any way, such as by removing 389 the copyright notice or references to the Internet Society or other 390 Internet organizations, except as needed for the purpose of 391 developing Internet standards in which case the procedures for 392 copyrights defined in the Internet Standards process must be 393 followed, or as required to translate it into languages other than 394 English. 396 The limited permissions granted above are perpetual and will not be 397 revoked by the Internet Society or its successors or assignees. 399 This document and the information contained herein is provided on an 400 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 401 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 402 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 403 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 404 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 Acknowledgment 408 Funding for the RFC Editor function is currently provided by the 409 Internet Society.