Internet Engineering Task Force S. Venaas Internet Draft University of Southampton Expiration Date: January 2006 T. Chown University of Southampton July 2005 Dual-stack clients and merging of data from DHCPv4 and DHCPv6 draft-venaas-dhc-dual-stack-merge-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract A node may have support for communications using both IPv4 and IPv6 protocols. Such a node may wish to obtain both IPv4 and IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). This can be done by using the IPv4 and the IPv6 DHC protocols respectively. This document considers mechanisms that allow such a node to make use of the configuration data from both Venaas & Chown [Expires January 2006] [Page 1] Internet Draft draft-venaas-dhc-dual-stack-merge-00.txt July 2005 protocols to obtain the desired common configuration. Table of Contents 1. Introduction ............................................... 2 2. Tools for merging .......................................... 3 2.1. Host prefers IPv4 or IPv6 .............................. 3 2.2. Dual-stack or both DHC protocols client option ......... 3 2.3. DUID and integrated DHCPv4/v6 server ................... 3 2.4. DHCPv6 option telling dual-stack client to use DHCPv4 .. 4 2.5. IPv4-mapped addresses in DHCPv6 options ................ 4 3. Solutions .................................................. 4 3.1. Use of preference rules ................................ 4 3.2. Lists of mixed addresses ............................... 5 3.3. Issues not solved ...................................... 6 4. Security Considerations .................................... 6 5. Informative References ..................................... 6 Authors' Addresses ............................................. 7 Intellectual Property and Copyright Statements ................. 7 1. Introduction The original specification of the Dynamic Host Configuration Protocol (DHCP) was made with only IPv4 in mind. That specification has been ubsequently revised, up to the latest version of DHCP [RFC 2131]. With the arrival of IPv6, a new DHCP specification for IPv6 has been designed, and published as DHCPv6 [RFC 3315]. These protocols allow nodes to communicate via IPv4 or IPv6 to retrieve configuration settings for operation in a managed environment. While an IPv6 node may acquire address-related configuration settings via IPv6 stateless address autoconfiguration [RFC 2462], such a node may wish to use stateless DHCPv6 [RFC 3736] for other administratively configured options, such as DNS or NTP. In early IPv6 deployments, a dual-stack mode of operation is typically used. There will thus be nodes that require both IPv4 and IPv6 configuration settings. At the same time there may be IPv4-only and IPv6-only nodes using these protocols. Issues related to this have been described in [ISSUES]. This document discusses how to resolve these issues. Venaas & Chown [Expires January 2006] [Page 2] Internet Draft draft-venaas-dhc-dual-stack-merge-00.txt July 2005 This initial revision does not attempt to describe any complete solutions, but rather serve as a discussion point by describing some of the possible methods that may be of use. In this document, we refer to DHCP for IPv4 [1] as DHCPv4 and DHCP for IPv6 [RFC 3315] as DHCPv6. 2. Tools for merging There are a number of different tools or methods that can be of use in ensuring that IPv4-only, IPv6-only and dual-stack hosts each get the info they need from DHCP4, DHCPv6 or a combination of the two. 2.1. Host prefers IPv4 or IPv6 The idea is that a dual-stack host may obtain information from both DHCPv4 and DHCPv6 but will prefer one of them. So if a single valued option is received from both it can use the preferred one. For a set (or unordered list) it might use only the preferred or mix them, while for an ordered list it should probably use all, but put the preferred first. The preference could be manually configured on the host or obtained via either DHCPv4 or DHCPv6. The option would only be needed for one of them. 2.2. Dual-stack or both DHC protocols client option Host could use a new DHCP option to tell DHCP server (v4 or v6) that it is dual-stack and have or will request configuration for the other protocol. This can indicate to the server what information it needs to return to the client. 2.3. DUID and integrated DHCPv4/v6 server DHCPv6 [RFC 3315] uses a DHCP Unique Identifier (DUID). A client requesting both IPv4 and IPv6, should use the same DUID for the two requests, see [3315IDV4] for using DUID with IPv4. If e.g. client requests DHCPv4 first, then when it makes the DHCPv6 request, the server knows what info the client previously learnt through DHCPv4 and can leave that out from the DHCPv6 reply. We are not sure whether this can be done if multiple integrated servers are deployed. Venaas & Chown [Expires January 2006] [Page 3] Internet Draft draft-venaas-dhc-dual-stack-merge-00.txt July 2005 2.4. DHCPv6 option telling dual-stack client to use DHCPv4 A new option could be used by DHCPv6 server to tell a dual-stack client to request IPv4 information even if it has IPv4 addresses (tells client to use DHCPINFORM). 2.5. IPv4-mapped addresses in DHCPv6 options DHCPv6 options could contain IPv4 addresses written as IPv4-mapped IPv6 addresses. 3. Solutions We will now discuss how the above tools might be used to solve some of the issues in [ISSUES]. 3.1. Use of preference rules A simple preference rule as in 2.1 might be sufficient in many cases. The perhaps most difficult problem is where the option is a list of values, and one wishes to have a mix of IPv4 and IPv6 addresses where one does not want to list all of one IP type before the other, or if one is preferred to the other in most cases but not always. Lists of mixed addresses are discussed in the next section. Another solution could be to use FQDNs as option values whenever possible. Then DHCPv4 and DHCPv6 might simply specify the same FQDN where the fqdn is registered in the DNS with both IPv4 and IPv6 addresses. The preference would then be determined by the host's destination address selection rules. Some sites deploying IPv6 choose initially to use different FQDNs for IPv6, in which case this would not work. The preference rule is not sufficient if say IPv6 is generally preferred, but IPv4 should preferred in some cases. One way of doing this, could be to have client prefer IPv6, and make the DHCPv6 server omit IPv6 info for options where IPv4 is preferred. The server could do this if by use of 2.2 it knows that the client also will get the IPv4 information. An IPv6-only client, or one not requesting IPv4 configuration, should still get all the IPv6 options. The administrator may manually configure a DHCPv6 server to omit some IPv6 config for clients that also obtain IPv4 information. A combined DHCPv4 and DHCPv6 server might be able to determine this automatically. With different servers it might help to have a single combined admin interface. Venaas & Chown [Expires January 2006] [Page 4] Internet Draft draft-venaas-dhc-dual-stack-merge-00.txt July 2005 One issue with the above is that the server must only omit options if it knows for sure that client will request and successfully obtain both IPv4 and IPv6 information. There are two ways this might be done. One is that server is told by client that it uses both (2.2), possibly combined with 2.4 where server tells client to request the other. Another possibly safer way is to make use of the DUID (2.3) so that server knows that the client that previously made a DHCPv6 request, now makes a DHCPv4 request. The latter should work if a client generally prefering one protocol, uses DHCP for the preferred protocol last. 3.2. Lists of mixed addresses As we said previously, the most difficult problem is when one has a list of values, and one wishes to have a mix of IPv4 and IPv6 addresses where one does not want to list all of one IP type before the other. We are not sure if this is necessary to solve. If it is, the easiest solution might be to use IPv4-mapped addresses as in 2.5, so that a mixed list of IPv4-mapped IPv6 addresses and other IPv6 addresses can be passed in a DHCPv6 option. If this is done it might be useful to have an option as described in 2.2 that tells the server that the client is dual-stack. One should not pass mapped addresses to an IPv6-only host. Another way of solving this would be to somehow leave holes in the IPv6 list, using some special IPv6 address to indicate where the IPv4 addresses returned from DHCPv4 should be placed in the list. We don't think this is a good solution, but it could be done provided the server knows client will or has asked for DHCPv4 information, and that it knows what IPv4 info the client has or will be given. Another issue with using a simple preference for lists, is that if a server is dual-stack with both IPv4 and IPv6 addresses, one may not wish to have both the addresses in the list. E.g. if one has a nameserver with IPv4 address a4 and IPv6 address a6, and another with IPv4 address b4, one may not want the list "a6, a4, b4", but rather "a6, b4". Whether this is a problem may depend on whether the list is processed sequentially and how long timeout there is before trying the next in the list. If an integrated DHCPv4 and DHCPv6 server knows that a client has previously got the list "a6" via say DHCPv6, it could choose to omit "a4" when the same client makes a DHCPv4 query. It can detect that it is the same client using DUID as in 2.3. However if there are multiple integrated servers the two requests may go to different servers. Another alternative could be to use the option in 2.2. Venaas & Chown [Expires January 2006] [Page 5] Internet Draft draft-venaas-dhc-dual-stack-merge-00.txt July 2005 3.3. Issues not solved There are many issues in [ISSUES] that are not tackled by the above. We have not looked at the issue of different people managing DHCP4 and DHCPv6 or the case where the node is statically configured with information for one protocol while using DHCP for the other. Another issue is what to do when initially only one IP protocol is enabled, and the other is enabled later. There are other issues not sufficiently tackled as well, we suggest reading [ISSUES] for the full details. The methods presented here are just some preliminary ideas. Through discussion in the DHC WG we will try to come up with solutions that can resolve the issues. It may however not be possible to come up with a complete solution to all of them. 4. Security Considerations We are not aware of any new security issues as a result of any of the described options, but this needs to be considered. 5. Informative References [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC 3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC 3736] R. Droms, "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [ISSUES] T. Chown, S. Venaas, C. Strauf, "DHCP: IPv4 and IPv6 Dual-Stack Issues", work-in-progress, draft-ietf-dhc-dual-stack-03, July 2005. [3315IDV4] T. Lemon, B. Sommerfeld, "Node-Specific Client Identifiers for DHCPv4", work-in-progress, draft-ietf-dhc-3315id-for-v4-04.txt, February 2005. Venaas & Chown [Expires January 2006] [Page 6] Internet Draft draft-venaas-dhc-dual-stack-merge-00.txt July 2005 Authors' Addresses Stig Venaas University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom EMail: sv@ecs.soton.ac.uk Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE Venaas & Chown [Expires January 2006] [Page 7] Internet Draft draft-venaas-dhc-dual-stack-merge-00.txt July 2005 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Venaas & Chown [Expires January 2006] [Page 8]