Network Working Group                                           B. Liu
Internet Draft                                     Huawei Technologies
Intended status: Informational                               R. Bonica
Expires: August 18, 2014                              Juniper Networks
                                                               T. Yang
                                                          China Mobile
                                                     February 14, 2014

               DHCPv6/SLAAC Interaction Operational Guidance
               draft-liu-v6ops-dhcpv6-slaac-guidance-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 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.








Liu, et al.            Expires August 18 2014                [Page 1]


Internet-Draft      liu-v6ops-dhcpv6-slaac-guidance      February 2014


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 ...................... 6
      3.4. Guidance for DHCPv6/SLAAC Co-exist Deployment ........... 6
   4. Security Considerations ...................................... 7
   5. IANA Considerations .......................................... 7
   6. References ................................................... 7
      6.1. Normative References .................................... 7
      6.2. Informative References .................................. 7
   7. Acknowledgments .............................................. 8
   Authors' Addresses .............................................. 9





















Liu, et al.            Expires August 18, 2014                [Page 2]


Internet-Draft      liu-v6ops-dhcpv6-slaac-guidance      February 2014




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 August 18, 2014                [Page 3]


Internet-Draft      liu-v6ops-dhcpv6-slaac-guidance      February 2014


   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

   As specified in [RFC6434], SLAAC is a basic requirement for an IPv6
   node while DHCPv6 is not anymore a requirement. 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 August 18, 2014                [Page 4]


Internet-Draft      liu-v6ops-dhcpv6-slaac-guidance      February 2014


   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.

   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 an RA that indicates that DHCPv6
   address assignment is available (i.e., 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 RA. (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 an RA is 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.


Liu, et al.            Expires August 18, 2014                [Page 5]


Internet-Draft      liu-v6ops-dhcpv6-slaac-guidance      February 2014


   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, e.g. an isolated network.

   The administrators MUST turn the A flag on, and should 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.

   - 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


Liu, et al.            Expires August 18, 2014                [Page 6]


Internet-Draft      liu-v6ops-dhcpv6-slaac-guidance      February 2014


   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.

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






Liu, et al.            Expires August 18, 2014                [Page 7]


Internet-Draft      liu-v6ops-dhcpv6-slaac-guidance      February 2014


7. Acknowledgments

   Valuable comment was received from Sheng Jiang and Brian E Carpenter
   to initiate the draft. Many texts in Section 3.2 were proposed by
   Lorenzo Colitti and Mikael Abrahamsson to improve the draft.

   The authors would like to thank all the above contributors.

   This document was prepared using 2-Word-v2.0.template.dot.







































Liu, et al.            Expires August 18, 2014                [Page 8]


Internet-Draft      liu-v6ops-dhcpv6-slaac-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


   Tianle Yang
   China Mobile
   32, Xuanwumenxi Ave.
   Xicheng District, Beijing  100053
   China

   Email: yangtianle@chinamobile.com





















Liu, et al.            Expires August 18, 2014                [Page 9]