Network Working Group
V6OPS                                                             B. Liu
Internet Draft                                    Huawei Technologies
Internet-Draft                                                  S. Jiang
Intended status: Informational                       Huawei Technologies
Expires: April 17, 2015                                        R. Bonica
Expires: December 20, 2014
                                                        Juniper Networks
                                                             S. Jiang
                                                  Huawei Technologies
                                                                 X. Gong
                                                                 W. Wang
                                                         BUPT University
                                                        June 18,
                                                        October 14, 2014

    DHCPv6/SLAAC Address Configuration Interaction Problem Statement
               draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt
                draft-ietf-v6ops-dhcpv6-slaac-problem-02

Abstract

   The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router
   Advertisement (RA) message.  The RA message contains three flags,
   indicating which autoconfiguration mechanisms are available to on-
   link hosts.  These are the M, O and A flags.  The M, O and A flags
   are advisory, not prescriptive.

   This document describes divergent host behaviors observed in popular
   operating systems.  It also describes operational problems that
   divergent behaviors cause.

Status of this 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 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. April 17, 2015.

Copyright Notice

   Copyright (c) 2011 2014 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

   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
   2. Host Behavior Definition in Standards ........................  The M, O and A Flags  . . . . . . . . . . . . . . . . . . . .   3
     2.1. A (Autonomous) Flag ..................................... 4
      2.2.  M (Managed) Flag ........................................ 4
      2.3.  . . . . . . . . . . . . . . . . . . . .   3
     2.2.  O (Otherconfig) Flag ....................................  . . . . . . . . . . . . . . . . . .   4
     2.3.  A (Autonomous) Flag . . . . . . . . . . . . . . . . . . .   4
   3. Problems  Problem Statement ........................................... 5 . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Divergent Host Behavior Ambiguity ................................. 5 Behaviors  . . . . . . . . . . . . . . . .   4
     3.2.  Operational Problems Implication ........................ 6  . . . . . . . . . . . . . . . . . .   5
       3.2.1. Renumbering ........................................ 6  Inappropriate Sources . . . . . . . . . . . . . . . .   5
       3.2.2. Cold Start Problem ................................. 6
         3.2.3. Specific Management Patterns ....................... 7  Renumbering . . . . . . . . . . . . . . . . . . . . .   5
   4. Conclusions .................................................. 7
   5.  Security Considerations ...................................... 7
   6. . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations .......................................... 7 . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References ................................................... 7  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References .................................... 7  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References .................................. 8
   8. Acknowledgments .............................................. 8  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Test Results of Host Behavior ....................... 9
      A.1 Detailed . . . . . . . . . . . . . . . . . . . .   7
     A.1.  Test Results .................................... 9
         A.1.1 Environment  . . . . . . . . . . . . . . . . . . . .   7
     A.2.  Host Initial Behavior .............................. 10
         A.1.2 in the Initial State  . . . . . . . . . . .   8
     A.3.  Host Behavior in Flags Transition .................. 10
      A.2 Observations from State Transitions  . . . . . . . . . . .   9
   Appendix B.  Analysis of the Test .............................. Ambiguities  . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   In IPv6, both of the DHCPv6 [RFC3315] and

   IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861]
   protocols could be utilized for automatic IP address configuration
   for the hosts. They
   procedures in order to discover which autoconfiguration mechanisms
   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 to them.  The following is a list of autoconfiguration
   mechanisms:

   o  DHCPv6 service in [RFC3315]

   o  Stateless Address Autoconfiguration (SLAAC) [RFC4862]

   ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message.
   Routers periodically broadcast the network
   or not. And there is RA message to all on-link nodes.

   They also unicast RA messages in response to solicitations.  The RA
   message contains:

   o  an M (Managed) flag

   o  an O (OtherConfig) flag, if set, indicating
   configure information other than flag

   o  zero or more Prefix Information (PI) Options

   The M flag indicates that addresses (e.g. DNS, Route .etc) are available from DHCPv6.  The O
   flag indicates that other configuration information (e.g., DNS-
   related information) is available through DHCPv6 configuration. Moreover, there's another from DHCPv6.  The PI Option
   includes a prefix, an A (Autonomous) flag defined in ND, indicating the hosts to do SLAAC,
   may also influent the behavior of hosts.

   So with these flags, and other fields.  The A
   flag indicates that the two address configuration mechanisms are
   somehow correlated. But prefix can be used 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 SLAAC.  The M, O and A
   flags by
   different hosts. This would add additional complexity for both are advisory, not prescriptive.  For example, the M flag
   indicates that addresses are available from DHCPv6.  It does not
   indicate that hosts and the network management.

   This draft reviews the standard definition of are required to acquire addresses from DHCPv6.
   Similar statements can be made about the above mentioned
   flags, O and identifies the potential ambiguous behavior of
   interpreting these A flags. And then analyzes what operational problems
   might be caused by the ambiguous behavior.

   In most cases, the appendix, detailed test results of several major desktop M, O and A flags elicit identical behaviors from
   most popular operating systems' behavior of interpreting systems.  However, in several cases, the M, O
   and A flags are provided.
   According to elicit divergent behaviors.  For example, when a router
   changes the test results, we can see settings of the ambiguity problem is
   actually happening in current implementations.

