idnits 2.17.1 draft-ietf-dhc-dual-stack-merge-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 6758 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 3315 (ref. '2') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '3') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '4') (Obsoleted by RFC 8415) == Outdated reference: A later version (-04) exists of draft-ietf-dhc-dual-stack-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working S. Venaas 3 Group T. Chown 4 Internet-Draft University of Southampton 5 Expires: April 27, 2006 October 24, 2005 7 Dual-stack clients and merging of data from DHCPv4 and DHCPv6 8 draft-ietf-dhc-dual-stack-merge-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 A node may have support for communications using both IPv4 and IPv6 42 protocols. Such a node may wish to obtain both IPv4 and IPv6 43 configuration settings via the Dynamic Host Configuration Protocol 44 (DHCP). This can be done by using the IPv4 and the IPv6 DHC 45 protocols respectively. This document considers mechanisms that 46 allow such a node to make use of the configuration data from both 47 protocols to obtain the desired common configuration. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Tools for merging . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1 Host prefers IPv4 or IPv6 . . . . . . . . . . . . . . . . 3 54 2.2 Dual-stack or both DHC protocols client option . . . . . . 4 55 2.3 DUID and integrated DHCPv4/v6 server . . . . . . . . . . . 4 56 2.4 DHCPv6 option telling dual-stack client to use DHCPv4 . . 4 57 2.5 IPv4-mapped addresses in DHCPv6 options . . . . . . . . . 4 58 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1 Use of preference rules . . . . . . . . . . . . . . . . . 4 60 3.2 Lists of mixed addresses . . . . . . . . . . . . . . . . . 5 61 3.3 Issues not solved . . . . . . . . . . . . . . . . . . . . 6 62 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. Informative References . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . 8 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 the 74 arrival of IPv6, a new DHCP specification for IPv6 has been designed, 75 and published as DHCPv6 [2]. 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 [3], such a node may wish to use stateless DHCPv6 [4] for other 82 administratively configured options, such as DNS or 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. At the same time there may be IPv4-only 87 and IPv6-only nodes using these protocols. Issues related to this 88 have been described in [5]. This document discusses approaches 89 towards resolving these issues. 91 This initial revision does not attempt to describe any complete 92 solutions, but rather serve as a discussion point by describing some 93 of the possible methods that may be of use. 95 In this document, we refer to DHCP for IPv4 [1] as DHCPv4 and DHCP 96 for IPv6 [2] as DHCPv6. 98 The authgors would welcome input on these approaches. 100 2. Tools for merging 102 There are a number of different tools or methods that can be of use 103 in ensuring that IPv4-only, IPv6-only and dual-stack hosts each get 104 the information they need from DHCPv4, DHCPv6 or a combination of the 105 two. 107 2.1 Host prefers IPv4 or IPv6 109 The idea with a preference option of some kind is that a dual-stack 110 host may obtain information from both DHCPv4 and DHCPv6 but will 111 prefer one of them. So if a single valued option is received from 112 both servers it can use the preferred one. For a set (or unordered 113 list) it might use only the preferred result or mix them, while for 114 an ordered list it should probably use all, but put the preferred 115 first. The preference could be manually configured on the host or 116 obtained via either DHCPv4 or DHCPv6. The option would only be 117 needed for one of them. 119 2.2 Dual-stack or both DHC protocols client option 121 A host could use a new DHCP option to tell the DHCP server (DHCPv4 or 122 DHCPv6) that it is dual-stack and has or will request configuration 123 for the other protocol. This can indicate to the server what 124 information the server needs to return to the client. 126 2.3 DUID and integrated DHCPv4/v6 server 128 DHCPv6 [2] uses a DHCP Unique Identifier (DUID). A client requesting 129 both IPv4 and IPv6, should use the same DUID for the two requests, as 130 described in [6] for use of DUIDs with IPv4. If the client requests 131 DHCPv4 first, then when it makes the DHCPv6 request, the server knows 132 what information the client previously learnt through DHCPv4 from the 133 observed DUID and could leave the duplicate information out from the 134 DHCPv6 reply. We are not sure whether this can be done if multiple 135 integrated servers are deployed, but it seems an interesting 136 approach, and a good usage for DUIDs for IPv4. 138 2.4 DHCPv6 option telling dual-stack client to use DHCPv4 140 A new option could be used by a DHCPv6 server to tell a dual-stack 141 client to request IPv4 information even if it has IPv4 addresses 142 (tell client to use DHCPINFORM). 144 2.5 IPv4-mapped addresses in DHCPv6 options 146 DHCPv6 options could contain IPv4 addresses written as IPv4-mapped 147 IPv6 addresses. This is not elegant, however. 149 3. Solutions 151 We will now discuss how the above tools might be used to solve some 152 of the issues in [5]. 154 3.1 Use of preference rules 156 A simple preference rule as in Section 2.1 might be sufficient in 157 many cases. The perhaps most difficult problem is where the option 158 is a list of values, and one wishes to have a mix of IPv4 and IPv6 159 addresses where one does not want to list all of one IP type before 160 the other, or if one is preferred to the other in most cases but not 161 always. Lists of mixed addresses are discussed in Section 3.2. 163 Another solution could be to use FQDNs as option values whenever 164 possible. Then DHCPv4 and DHCPv6 might simply specify the same FQDN 165 where the FQDN is registered in the DNS with both IPv4 and IPv6 166 addresses. The preference would then be determined by the host's 167 destination address selection rules. Some sites deploying IPv6 168 choose initially to use different FQDNs for IPv6, in which case this 169 would not work. 171 The preference rule is not sufficient if say IPv6 is generally 172 preferred, but IPv4 should preferred in some cases. One way of doing 173 this could be to have the client prefer IPv6 and make the DHCPv6 174 server omit IPv6 information for options where IPv4 is preferred. 175 The server could do this if by use of the option in Section 2.2 it 176 knows that the client will also get the IPv4 information. An IPv6- 177 only client, or one not requesting IPv4 configuration, should still 178 get all the IPv6 options. The administrator may manually configure a 179 DHCPv6 server to omit some of the IPv6 configuration for clients that 180 also obtain IPv4 information. A combined DHCPv4 and DHCPv6 server 181 might be able to determine this automatically. With different 182 servers it might help to have a single combined admin interface. 184 One issue with the above is that the server must only omit options if 185 it knows for sure that client will request and successfully obtain 186 both IPv4 and IPv6 information. There are two ways this might be 187 done. One is that the server is told by the client that it uses 188 both, by using the option in Section 2.2, possibly combined with the 189 option in Section 2.4 where the server tells the client to request 190 the other. Another possibly safer way is to make use of the DUID as 191 in Section 2.3 so that server knows that the client that previously 192 made a DHCPv6 request, now makes a DHCPv4 request. The latter should 193 work if a client generally prefering one protocol, uses DHCP for the 194 preferred protocol last. We feel the DUID approach is an elegant 195 one, and is a good use of the DUID concept that is now available for 196 both DHCPv4 and DHCPv6. 198 3.2 Lists of mixed addresses 200 As we said previously, the most difficult problem is when one has a 201 list of values, and one wishes to have a mix of IPv4 and IPv6 202 addresses where one does not want to list all of one IP type before 203 the other. We are not sure if this is necessary to solve. If it is, 204 the easiest solution might be to use IPv4-mapped addresses as in 205 Section 2.5 so that a mixed list of IPv4-mapped IPv6 addresses and 206 other IPv6 addresses can be passed in a DHCPv6 option. If this is 207 done it might be useful to have an option as described in Section 2.2 208 that tells the server that the client is dual-stack. This is not 209 elegant however, and one should certainly not pass mapped addresses 210 to an IPv6-only host. 212 Another issue with using a simple preference for lists, is that if a 213 server is dual-stack with both IPv4 and IPv6 addresses, one may not 214 wish to have both the addresses in the list. For example, if one has 215 a nameserver with IPv4 address a4 and IPv6 address a6, and another 216 with IPv4 address b4, one may not want the list "a6, a4, b4", but 217 rather "a6, b4". Whether this is a problem may depend on whether the 218 list is processed sequentially and how long timeout there is before 219 trying the next in the list. If an integrated DHCPv4 and DHCPv6 220 server knows that a client has previously got the list "a6" via say 221 DHCPv6, it could choose to omit "a4" when the same client makes a 222 DHCPv4 query. It can detect that it is the same client using the 223 DUID as in Section 2.3. However if there are multiple integrated 224 servers the two requests may go to different servers. Another 225 alternative could be to use the option in Section 2.2. 227 3.3 Issues not solved 229 There are many issues in [5] that are not tackled by the above. We 230 have not looked at the issue of different people managing DHCPv4 and 231 DHCPv6 or the case where the node is statically configured with 232 information for one protocol while using DHCP for the other. Another 233 issue is what to do when initially only one IP protocol is enabled, 234 and the other is enabled later. There are other issues not 235 sufficiently tackled as well, we suggest reading [5] for the full 236 details. The methods presented here are just some preliminary ideas. 237 Through discussion in the DHC WG we will try to come up with 238 solutions that can resolve the issues. It may however not be 239 possible to come up with a complete solution to all of them. 241 3.4 Conclusion 243 We have proposed some initial ideas for solving the issue of merging 244 DHCP information available from DHCPv4 and DHCPv6 servers to IPv4- 245 only, IPv6-only or dual-stack nodes. We would welcome feedback on 246 these initial suggestions before progressing the document in more 247 detail, and tackling the additional issues described in the problem 248 statement draft. There are certainly useful tools for the task, in 249 particular DUID identifiers now available for DHCPv4 and DHCPv6. 251 4. IANA Considerations 253 This document has no actions for IANA. 255 5. Security Considerations 257 We are not aware of any new security issues as a result of any of the 258 described options, but this needs to be considered. 260 6. Informative References 262 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 263 March 1997. 265 [2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 266 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 267 RFC 3315, July 2003. 269 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 270 Autoconfiguration", RFC 2462, December 1998. 272 [4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 273 Service for IPv6", RFC 3736, April 2004. 275 [5] Chown, T., "DHCP: IPv4 and IPv6 Dual-Stack Issues", 276 draft-ietf-dhc-dual-stack-03 (work in progress), July 2005. 278 [6] Sommerfeld, B. and T. Lemon, "Node-Specific Client Identifiers 279 for DHCPv4", draft-ietf-dhc-3315id-for-v4-05 (work in progress), 280 June 2005. 282 Authors' Addresses 284 Stig Venaas 285 University of Southampton 286 School of Electronics and Computer Science 287 Southampton, Hampshire SO17 1BJ 288 United Kingdom 290 Email: sv@ecs.soton.ac.uk 292 Tim Chown 293 University of Southampton 294 School of Electronics and Computer Science 295 Southampton, Hampshire SO17 1BJ 296 United Kingdom 298 Email: tjc@ecs.soton.ac.uk 300 Intellectual Property Statement 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed to 304 pertain to the implementation or use of the technology described in 305 this document or the extent to which any license under such rights 306 might or might not be available; nor does it represent that it has 307 made any independent effort to identify any such rights. Information 308 on the procedures with respect to rights in RFC documents can be 309 found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use of 314 such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository at 316 http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at 322 ietf-ipr@ietf.org. 324 Disclaimer of Validity 326 This document and the information contained herein are provided on an 327 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 328 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 329 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 330 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 331 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 332 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 334 Copyright Statement 336 Copyright (C) The Internet Society (2005). This document is subject 337 to the rights, licenses and restrictions contained in BCP 78, and 338 except as set forth therein, the authors retain all their rights. 340 Acknowledgment 342 Funding for the RFC Editor function is currently provided by the 343 Internet Society.