Internet DRAFT - draft-liu-6man-dhcpv6-slaac-implementation-guide
draft-liu-6man-dhcpv6-slaac-implementation-guide
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