2. Host Behavior Definition in Standards

   In this section, we analyzed A, M M, O, and O flags definition.

   Please note that, A flag has no direct relationship with DHCPv6, but from one RA message to
   the next, it is somewhat correlated with M and O flags.

2.1. A (Autonomous) Flag

   In ND Prefix Information Option, the autonomous address-configuration
   flag (A flag)is used likely to indicate whether this prefix can be used for
   SLAAC.

   For the elicit one behavior from hosts running one
   operating system and another behavior from hosts running a different
   operating system.

   This document describes divergent host behavior, there is an explicit rule behaviors observed in popular
   operating systems.  It also describes operational problems that
   divergent behaviors cause.

2.  The M, O and A Flags

   This section briefly reviews how the SLAAC
   specification [RFC4862]: "If the Autonomous M, O and A flags are defined in
   [RFC4861].

2.1.  M (Managed) Flag

   The M flag is not set, silently
   ignore indicates that addresses are available from IPv6.  If the Prefix Information option."

   But when A
   M flag is set, the SLAAC protocol didn't provide a
   prescriptive definition. (However, it is quite obvious that host
   should do SLAAC when A O flag is set.)

2.2. redundant and can be ignored because
   DHCPv6 will return all available configuration information.

   M (Managed) Flag

   In earlier SLAAC specification [RFC2462], the host behavior and A flag semantics are independent of
   interpreting one another.  The M flag is as below:

   "On receipt of a valid Router Advertisement, a host copies the value
   indicates that addresses are available from DHCPv6, regardless of the advertisement's M bit into ManagedFlag. If the value of
   ManagedFlag changes
   A flag setting.  The following setting are all allowed:

   o  M=0 A=0
   o  M=0 A=1

   o  M=1 A=0

   o  M=1 A=1

2.2.  O (Otherconfig) Flag

   The O flag indicates that other configuration information (e.g., DNS-
   related information) is available from FALSE to TRUE, and IPv6.  If the host M flag is not already
   running the stateful address autoconfiguration protocol, the host
   should invoke set,
   the stateful address auto-configuration protocol,
   requesting both address information O flag is redundant and other can be ignored because DHCPv6 will return
   all available configuration information. If the
   value

   O and A flag semantics are independent of the ManagedFlag changes one another.  The O flag
   indicates that other configuration is available 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 DHCPv6,
   regardless of the A 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.)" setting.  The following setting are all
   allowed:

   o  O=0 A=0

   o  O=0 A=1

   o  O=1 A=0

   o  O=1 A=1

2.3. O (Otherconfig)  A (Autonomous) Flag

   The situation of O A 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 indicates that the stateful autoconfiguration protocol, requesting
   information (excluding addresses if ManagedFlag prefix that is set to FALSE). If
   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 also carried by the PI
   option can be used for SLAAC.  A 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 semantics are independent of M
   and O flags
   in [RFC2462]:

   "In addition, when flag semantics.  The A flag indicates that the value prefix can be
   used by SLAAC, regardless 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." M and O flag settings.

