Network Working Group B. Liu Internet Draft Huawei Technologies Intended status: Informational R. Bonica Expires: June 28, 2014 Juniper Networks T. Yang China Mobile December 25, 2013 DHCPv6/SLAAC Interaction Operational Guidance draft-liu-v6ops-dhcpv6-slaac-guidance-00.txt 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 June 28, 2014. Copyright Notice Copyright (c) 2011 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 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. Liu, et al. Expires June 28 2014 [Page 1] Internet-Draft liu-v6ops-dhcpv6-slaac-guidance December 2013 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. Table of Contents 1. Introduction ................................................. 3 2. Problems Summary ............................................. 3 3. Operational Guidance.......................................... 4 3.1. General Guidelines ...................................... 4 3.2. Guidance for DHCPv6-only Deployment ..................... 5 3.3. Guidance for SLAAC-only Deployment ...................... 5 3.4. Guidance for DHCPv6/SLAAC Co-exist Deployment ........... 6 4. Security Considerations ...................................... 6 5. IANA Considerations .......................................... 6 6. References ................................................... 7 6.1. Normative References .................................... 7 6.2. Informative References .................................. 7 7. Acknowledgments .............................................. 7 Authors' Addresses .............................................. 8 Liu, et al. Expires June 28, 2014 [Page 2] Internet-Draft liu-v6ops-dhcpv6-slaac-guidance December 2013 1. Introduction In draft [DHCPV6-SLAAC-PS], the DHCPv6/SLAAC 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. Note that, as similar to the [DHCPV6-SLAAC-PS], this document mainly focuses on address provisioning problems and doesn't intent to cover other provisions such as routes, DNS etc. This document either doesn't 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 [RA-DHCPv6-COMP] could be referred. 2. Problems Summary The main problem described in [DHCPV6-SLAAC-PS] is standard definition ambiguity which means, on interpreting the same messages, different hosts might behave differently. Thus it 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. At initialing state, all the platforms we tested just treated the flags as prescriptive. But when flags are in Liu, et al. Expires June 28, 2014 [Page 3] Internet-Draft liu-v6ops-dhcpv6-slaac-guidance December 2013 transition, e.g. the host is already SLAAC-configured, then M flag transition from 0 to 1, or the host is already DHCPv6-configured, then A flag transitions from 0 to 1, the behavior of different platforms varied. Some still treated the flags as prescriptive while others just treated them as advisory and did nothing. #3 "Address Configuring Method" VS "Address Lifetime" When method changes, should the hosts immediately release the addresses or just wait them expired? It is not clearly specified in standards. #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, should the host 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, should the host initiate a stand-alone stateless DHCPv6 session? 3. Operational Guidance 3.1. General Guidelines - Always Turn RAs On Currently, turning RAs on is actually a basic requirement for running IPv6 network since only RA 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. - SLAAC Could be considered as a Bottom Line for Address Provisioning SLAAC is a basic requirement for an IPv6 node as specified in [RFC6434]. So every node could always get a prefix if RAs with PIO Prefix Information Option are available. If the administrators need to management nodes which might include multiple operation systems, and they want to make sure every node could at least get one global prefix, SLAAC is the bottom line. Then A flag always needs to be turned on in this case. - Avoid Flags Transition as Possible Liu, et al. Expires June 28, 2014 [Page 4] Internet-Draft liu-v6ops-dhcpv6-slaac-guidance December 2013 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 host address configuration method switch as possible, since it might not be applicable by transitioning the flags thus significant operation burden might be involved. 3.2. Guidance for DHCPv6-only Deployment In IPv4, there is only one method (DHCPv4) of 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. So in this case, the administrators could always force SLAAC off (A=0), indicate DHCPv6 is available (M=1), and install DHCPv6 relays on all routers. 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 clear of the fact that every node in their intended management scope is supposed to support DHCPv6. - Use Cases Might NOT be Supported Per problem #1, DHCPv6-only configuration without RAs is not applicable for some hosts. But this is an invalid use case so far, as analyzed above. Never the less, it might become a problem when mechanism like [DHCPv6-ROUTE] are available in the future. Per problem #2, if the administrators want to switch the DHCPv6-only configured hosts to SLAAC-only, it might be not applicable for 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, e.g. an isolated network. Liu, et al. Expires June 28, 2014 [Page 5] Internet-Draft liu-v6ops-dhcpv6-slaac-guidance December 2013 The administrators MUST turn the A flag on, and should turn M flag off. Note that some platforms (e.g. Window 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. - Use Cases Might NOT be Supported 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-exist Deployment 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 due to capability limitation (SLAAC-only) or specific configuration manually or mistakenly (DHCPv6-only). If the two mechanisms would bring two prefixes for the nodes respectively, then the administrators need to make sure the SLAAC and DHCPv6 are available simultaneously (through RA with M=1) before nodes get online since once the nodes were configured with one prefix, per problem #2, later they might not care about the other newly added prefix. 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 some platforms might immediately release the addresses. It might be harmful in some situations, especially in make-before-break renumbering. 4. Security Considerations No more security considerations than the Neighbor Discovery protocol [RFC4861]. 5. IANA Considerations None. Liu, et al. Expires June 28, 2014 [Page 6] Internet-Draft liu-v6ops-dhcpv6-slaac-guidance December 2013 6. References 6.1. Normative References [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [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. 6.2. Informative References [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [DHCPV6-SLAAC-PS] Liu, B., Bonica, R., Gong, X., and W. Wang, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Work in Progress, November 2013 [RA-DHCPv6-COMP] A. Yourtchenko, "A comparison between the DHCPv6 and RA based host configuration", Work in Progress, November 2013 [DHCPv6-ROUTE] Dec, W., Mrugalski, T., Sun, T., Sarikaya, B., and A. Matsumoto, " DHCPv6 Route Options ", Work in Progress, August 2012 7. Acknowledgments Valuable comment was received from Sheng Jiang and Brian E Carpenter to initiate the draft. This document was prepared using 2-Word-v2.0.template.dot. Liu, et al. Expires June 28, 2014 [Page 7] Internet-Draft liu-v6ops-dhcpv6-slaac-guidance December 2013 Authors' Addresses Bing Liu Q14-4-A Building Huawei Technologies Co., Ltd Zhong-Guan-Cun Environment Protection Park, No.156 Beiqing Rd. Hai-Dian District, Beijing P.R. China Email: leo.liubing@huawei.com Ron Bonica Juniper Networks Sterling, Virginia 20164 USA Email: rbonica@juniper.net Tianle Yang China Mobile 32, Xuanwumenxi Ave. Xicheng District, Beijing 100053 China Email: yangtianle@chinamobile.com