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