3. Problems  Problem Statement

3.1.  Divergent 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. Behaviors

   The ambiguity is summarized as authors tested several popular operating systems in order to
   determine what behaviors the
   following aspects.

   #1 Dependency between DHCPv6 M, O and RA A flag elicit.  In standards, behavior of DHCPv6 some cases,
   the M, A 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 O flags are elicit identical behaviors from most popular
   operating systems.  However, in transition,
   e.g. several cases, the host is already SLAAC-configured, then M flag changes from
   FALSE to TRUE, it is M, O and A flags
   elicit divergent behaviors.  The table below characterizes those
   cases:

   Host State         Input  Behavior

   Host has 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       No RA  Some popular operating systems acquire
   acquired any              addresses from TRUE to FALSE, it is also not
   clear whether the host should turn DHCPv6 off or DHCPv6.  Others do not.

   #3 "Address Configuring Method" and "Address Lifetime"
   When one address configuration method is off, that is,
   addresses

   Host has not       RA     Some popular operating systems acquire
   acquired any       with   other information from DHCPv6, regardless
   addresses          M=0,   of the A flag or
   M flag changes setting. Others do so, but
                      O=1    only if A=1

   Host has acquired  RA     Some operating systems release DHCPv6
   addresses from TRUE to FALSE, it is not clear whether the host
   should immediately     with M addresses immediately. Some 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, DHCPv6
   DHCPv6 only (M =   =0     addresses when both M and O
   flags are TRUE, it is not clear whether the host should initiate one
   stateful they expire.
   1)

   Host has acquired  RA     Some operating systems acquire DHCPv6 session to get both address and info-configuration or
   initiate two independent sessions of which one is dedicated for
   address provisioning
   addresses from     with M addresses immediately.  Others do so only
   SLAAC only (A=1)   = 1    if their SLAAC addresses expire and cannot
                             be refreshed.

3.2.  Operational Problems

   This section describes operational issues caused by the divergent
   behaviors, described above.

3.2.1.  Inappropriate Sources

   Some operating systems base their decision to acquire configuration
   information upon inappropriate sources.  For example, some operating
   systems acquire other is for configuration information provision. When
   A if M = 0, O = 1, and
   A = 1, but not if M flags are FALSE = 0, 0 = 1 and O flag is TRUE, A = 0.  In other words, on some
   operating systems, it is not clear whether
   the host should initiate a stand-alone stateless impossible to acquire other information from
   DHCPv6 session.

3.2. Operational Problems Implication unless addresses are acquired from either DHCPv6 or SLAAC.

3.2.2.  Renumbering

   According to [RFC6879] a renumbering exercise can include the abovementioned host behavior ambiguity, there might
   be operational issues as the following.

3.2.1. Renumbering

   During IPv6 renumbering, the SLAAC-configured
   following steps:

   o  Causing hosts can reconfigure
   IP that have acquired addresses by receiving ND Router Advertisement (RA) messages
   containing from one
      autoconfiguration mechanism to release those addresses and acquire
      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 from another autoconfiguration mechanism

   o  Causing 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 that have acquired addresses from one
      autoconfiguration mechanism to current implementations, this requirement
   is not applicable release those addresses and has been identified as a gap in [RFC7010].

3.2.2. Cold Start Problem

   If all nodes, or many nodes, restart at acquire
      new addresses from the same time after a power
   cut, the results might not consistent.

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 autoconfiguration mechanism

   o  Causing hosts that have acquired addresses from one
      autoconfiguration mechanism to retain those addresses and acquire
      new addresses from another autoconfiguration mechanism

   Ideally, these steps could be initiated by broadcasting RA message
   onto the networks subnetwork that need some specific management patterns. Examples are:

   - is being renumbered.  Sadly, this is not
   possible, because the hosts RA message may elicit a different behavior from
   each host.  According to Section 3.1, renumbering operations would
   have been SLAAC-configured, then the network need the
   hosts to do following limitations:

   o  During a flash switch from 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 SLAAC, some operating systems
      release DHCPv6 acquired addresses (e.g.
   ULA), and immediately, while other will
      retain then until they also need to contact the DHCPv6 server for info-
   configuration.

