Network Working Group B. Liu Internet Draft Huawei Technologies Intended status: Informational R. Bonica Expires: December 20, 2014 Juniper Networks S. Jiang Huawei Technologies X. Gong W. Wang BUPT University June 18, 2014 DHCPv6/SLAAC Address Configuration Interaction Problem Statement draft-ietf-v6ops-dhcpv6-slaac-problem-01.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 December 18, 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 December 20 2014 [Page 1] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 Abstract This document analyzes the DHCPv6/SLAAC interaction issue on host. More specifically, the interaction is regarding with the A, M, and O flags which are defined in ND protocol. Test results identify that current implementations in operating systems have varied on interpreting the flags. The variation might cause some operational issues as described in the document. Table of Contents 1. Introduction ................................................. 3 2. Host Behavior Definition in Standards ........................ 3 2.1. A (Autonomous) Flag ..................................... 4 2.2. M (Managed) Flag ........................................ 4 2.3. O (Otherconfig) Flag .................................... 4 3. Problems Statement ........................................... 5 3.1. Host Behavior Ambiguity ................................. 5 3.2. Operational Problems Implication ........................ 6 3.2.1. Renumbering ........................................ 6 3.2.2. Cold Start Problem ................................. 6 3.2.3. Specific Management Patterns ....................... 7 4. Conclusions .................................................. 7 5. Security Considerations ...................................... 7 6. IANA Considerations .......................................... 7 7. References ................................................... 7 7.1. Normative References .................................... 7 7.2. Informative References .................................. 8 8. Acknowledgments .............................................. 8 Appendix A. Test Results of Host Behavior ....................... 9 A.1 Detailed Test Results .................................... 9 A.1.1 Host Initial Behavior .............................. 10 A.1.2 Host Behavior in Flags Transition .................. 10 A.2 Observations from the Test .............................. 11 Liu, et al. Expires December 20, 2014 [Page 2] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 1. Introduction In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery [RFC4861] protocols could be utilized for automatic IP address configuration for the hosts. They are known as stateful address auto-configuration and stateless address auto-configuration (SLAAC, [RFC4862]). Sometimes the two address configuration methods might be both available in one network. In ND protocol, there is an M (Managed) flag defined in RA message, indicating the hosts whether there is DHCPv6 service in the network or not. And there is an O (OtherConfig) flag, if set, indicating configure information other than addresses (e.g. DNS, Route .etc) is available through DHCPv6 configuration. Moreover, there's another A (Autonomous) flag defined in ND, indicating the hosts to do SLAAC, may also influent the behavior of hosts. So with these flags, the two address configuration mechanisms are somehow correlated. But for some reasons, the ND protocol didn't define the flags as prescriptive but only advisory. This ambiguous definition might vary the behavior of interpreting the flags by different hosts. This would add additional complexity for both the hosts and the network management. This draft reviews the standard definition of the above mentioned flags, and identifies the potential ambiguous behavior of interpreting these flags. And then analyzes what operational problems might be caused by the ambiguous behavior. In the appendix, detailed test results of several major desktop operating systems' behavior of interpreting the flags are provided. According to the test results, we can see the ambiguity problem is actually happening in current implementations. 2. Host Behavior Definition in Standards In this section, we analyzed A, M and O flags definition. Please note that, A flag has no direct relationship with DHCPv6, but it is somewhat correlated with M and O flags. Liu, et al. Expires December 20, 2014 [Page 3] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 2.1. A (Autonomous) Flag In ND Prefix Information Option, the autonomous address-configuration flag (A flag)is used to indicate whether this prefix can be used for SLAAC. For the host behavior, there is an explicit rule in the SLAAC specification [RFC4862]: "If the Autonomous flag is not set, silently ignore the Prefix Information option." But when A flag is set, the SLAAC protocol didn't provide a prescriptive definition. (However, it is quite obvious that host should do SLAAC when A flag is set.) 2.2. M (Managed) Flag In earlier SLAAC specification [RFC2462], the host behavior of interpreting M flag is as below: "On receipt of a valid Router Advertisement, a host copies the value of the advertisement's M bit into ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address auto-configuration protocol, requesting both address information and other information. If the value of the ManagedFlag changes from TRUE to FALSE, the host should continue running the stateful address auto-configuration, i.e., the change in the value of the ManagedFlag has no effect. If the value of the flag stays unchanged, no special action takes place. In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating in the stateful protocol as a result of an earlier advertisement." But in the updated SLAAC specification [RFC4862], the relative description was removed, the reason was "considering the maturity of implementations and operational experiences. ManagedFlag and OtherConfigFlag were removed accordingly. (Note that this change does not mean the use of these flags is deprecated.)" 2.3. O (Otherconfig) Flag The situation of O flag is similar with above mentioned M flag. In earlier SLAAC [RFC2462], the host behavior is clear: "If the value of OtherConfigFlag changes from FALSE to TRUE, the host should invoke the stateful autoconfiguration protocol, requesting information (excluding addresses if ManagedFlag is set to FALSE). If Liu, et al. Expires December 20, 2014 [Page 4] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 the value of the OtherConfigFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration protocol, i.e., the change in the value of OtherConfigFlag has no effect. If the value of the flag stays unchanged, no special action takes place. In particular, a host MUST NOT reinvoke stateful configuration if it is already participating in the stateful protocol as a result of an earlier advertisement." And there's another description of the relationship of M and O flags in [RFC2462]: "In addition, when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitely TRUE as well. It is not a valid configuration for a host to use stateful address autoconfiguration to request addresses only, without also accepting other configuration information." 3. Problems Statement 3.1. Host Behavior Ambiguity The main problem 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 or Prescriptive Some platforms interpret the flags as advisory while others might interpret them prescriptive. Especially when flags are in transition, e.g. the host is already SLAAC-configured, then M flag changes from FALSE to TRUE, it is not clear whether the host should start DHCPv6 or not; or vise versa, the host is already both SLAAC/DHCPv6 configured, then M flag change from TRUE to FALSE, it is also not clear whether the host should turn DHCPv6 off or not. #3 "Address Configuring Method" and "Address Lifetime" Liu, et al. Expires December 20, 2014 [Page 5] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 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 both M and O flags are TRUE, it is not clear whether the host should initiate one stateful DHCPv6 session to get both address and info-configuration or initiate two independent sessions of which one is dedicated for address provisioning and the other is for information provision. When A and M flags are FALSE and O flag is TRUE, it is not clear whether the host should initiate a stand-alone stateless DHCPv6 session. 3.2. Operational Problems Implication According to the abovementioned host behavior ambiguity, there might be operational issues as the following. 3.2.1. Renumbering During IPv6 renumbering, the SLAAC-configured hosts can reconfigure IP addresses by receiving ND Router Advertisement (RA) messages containing new prefix information. The DHCPv6-configured hosts can reconfigure addresses by initialing RENEW sessions when the current addresses' lease time is expired or receiving the reconfiguration messages initialed by the DHCPv6 servers. The above mechanisms have an implicit assumption that SLAAC- configured hosts will remain SLAAC while DHCPv6-managed hosts will remain DHCPv6-managed. But in some situations, SLAAC-configured hosts might need to switch to DHCPv6-managed, or vice versa. In [RFC6879], it described several renumbering scenarios in enterprise network for this requirement; for example, the network may split, merge, relocate or reorganize. But due to current implementations, this requirement is not applicable and has been identified as a gap in [RFC7010]. 3.2.2. Cold Start Problem If all nodes, or many nodes, restart at the same time after a power cut, the results might not consistent. Liu, et al. Expires December 20, 2014 [Page 6] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 3.2.3. Specific Management Patterns Since the host behavior of address configuration is somehow un- controlled by the network side, it might cause gaps to the networks that need some specific management patterns. Examples are: - the hosts have been SLAAC-configured, then the network need the hosts to do DHCPv6 simultaneously (e.g. for multihoming). - the network wants the hosts to do stateless DHCPV6-only; for example, the hosts are configured with self-generated addresses (e.g. ULA), and they also need to contact the DHCPv6 server for info- configuration. 4. Conclusions - The host behavior of SLAAC/DHCPv6 interaction is ambiguous in standard. - Varied behavior of implementations has been observed. In [RFC4862] it is said "Removed the text regarding the M and O flags, considering the maturity of implementations and operational experiences." This consideration intended to remain the ambiguity. But in the perspective of operation, ambiguity normally is problematic. - It is foreseeable that the un-uniformed host behavior can cause operational problems. 5. Security Considerations No more security considerations than the Neighbor Discovery protocol [RFC4861]. 6. IANA Considerations None. 7. References 7.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. Liu, et al. Expires December 20, 2014 [Page 7] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 7.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. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, September 2013. [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013. 8. Acknowledgments The test was done by our research partner BNRC-BUPT (Broad Network Research Centre in Beijing University of Posts and Telecommunications). Thanks for the hard efficient work of student Xudong Shi and Longyun Yuan. Valuable comments were received from Sheng Jiang, Brian E Carpenter, Ron Atkinson, Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith to improve the draft. This document was prepared using 2-Word-v2.0.template.dot. Liu, et al. Expires December 20, 2014 [Page 8] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 Appendix A. Test Results of Host Behavior We did tests of the behavior of interpreting the flags by current mainstream desktop/mobile operating systems as the following. A.1 Detailed Test Results /-----\ +---------+ // \\ | DHCPv6 | | Router | | server | \\ // +----+----+ \--+--/ | | | | | | ----+--+----------+----------+---+----- | | | | | | | | | +----+---+ +----+---+ +----+---+ | | | | | | | Host1 | | Host2 | | Host3 | +--------+ +--------+ +--------+ Figure 1 Test Environment The 5 elements were all created in Vmware in one computer, for ease of operation. - Router quagga 0.99-19 soft router installed on Ubuntu 11.04 virtual host - DHCPv6 Server: dibbler-server installed on Ubuntu 11.04 virtual host - Host A Window 7 Virtual Host - Host B Ubuntu 12.10 Virtual Host - Host C Mac OS X v10.7 Virtual Host Another test was done dedicated for the mobile phone operating systems. The environment is similar (not in VMware, all are real PC and mobile phones): - Router quagga 0.99-17 soft router installed on Ubuntu 12.10 - DHCPv6 Server: dibbler-server installed on Ubuntu 12.10 Liu, et al. Expires December 20, 2014 [Page 9] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 - Host D Android 4.0.4 (kernel: 3.0.16-gfa98030; device: HTC Incredible S) - Host E IOS 6.1.3 (model: iPod Touch 4) (Note: The tested Android version didn't support DHCPv6, so the following results don't include Android.) A.1.1 Host Initial Behavior When hosts are not configured yet, we tested their behavior when receiving different A/M/O combinations. The results are as the following: o Window 7/Apple IOS - A=0&M=O&O=0, non-config - A=1&M=0&O=0, SLAAC only - A=1&M=0&O=1, SLAAC + Stateless DHCPv6 - A=1&M=1&O=0, SLAAC + DHCPv6 - A=1&M=1&O=1, SLAAC + DHCPv6 - A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) - A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) - A=0&M=0&O=1, Stateless DHCPv6 only o Linux/MAC OS X - A=0&M=O&O=0, non-config - A=1&M=0&O=0, SLAAC only - A=1&M=0&O=1, SLAAC + Stateless DHCPv6 - A=1&M=1&O=0, SLAAC + DHCPv6 - A=1&M=1&O=1, SLAAC + DHCPv6 - A=0&M=1&O=0, DHCPv6 only (A=0 or Non-PIO) - A=0&M=1&O=1, DHCPv6 only (A=0 or Non-PIO) - A=0&M=0&O=1, non-config As showed above, Linux and MAC OSX acted the same way, but are different from Windows 7 and Apple IOS. The only difference is when A=0&M=0&O=1, Windows 7/Apple IOS did stateless DHCPv6 while Linux/MAC OSX did nothing. A.1.2 Host Behavior in Flags Transition o SLAAC-only host receiving M=1 - Window 7 would initiate DHCPv6 - Linux/MAC/IOS would keep SLAAC and don't initiate DHCPv6 unless SLAAC is expired and no continuous RAs o DHCPv6-only host receiving A=1 Liu, et al. Expires December 20, 2014 [Page 10] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 - They all do SLAAC o Stateless DHCPv6-configured host receiving M=1 (while keeping O=1) - Window 7 would initiate stateful DHCPv6, configuring address as well as re-configuring other information - Linux/MAC/IOS no action o Statefull DHCPv6-configured host receiving M=0 (while keeping O=1) - Window 7 would release all DHCPv6 configurations including address and other information, and initiate stateless DHCPv6 - Linux/MAC/IOS no action A.2 Observations from the Test o A flag A flag is a switch to control whether to do SLAAC, and it is independent with M and O flags, in another word, A is independent with DHCPv6. At the non-SLAAC-configured state (either non-configured or DHCPv6- configured only), all the operating systems acted the same way in interpreting A flag. If A flag is TRUE, they all configure SLAAC, it is obvious and reasonable. o M flag M is a key flag to interact ND and DHCPv6, but the host behaviors on M flag were quite different. At the initialing state, some operating systems would start DHCPv6 only if receiving an RA message with M flag set while some would initially start DHCPv6 if RAs are absent. This result reflects the ambiguity problem of #1 Dependency between DHCPv6 and RA in above text. When the hosts are SLAAC-configured, and then the M flag changes from FALSE to TRUE, some operating systems would initiate DHCPv6 while some would not. This reflects the problem #2 Advisory or Prescriptive. o O flag In the test, when M flag is set, the O flag is implicitly set as well; in another word, the hosts would not initial stateful DHCPv6 and stateless DHCPv6 respectively. This is a reasonable behavior. Liu, et al. Expires December 20, 2014 [Page 11] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 But the O flag is not independent from A flag in some operating systems, which won't initiate stateless DHCPv6 when A flag is FALSE. That is to say, it is not applicable to have a "stateless DHCPv6 only" configuration state for some operating systems; it is also not applicable for these operating systems to switch between stateful DHCPv6 and stateless DHCPv6 (according to O flag changing from TRUE to FALSE or vice versa). This reflects the problem #4 Dependencies between the flags. Liu, et al. Expires December 20, 2014 [Page 12] Internet-Draft draft-ietf-v6ops-dhcpv6-slaac-problem June 2014 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 Xiangyang Gong No.3 Teaching Building Beijing University of Posts and Telecommunications (BUPT) No.10 Xi-Tu-Cheng Rd. Hai-Dian District, Beijing P.R. China Email: xygong@bupt.edu.cn Wendong Wang No.3 Teaching Building Beijing University of Posts and Telecommunications (BUPT) No.10 Xi-Tu-Cheng Rd. Hai-Dian District, Beijing P.R. China Email: wdwang@bupt.edu.cn