Network Working Group B. Liu Internet Draft Huawei Technologies Intended status: Informational R. Bonica Expires: August 18, 2014 Juniper Networks February 14, 2014 DHCPv6/SLAAC Interaction Implementation Guidance draft-liu-6man-dhcpv6-slaac-implementation-guide-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 August 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. 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 Liu, et al. Expires August 18 2014 [Page 1] Internet-Draft dhcpv6-slaac-implementation-guidance February 2014 interpreting the flags. The variation might impact real network operations, so this document aims to provide some guidance on what should be the proper implementation on the interaction behavior. Table of Contents 1. Introduction ................................................. 3 2. Problems Summary ............................................. 3 3. Implementation Guidance ...................................... 4 3.1. For the dependency ...................................... 4 3.2. Advisory VS Prescriptive ................................ 4 3.3. Method VS Lifetime ...................................... 4 3.4. Flags dependency ........................................ 5 4. Security Considerations ...................................... 5 5. IANA Considerations .......................................... 5 6. References ................................................... 5 6.1. Normative References .................................... 5 6.2. Informative References .................................. 5 7. Acknowledgments .............................................. 6 Authors' Addresses .............................................. 7 Liu, et al. Expires August 18, 2014 [Page 2] Internet-Draft dhcpv6-slaac-implementation-guidance February 2014 1. Introduction In draft [DHCPV6-SLAAC-PS], the DHCPv6/SLAAC [RFC3315] [RFC4862]interaction issue on host was 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 issues as described in the document. 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 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 Liu, et al. Expires August 18, 2014 [Page 3] Internet-Draft dhcpv6-slaac-implementation-guidance February 2014 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. Implementation Guidance 3.1. For the dependency When considering ND and DHCPv6, in general they should not rely on each other from the perspective of two different protocols. But in current practice, as described in [OPERATIONAL-GUIDE], it is reasonable that DHCPv6 is initialed relying on RA messages (with the M flag set in the Prefix Information Option), since DHCPv6-only- without-RA is an invalid use case so far and RAs are always needed for the hosts to have offline communication. However, for the implementation, making DHCPv6 initialing totally depend on RA messages is more or less fragile since DHCPv6-only- without-RA might become a valid case in the future or some special scenarios. So it is recommended for implementers to take into account the cases that RAs are absent. The DHCPv6 protocol state machine should support DHCPv6 be initiated after a timeslot of RAs absent. 3.2. Advisory VS Prescriptive The fact that current implementations have varied on interpreting the flags is mostly caused by the ambiguity of the definition. It is recommended for the implementation to interpret the flags as prescriptive rather than advisory. Especially when the flags are in transitioning, it is recommended for the implementation to continually monitor the flags' state. If the flags changed, the program should behave as the changed flags indicate. 3.3. Method VS Lifetime When A/M/O is changed from 1 to 0, the program should deprecate the relevant configuration method as recommended in the above Section 3.2. But the program should remain the configured addresses or information until the lifetime expired. It is not recommended that the program immediately release the address or information when configuration method change is detected. Liu, et al. Expires August 18, 2014 [Page 4] Internet-Draft dhcpv6-slaac-implementation-guidance February 2014 3.4. Flags dependency When M=1, regardless O=1 or O=0, the host should try to get all the configurations through one stateful DHCPv6 session. When M=1 and O=1, but the host didn't get any information configuration besides address configuration, the host should try to get information configuration through another stateless DHCPv6 procedure. When M=0 and O=1, regardless A=1 or A=0, the host should try to get information configuration through a stateless DHCPv6 procedure. 4. Security Considerations No more security considerations than the Neighbor Discovery protocol [RFC4861]. 5. IANA Considerations None. 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. 6.2. Informative References [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 [OPERATIONAL-GUIDE] Liu, B., Bonica, R., and T. Yang, "DHCPv6/SLAAC Address Configuration Interaction Operational Guidance", Work in Progress, February 2014 Liu, et al. Expires August 18, 2014 [Page 5] Internet-Draft dhcpv6-slaac-implementation-guidance February 2014 7. Acknowledgments Valuable comment was received from Brian E Carpenter and Sheng Jiang to initiate the draft. This document was prepared using 2-Word-v2.0.template.dot. Liu, et al. Expires August 18, 2014 [Page 6] Internet-Draft dhcpv6-slaac-implementation-guidance February 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