4. Conclusions

   - The expire.  Therefore, results are
      unpredictable.

   o  On some operating systems, if a host behavior of SLAAC/DHCPv6 interaction is ambiguous in
   standard.

   - Varied behavior of implementations has been observed. In [RFC4862] acquired addresses from
      SLAAC, it is said "Removed the text regarding the M and O flags, considering
   the maturity of implementations and operational experiences." This
   consideration intended impossible to remain the ambiguity. But in the
   perspective acquire additional addresses from
      DHCPv6.  This may be required as part of operation, ambiguity normally is problematic.

   - It is foreseeable that the un-uniformed host behavior can cause
   operational problems.

5. a renumbering operation.

4.  Security Considerations

   No more

   As this memo does not introduce any new protocols or procedures, it
   does not introduce any new security considerations than the Neighbor Discovery protocol
   [RFC4861].

6. vulnerabilities.

5.  IANA Considerations

   None.

   This draft does not request any IANA action.

6.  Acknowledgements

   The authors wish to acknowledge BNRC-BUPT (Broad Network Research
   Centre in Beijing University of Posts and Telecommunications) for
   their testing efforts.  Special thanks to Xudong Shi, Longyun Yuan
   and Xiaojian Xue for their extraordinary effort.

   The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson,
   Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for
   their helpful comments.

7.  References

