V6OPS B. Liu Internet-Draft Huawei Technologies Intended status: Informational R. Bonica Expires: January 22, 2015 Juniper Networks T. Yang China Mobile July 21, 2014 DHCPv6/SLAAC Address Configuration Interaction Problem Statement draft-liu-v6ops-dhcpv6-slaac-guidance-02 Abstract ND and DHCPv6 protocols could have some interaction on address provisioning with the A, M, and O flags defined in ND protocol. But the relevant standard definitions of the flags contain ambiguity, so that current implementations in operating systems have varied on interpreting the flags. The variation might impact real network operations, so this document aims to provide some operational guidance to eliminate the impact as much as possible. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 22, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Liu, et al. Expires January 22, 2015 [Page 1] Internet-Draft DHCPv6/SLAAC Interaction Guidance July 2014 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problems Summary . . . . . . . . . . . . . . . . . . . . . . 2 3. Operational Guidance . . . . . . . . . . . . . . . . . . . . 3 3.1. General Guidance . . . . . . . . . . . . . . . . . . . . 4 3.2. Guidance for DHCPv6-only Deployment . . . . . . . . . . . 4 3.3. Guidance for SLAAC-only Deployment . . . . . . . . . . . 5 3.4. Guidance for DHCPv6/SLAAC Co-existence Deployment . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In draft [I-D.ietf-v6ops-dhcpv6-slaac-problem], the DHCPv6/SLAAC [RFC3315] [RFC4862] interaction issues on host were reported. More specifically, the interaction is regarding with the A, M, and O flags which are defined in ND protocol. Test results have identified that current implementations in operating systems have varied on interpreting the flags. The variation might cause some operational problems as described in the document. Given the fact that the above mentioned issues might impact real network operations, this document aims to provide some operational guidance to eliminate the impact as much as possible. This document either doesn not intent to cover the topic of selection between RA and DHCPv6 for the overlapped functions. There always are arguments about what should be done through RA options or through DHCPv6 options. For this general issue, draft [I-D.yourtchenko-ra-dhcpv6-comparison] could be referred. 2. Problems Summary The main problem described in [I-D.ietf-v6ops-dhcpv6-slaac-problem] is standard definition ambiguity, which means, on interpreting the same messages, different hosts might behave differently. Thus it Liu, et al. Expires January 22, 2015 [Page 2] Internet-Draft DHCPv6/SLAAC Interaction Guidance July 2014 could be un-controlled or un-predictable for administrators on some operations. The ambiguity is summarized as the following aspects. 1. Dependency between DHCPv6 and RA In standards, behavior of DHCPv6 and Neighbor Discovery protocols is specified respectively. But it is not clear that whether there should be any dependency between them. More specifically, is RA (with M=1) required to trigger DHCPv6? If there are no RAs at all, should hosts initiate DHCPv6 by themselves? 2. Advisory VS Prescriptive Some platforms interpret the flags as advisory while others interpret them prescriptive. Especially when flags are in transition, e.g. the host is already SLAAC-configured, then M flag transition from 0 to 1, it is not clear whether the host should start DHCPv6 or not; or vise versa, the host is already both SLAAC/DHCPv6 configured, then A flag transitions from 0 to 1, it is also not clear whether the host should turn DHCPv6 off or not. 3. Address Configuring Method VS Address Lifetime When one address configuration method is off, that is, the A flag or M flag changes from TRUE to FALSE, it is not clear whether the host should immediately release the corresponding address(es) or just retain it(them) until expired. 4. Dependencies between the flags The semantics of the flags seems not totally independent, but the standards didn't clearly clarify it. For example, when M=1 & O=1, it is not clear whether the host should initial one stateful DHCPv6 session to get both address and info- configuration or initial two independent sessions of which one is dedicated for address provisioning and the other is for information provision. When A=0 & M=0 & O=1, it is not clear whether the host should initiate a stand-alone stateless DHCPv6 session 3. Operational Guidance Liu, et al. Expires January 22, 2015 [Page 3] Internet-Draft DHCPv6/SLAAC Interaction Guidance July 2014 3.1. General Guidance - Always Turn RAs On Currently, turning RAs on is actually a basic requirement for running IPv6 networks since only RAs could advertise default route(s) for the end nodes. And if the nodes want to communicate with each other on the same link via DHCPv6-configured addresses, they also need to be advertised with L flag set in RAs. So for current networks, an IPv6 network could not run without RAs, unless the network only demands a communication via link-local addresses. - DHCPv6/SLAAC Co-existence is a Safe Way to Guarantee Address Provisioning As specified in [RFC6434], SLAAC is a mandatory function for an IPv6 node while DHCPv6 is not. So every node could always get a prefix if RAs with PIO (Prefix Information Option) are available. However, there might be corner cases that one host might be mistakenly configured as DHCPv6-only configuration, thus if the administrators want to make sure every node could at least get one global address, DHCPv6/SLAAC is a safe way. Nevertheless, the co-existence might only be a safe way rather tahn an optimal way for address provisioning due to the potential problems described in Section 3.4 below. - Avoid Flags Transition as Possible As described in Problem-3, the behavior would be unpredictable/ un-controlled when flags are in transition. So the administrators need to carefully plan the network and try to avoid the requirement that host address configuration switching between different states (e.g. from SLAAC-only to DHCPv6-only or vice versa; from SLAAC-only to DHCPv6/SLAAC co-existence or vice versa). Since the expected host behavior is not guaranteed by only transitioning the flags. To achieve the state switching, manual/additional operation burden might be involved. 3.2. Guidance for DHCPv6-only Deployment In IPv4, there is only one method (DHCPv4) for automatically configuring the hosts. Many network operations/mechanisms, especially in enterprise networks, are built around this central- managed model. So it is reasonable for people who are accustomed to DHCPv4-only deployment still prefer DHCPv6-only in IPv6 networks. Liu, et al. Expires January 22, 2015 [Page 4] Internet-Draft DHCPv6/SLAAC Interaction Guidance July 2014 Besides, some networks just prefer central management of all IP addressing. These networks may want to assign addresses only via DHCPv6. This can be accomplished by sending RAs that indicate DHCPv6 is available (M=1), installing DHCPv6 servers or DHCPv6 relays on all links, and setting A=0 in the Prefix Information Options of all prefixes in the RAs. (Instead of forcing the A flag off, simply not including any PIO in RAs could also make the same effect). But before doing this, the administrators need to be sure that every node in their intended management scope supports DHCPv6. Note that RAs are still necessary in order for hosts to be able to use these addresses. This is for two reasons: 1. Per Problem-1, if there is no RA, some hosts will not attempt to obtain address configuration via DHCPv6 at all. 2. DHCPv6 can assign addresses but not routing. Routing can be implemented on hosts by means of accepting and implementing information from RA messages containing default-route, Prefix Information Option with O=1, or Route Information Option, or by configuring manual routing. Without routing, IPv6 addresses won't be used for communication outside the host. Thus, for example, if there is no RA and no static routing, then addresses assigned by DHCPv6 cannot be used even for communication between hosts on the same link. Also note that unlike SLAAC, DHCPv6 is not a strict requirement for IPv6 hosts [RFC6434], and some nodes do not support DHCPv6. Thus, this model can only be used if all the hosts that need IPv6 connectivity support DHCPv6. Per Problem-2, if the administrators want to switch the DHCPv6-only configured hosts to SLAAC-only, this is not possible on some hosts without manually changing the hosts' configuration or using additional management tools. Per Problem-4, for some platforms, the A flag and O flag might not be independent, when SLAAC is off, a stand-alone stateless DHCPv6 session would not be applicable. However, this might not be a common use case. 3.3. Guidance for SLAAC-only Deployment In contrast with DHCPv6-only, some scenarios might be suitable for SLAAC-only which allows minimal administration burden and node capability requirement. Liu, et al. Expires January 22, 2015 [Page 5] Internet-Draft DHCPv6/SLAAC Interaction Guidance July 2014 The administrators MUST turn the A flag on, and turn M flag off. Note that some platforms (e.g. Windows 8) might still initiate DHCPv6 session regardless of M flag off. But since there is no DHCPv6 service available, the only problem is that there would be some unnecessary traffic. Per Problem-2, if the administrators want to switch the SLAAC-only configured hosts to DHCPv6-only, it might be not applicable for some hosts without manually changing the hosts' configuration or using additional management tools. 3.4. Guidance for DHCPv6/SLAAC Co-existence Deployment - Scenarios of DHCPv6/SLAAC co-existence * For provisioning redundancy: If the administrators want all nodes at least could configure a global scope address, then they could turn A flag and M flag both on in case some nodes only support one of the mechanisms. For example, some hosts might only support SLAAC; while some hosts might only support DHCPv6 due to manual/mistaken configurations. * For different provisioning: If the two mechanisms would bring two prefixes for the nodes respectively (e.g. special prefix from DHCPv6 for a specific service), then the administrators need to make sure the SLAAC and DHCPv6 are available simultaneously (through RA with M=1) before nodes getting online, since once the nodes were configured with SLAAC, per Problem-2, later they might not care about the newly added DHCPv6 provision. - Potential Problems * Per Problem-3, when administrators want to deprecate a SLAAC/ DHCPv6 prefix/address, it's better NOT simply turning the A/M flag off since there is possibility that some platforms might immediately release the addresses. This behavior might be harmful in some situations, e.g. in make-before-break renumbering. * It is worth to be noticed that enabling both DHCPv6 and SLAAC would cause one host to configure more IPv6 addresses. Typically, there would be one more DHCPv6-configured address than SLAAC-only configuration; and two more addresses based on SLAAC and privacy extension than DHCPv6-only configuration. Too many addresses might cause ND cache overflow problem in some situations (please refer to Section 3.2 of [I-D.liu-v6ops-running-multiple-prefixes] for details). Liu, et al. Expires January 22, 2015 [Page 6] Internet-Draft DHCPv6/SLAAC Interaction Guidance July 2014 * For provisioning redundancy scenario, there is concern that SLAAC/DHCPv6 addresses based on the same prefix might cause some applications confusing. But we haven't identified real problems in practice. [Open Question] Has anybody experienced issues in the case? * Besides address configuration, DNS can also be configured both by SLAAC and DHCPv6. If the DNS information in RAs and DHCPv6 are different, the host might confuse. So in terms of operation, the operators should make sure DNS configuration in RAs and DHCPv6 are the same. 4. Security Considerations No more security considerations than the Neighbor Discovery protocol [RFC4861]. 5. IANA Considerations This draft does not request any IANA action. 6. Acknowledgements Valuable comments were received from Sheng Jiang and Brian E Carpenter to initiate the draft. Texts in Section 3.2 were based on Lorenzo Colitti and Mikael Abrahamsson's proposal. There were also comments from Erik Nordmark, Ralph Droms, John Brzozowski, Andrew Yourtchenko and Wesley George to improve the draft. The authors would like to thank all the above contributors. This document was produced using the xml2rfc tool [RFC2629]. (This document was initiallly prepared using 2-Word-v2.0.template.dot. ) 7. References 7.1. Normative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Liu, et al. Expires January 22, 2015 [Page 7] Internet-Draft DHCPv6/SLAAC Interaction Guidance July 2014 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011. 7.2. Informative References [I-D.ietf-v6ops-dhcpv6-slaac-problem] Liu, B., Bonica, R., Gong, X., and W. Wang, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", draft-ietf-v6ops-dhcpv6-slaac-problem-01 (work in progress), June 2014. [I-D.liu-v6ops-running-multiple-prefixes] Liu, B., Jiang, S., and Y. Bo, "Running Multiple IPv6 Prefixes", draft-liu-v6ops-running-multiple-prefixes-01 (work in progress), July 2014. [I-D.yourtchenko-ra-dhcpv6-comparison] Yourtchenko, A., "A comparison between the DHCPv6 and RA based host configuration", draft-yourtchenko-ra- dhcpv6-comparison-00 (work in progress), November 2013. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Authors' Addresses Bing Liu Huawei Technologies Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: leo.liubing@huawei.com Ron Bonica Juniper Networks Sterling, Virginia 20164 USA Email: rbonica@juniper.net Liu, et al. Expires January 22, 2015 [Page 8] Internet-Draft DHCPv6/SLAAC Interaction Guidance July 2014 Tianle Yang China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 100053 P.R. China Email: yangtianle@chinamobile.com Liu, et al. Expires January 22, 2015 [Page 9]