7.1.  Normative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [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.

7.2.  Informative References

   [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
             Autoconfiguration", RFC 2462, December 1998.

   [RFC3315] R.  Droms, R., 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", for IPv6", RFC 7010,
             September 2013. 3736, April 2004.

   [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.

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

A.1.  Test Results Environment

                                                /-----\
                 +---------+                  //       \\
                 |  DHCPv6 |                 |  Router   |
                 |  server |                  \\       //
                 +----+----+                    \--+--/
                      |                            |
                      |                            |
                      |                            |
                  ----+--+----------+----------+---+-----
                         |          |          |
                         |          |          |
                         |          |          |
                    +----+---+ +----+---+ +----+---+
                    |        | |        | |        |
                    |  Host1 Host 1 | |  Host2 Host 2 | |  Host3 Host 3 |
                    +--------+ +--------+ +--------+

                        Figure 1 1: Test Environment

   The 5 elements were all created in Vmware test environment depicted Figure 1 in one computer, for ease was replicated on a single
   server using VMware.  For simplicity of operation.

   - Router quagga operation, only one host was
   run at a time.  Network elements were as follows:

   o  Router: Quagga 0.99-19 soft router installed on Ubuntu 11.04
      virtual host
   -

   o  DHCPv6 Server: dibbler-server Dibbler-server installed on Ubuntu 11.04 virtual
      host
   -

   o  Host A 1: Window 7 / Window 8.1 Virtual Host
   -

   o  Host B 2: Ubuntu 12.10 14.04 (Linux Kernel 3.12.0) Virtual Host
   -

   o  Host C 3: Mac OS X v10.7 v10.9 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
   - Host D Android 4.0.4 (kernel: 3.0.16-gfa98030; device: HTC
     Incredible S)
   -

   o  Host E 4: IOS 6.1.3 8.0 (model: iPod Touch 4)
   (Note: The tested Android version didn't support DHCPv6, so the
   following results don't include Android.)

A.1.1 Apple iPhone 5S, connected via wifi)

A.2.  Host Initial Behavior

   When hosts are not configured yet, we tested their in the Initial State

   The bullet list below describes host behavior in the initial state,
   when
   receiving different A/M/O combinations. The results are as the
   following: host has not yet acquired any autoconfiguration information.
   Each bullet item represents an input and the behavior elicited by
   that input.

   o Window 7/Apple  A=0, M=0, O=0

      *  Windows 8.1 acquired addresses and other information from
         DHCPv6.

      *  All other hosts acquired no configuration information.

   o  A=0, M=0, O=1

      *  Windows 8.1 acquired addresses and other information from
         DHCPv6.

      *  Windows 7, OSX 10.9 and 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, 8.0 acquired other information from
         DHCPv6.

      *  Ubuntu 14.04 acquired no configuration information.

   o  A=0, M=1, O=0

      *  All hosts acquired addresses and other information from DHCPv6.

   o  A=0, M=1, O=1
      *  All hosts acquired addresses and other information from DHCPv6.

   o  A=1, M=0, O=0

      *  Windows 8.1 acquired addresses from SLAAC + DHCPv6
     - A=1&M=1&O=1, and DHCPv6.  It also
         acquired non-address information from DHCPv6.

      *  All the other host acquired addresses from 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,  A=1, M=0, O=1

      *  Windows 8.1 acquired addresses from SLAAC only
     - A=1&M=0&O=1, and DHCPv6.  It also
         acquired other information from DHCPv6.

      *  All the other hosts acquired addresses from SLAAC + Stateless DHCPv6
     - A=1&M=1&O=0, and other
         information from DHCPv6.

   o  A=1, M=1, O=0

      *  All hosts acquired addresses from SLAAC + DHCPv6
     - A=1&M=1&O=1, and DHCPv6.  They also
         acquired other information from DHCPv6.

   o  A=1, M=1, O=1

      *  All hosts acquired addresses from 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 and DHCPv6.  They also
         acquired other information from DHCPv6.

   As showed above, Linux four inputs result in divergent behaviors.

A.3.  Host Behavior in State Transitions

   The bullet list below describes behavior elicited during state
   transitions.  The value x can represents both 0 and MAC OSX acted 1.

   o  Old state (M = x, O = x, A = 1) , New state (M = x, O = x, A = 0)
      (This means a SLAAC-configured host, which is regardless of DHCPv6
      configured or not, reveiving A transitiong from 1 to 0. )

      *  All the same way, but are
   different hosts retain SLAAC addresses until they expire

   o  Old state (M = 0, O = x, A = 1), New state (M = 1, O = x, A = 1)
      (This means a SLAAC-only host receiving M transisioning from 0 to
      1.)

      *  Windows 7 and Apple IOS. The acquires addresses from DHCPv6, immediately.

      *  Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6
         only difference is when
   A=0&M=0&O=1, if the SLAAC addresses are allowed to expire

      *  Windows 7/Apple IOS did stateless 8.1 was not tested because it always acquire addresses
         from DHCPv6 while Linux/MAC
   OSX did nothing.

A.1.2 Host Behavior in Flags Transition regardless of the M flag setting.

   o SLAAC-only  Old state (M = 1, O = x, A = x), New state (M = 0, O = x, A = x)
      (This means a DHCPv6-configured host receiving M=1
     - Window M transitioning
      from 1 to 0.)

      *  Windows 7 would initiate immediately released the DHCPv6
     - Linux/MAC/IOS would address

      *  Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep SLAAC and don't initiate the DHCPv6 unless
     SLAAC is expired and no continuous RAs
         addresses until they expire

   o  Old state (M = 1, O = x, A = 0), New state (M = 1, O = x, A = 1)
      (This means a DHCPv6-only host receiving A=1
     - They all do SLAAC

   o Stateless DHCPv6-configured A transisioning from 0 to
      1.)

      *  All 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 acquire addresses from SLAAC

   o Statefull  Old state (M = 0, O = 1, A = x), New state (M = 1, O = 1, A = x)
      (This means a Stateless DHCPv6-configured host [RFC3736], which is
      regardless of SLAAC configured or not, receiving M=0 (while M transisioning
      from 0 to 1 with keeping O=1)
     - Window O=1 )

      *  Windows 7 would release all DHCPv6 configurations including
     address acquires addresses and refreshes other information, and initiate stateless information
         from DHCPv6
     - Linux/MAC/IOS no action

A.2 Observations

      *  Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing

      *  Windows 8.1 was not tested because it always acquire addresses
         from DHCPv6 regardless of the Test M flag setting.

   o  Old state (M = 1, O = 1, A flag = x), New state (M = 0, O = 1, A flag is = x)
      (This means a switch to control whether to do SLAAC, and it Stateful DHCPv6-configured host, which is
   independent with regardless
      of SLAAC configured or not, receiving M transisioning from 0 to 1
      with keeping O=1 )

      *  Windows 7 released all DHCPv6 addresses and O flags, in another word, A refreshes all
         DHCPv6 other information.

      *  Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing

Appendix B.  Analysis of the Ambiguities

   Following is independent
   with DHCPv6.

   At a comprehensive analysis of the non-SLAAC-configured state (either non-configured or DHCPv6-
   configured only), ambiguities as defined
   in the standards.  In theory, all the operating systems acted ambiguities might cause
   divergent host behavior.  Some of the same way in
   interpreting A flag. If A flag divergence has been identified
   by the tests while some haven't.  It is TRUE, they worth to document all configure SLAAC, the
   ambiguities.

   1.  Dependency between DHCPv6 and RA

      In standards, behavior of DHCPv6 and Neighbor Discovery protocols
      is specified respectively.  But it is obvious and reasonable.

   o M flag

   M not clear that whether there
      should be any dependency between them.  More specifically, is a key flag RA
      (with M=1) required to interact ND and DHCPv6, but trigger DHCPv6?  If there are no RAs at
      all, should hosts initiate DHCPv6 by themselves?

   2.  Behaviors of Flag Transition

      When flags are in transition, e.g. the host behaviors on is already SLAAC-
      configured, then M flag were quite different.

   At changes from FALSE to TRUE, it is not
      clear whether the initialing state, some operating systems would start DHCPv6
   only if receiving an RA message with M flag set while some would
   initially host should start DHCPv6 if RAs are absent. This result reflects 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
   ambiguity problem of #1 Dependency between host
      should turn DHCPv6 off or not.

   3.  Distinction between "Address Configuring Method" and RA in above
   text. "Address
       Lifetime"

      When one address configuration method is off, that is, the hosts are SLAAC-configured, and then the A flag
      or M flag changes from
   FALSE TRUE to TRUE, some operating systems would initiate DHCPv6 while
   some would not. This reflects FALSE, it is not clear whether the
      host should immediately release the problem #2 Advisory corresponding address(es) or Prescriptive.

   o O flag

   In
      just retain it(them) until expired.

   4.  Dependencies between the flags

      The semantics of the flags seems not totally independent, but the test,
      standards didn't clearly clarify it.  For example, when both M flag is set, the and
      O flag flags are TRUE, it is implicitly set as well;
   in another word, the hosts would not initial clear whether the host should initiate
      one stateful DHCPv6 session to get both address and
   stateless DHCPv6 respectively. This info-
      configuration or initiate two independent sessions of which one is a reasonable behavior.

   But
      dedicated for address provisioning and the O flag other is not independent from A flag in some operating
   systems, which won't initiate stateless DHCPv6 when for
      information provision.  When A and M flags are FALSE and O flag is FALSE.
   That is to say,
      TRUE, it is not applicable to have clear whether the host should initiate 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 stand-
      alone stateless DHCPv6 (according to O flag changing from TRUE
   to FALSE or vice versa). This reflects the problem #4 Dependencies
   between the flags. session.

Authors' Addresses

   Bing Liu
   Q14-4-A Building
   Huawei Technologies Co., Ltd
   Zhong-Guan-Cun Environment Protection Park,
   Q14, Huawei Campus, No.156 Beiqing Rd. Road
   Hai-Dian District, Beijing Beijing, 100095
   P.R. China

   Email: leo.liubing@huawei.com
   Sheng Jiang
   Huawei Technologies
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: jiangsheng@huawei.com

   Ron Bonica
   Juniper Networks
   Sterling, Virginia
   20164
   USA

   Email: rbonica@juniper.net

   Xiangyang Gong
   BUPT University
   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
   BUPT University
   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