V6OPSNetwork Working Group                                          B. Liu
Internet-Draft
Internet Draft                                    Huawei Technologies Co., Ltd
Intended status: Informational                              R. Bonica
Expires: May 30, December 20, 2014                           Juniper Networks
                                                             S. Jiang
                                                  Huawei Technologies Co., Ltd
                                                              X. Gong
                                                              W. Wang
                                                      BUPT University
                                                       November 26, 2013
                                                        June 18, 2014

      DHCPv6/SLAAC Address Configuration Interaction Problem Statement
                draft-ietf-v6ops-dhcpv6-slaac-problem-00

Abstract

   This document analyzes the DHCPv6/SLAAC interaction issue on host.
   More specifically, the interaction is regarding with the A, M, and O
   flags defined in ND protocol. Test results identify that current
   implementations in operating systems have varied on interpreting
   these flags. The variation might cause some operational issues as
   described in the document.
               draft-ietf-v6ops-dhcpv6-slaac-problem-01.txt

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 May 30, December 18, 2014.

Copyright Notice

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

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2 ................................................. 3
   2. Host Behavior of DHCPv6/SLAAC Interaction . . . . . . . . . .   3
     2.1.  Relevant RA Flags Defined Definition in Standards  . . . . . . . . . ........................ 3
       2.1.1.
      2.1. A (Autonomous) Flag . . . . . . . . . . . . . . . . .   3
       2.1.2. ..................................... 4
      2.2. M (Managed) Flag  . . . . . . . . . . . . . . . . . .   3
       2.1.3. ........................................ 4
      2.3. O (Otherconfig) Flag  . . . . . . . . . . . . . . . .   4
     2.2.  Behavior of Current Implementations . . . . . . . . . . . .................................... 4
       2.2.1.  A flag  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.2.  M flag  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.3.  O flag  . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Possible Operational Issues of DHCPv6/SLAAC Interaction . . . Problems Statement ........................................... 5
      3.1.  Renumbering . . . . . . . . . . . . . . . . . . . . . . . Host Behavior Ambiguity ................................. 5
      3.2. Operational Problems Implication ........................ 6
         3.2.1. Renumbering ........................................ 6
         3.2.2. Cold Start Problems . . . . . . . . . . . . . . . . . . . Problem ................................. 6
     3.3.  Strong
         3.2.3. Specific Management . . . . . . . . . . . . . . . . . . . .   6 Patterns ....................... 7
   4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   6 .................................................. 7
   5. Security Considerations . . . . . . . . . . . . . . . . . . . ...................................... 7
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .......................................... 7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . ................................................... 7
     8.1.
      7.1. Normative References  . . . . . . . . . . . . . . . . . . .................................... 7
     8.2.
      7.2. Informative References  . . . . . . . . . . . . . . . . .   7 .................................. 8
   8. Acknowledgments .............................................. 8
   Appendix A. Test Details Results of Host Behaviors . . . . . . . . . . .   8
     A.1. Behavior ....................... 9
      A.1 Detailed Test Results .................................... 9
         A.1.1 Host Transition Initial Behavior  . . . . . . . . . . . . . . . . .............................. 10
     A.2.
         A.1.2 Host Stateful/Stateless DHCPv6 Behavior . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . in Flags Transition .................. 10
      A.2 Observations from the Test .............................. 11

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 (, (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 available when in the flag
   is set. network
   or not. And there is an O (OtherConfig) flag flag, if set, indicating
   configure information other than addresses (e.g. DNS, Route .etc) is
   available through DHCPv6 configuration when it is set. configuration. Moreover, there's another A
   (Autonomous) flag defined in ND, which indicating the hosts to do SLAAC. SLAAC,
   may also influent the behavior of hosts.

   So with these flags, the two address configuration methods mechanisms are
   somehow correlated. But for some reasons, the ND protocol didn't
   define the flags as prescriptive but only advisory. This means the ambiguous
   definition
   is more or less ambiguous, and hosts might vary the behavior of interpreting the flags because of by
   different hosts. This would add additional complexity for both the ambiguity.  In
   hosts and the appendix, we
   provided test results to identify different host operating systems
   have taken different approaches. network management.

   This might cause some 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
   issues as analyzed 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 section 3. current implementations.

2. Host Behavior of DHCPv6/SLAAC Interaction Definition in Standards

   In this section, we analyze analyzed A, M, M and O flags definition, and briefly
   point out some important test results of host behavior of
   interpreting these flags in mainstream operating systems
   implementations. definition.

   Please note that, A flag has no direct relationship with DHCPv6, but
   it is somewhat correlated with M and O flags.

2.1.  Relevant RA Flags Defined in Standards

2.1.1. A (Autonomous) Flag

   In ND Prefix Information Option, when the autonomous address-
   configuration address-configuration
   flag (A flag) is set, it indicates that 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.  It (However, it is not clear the quite obvious that host "could"
   should do SLAAC
   or "must" do.

2.1.2. 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 current 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.1.3. deprecated.)"

2.3. O (Otherconfig) Flag

   As mentioned above, the

   The situation of O flag is similar with M. 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
   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 implicitly 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."

2.2.

3. Problems Statement

3.1. Host Behavior of Current Implementations

   We did tests of current mainstream desktop/mobile operating systems'
   behavior (please refer to Ambiguity

   The main problem is standard definition ambiguity which means, on
   interpreting the appendix same messages, different hosts might behave
   differently. Thus it could be un-controlled or un-predictable for details).  This section
   only briefly illustrates
   administrators on some important results.

2.2.1.  A flag

   A flag operations. The ambiguity is a switch to control whether to do SLAAC, 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
   independent with M/O flags, in another word, A not clear that whether there should
   be any dependency between them.

   More specifically, is independent with
   DHCPv6.

   At the non-SLAAC-config state (including DHCPv6-only-configured), all
   the OSes acted 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 same with A flag, if A set, they all configured
   SLAAC, it is obvious and reasonable.  But flags as advisory while others might
   interpret them prescriptive. Especially when hosts flags are SLAAC-
   configured, and A changed from 1 to 0, the behavior varied, some
   deprecated SLAAC while some ignored in transition,
   e.g. the RA messages.

2.2.2.  M flag

   M host is a key already SLAAC-configured, then M flag changes from
   FALSE to correlate ND and DHCPv6, but TRUE, it is not clear whether the host behavior on 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 quite different.

   In our test, there was also not
   clear whether the host should turn DHCPv6 off or not.

   #3 "Address Configuring Method" and "Address Lifetime"
   When one OS treating address configuration method is off, that is, the A flag as prescriptive, or
   M flag changes from TRUE to FALSE, it
   even released DHCPv6 session when M=0.  But is not clear whether the others just treat host
   should immediately release the
   flag as advisory, when SLAAC was done, it won't care about M=1, and
   M=0 won't cause operation for corresponding address(es) or just
   retain it(them) until expired.

   #4 Dependencies between the already configured DHCPv6
   addresses.  Moreover, flags

   The semantics of the two OSes even would flags seems not initiate DHCPv6
   session until they receives RA messages with M=1, this behavior has
   an implication that DHCPv6 somehow depends on ND.

2.2.3.  O flag

   In our tests, totally independent, but the
   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 reasonable behavior.

   But dedicated for
   address provisioning and the O flag could be influented by other is for information provision. When
   A flag in some OSes.  In our
   test, there and M flags are two OSes that won't initiate stateless DHCPv6 when A FALSE and O flag is not set, 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 two OSes to switch
   between stateful DHCPv6 and stand-alone stateless DHCPv6 (according to O flag
   changing from 0 to 1 or verse vice).

3.  Possible session.

3.2. Operational Issues of DHCPv6/SLAAC Interaction Problems Implication

   According to the abovementioned tests, host behavior ambiguity, there are possible might
   be operational issues as the following.

3.1.

3.2.1. Renumbering

   During IPv6 renumbering, the SLAAC-configured hosts could can reconfigure
   IP addresses by receiving ND Router Advertisement (RA) messages
   containing new prefix information. The DHCPv6-configured hosts could can
   reconfigure addresses by initialing RENEW sessions when the current
   addresses' lease time is expired or receiving the reconfiguration
   messages initiated initialed by the DHCPv6 servers.

   So renumbering won't be a problem when SLAAC-configured

   The above mechanisms have an implicit assumption that SLAAC-
   configured hosts would will remain SLAAC configuration as well as while DHCPv6-managed hosts remaining
   DHCPv6. will
   remain DHCPv6-managed. But in some situations, SLAAC-configured hosts
   might need to switch to DHCPv6-managed, or verse vice. 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.

3.2.2. Cold Start Problems Problem

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

3.3.  Strong

3.2.3. Specific Management Patterns

   Since the host behavior of address configuration is un-controlled and
   un-predictable somehow un-
   controlled by the network side, it might cause gaps to the
   networks that need strong management (for example, the enterprise
   networks and the ISP CPE networks).  Examples are:

   o  the administrator wants the hosts to do DHCPv6-only configuration,
      it is not applicable for some operating systems due cause gaps to current
      implementation unless manually configure the hosts to DHCPv6-only
      model

   o networks
   that need some specific management patterns. Examples are:

   - the hosts have been SLAAC-configured, then the administrator wants network need the
   hosts to do DHCPv6 simultaneously (e.g. for multihoming)

   o multihoming).
   - the administrator network wants the hosts to do statelss DHCPv6-only; 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
   configuration.

4. Conclusions

   o

   - The host behavior of SLAAC/DHCPv6 interaction is ambiguous in
   standard.

   o  The

   - Varied behavior of implementations have has been varied on this issue. observed. In [RFC4862]
   it is said "Removed the text regarding the M and O flags, considering
   the maturity of implementations and operational experiences."  The description seems not true anymore.

   o 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 issues, e.g. in renumbering and strong management. problems.

5. Security Considerations

   No more security considerations than the Neighbor Discovery protocol
   [RFC4861].

6. IANA Considerations

   This draft does not request any IANA action.

   None.

7.  Acknowledgements

   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 the
   student Xudong Shi and Longyun Yuan.

   Valuable comment was received from Brian E Carpenter, Mikael
   Abrahamsson, Dave Thaler, Lee Howard .etc to improve the draft.

   This document was produced using the xml2rfc tool [RFC2629].

8. References

8.1.

7.1. Normative References

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

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

8.2.

7.2. Informative References

   [I-D.liu-6renum-dhcpv6-slaac-switching]
              Liu, B., Wang, W., and X. Gong, "DHCPv6/SLAAC Address
              Configuration Switching for Host Renumbering", draft-liu-
              6renum-dhcpv6-slaac-switching-02 (work in progress),
              January 2013.

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

   [RFC6879]  Jiang, S., Liu, B., and B.

   [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
             (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC5887] Carpenter, "IPv6 Enterprise
              Network Renumbering Scenarios, Considerations, B., Atkinson, R., and
              Methods", H. Flinck, "Renumbering
             Still Needs Work", RFC 6879, February 2013. 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.

Appendix A. Test Details of Host Behaviors 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.

   o

   - Router quagga 0.99-19 soft router installed on Ubuntu 11.04
     virtual host

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

   o
   - Host A Window 7 Virtual Host

   o
   - Host B Ubuntu 12.10 Virtual Host

   o
   - 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):

   o

   - Router quagga 0.99-17 soft router installed on Ubuntu 12.10

   o
   - DHCPv6 Server: dibbler-server installed on Ubuntu 12.10

   o
   - Host D Android 4.0.4 (kernel: 3.0.16-gfa98030; device: HTC
     Incredible S)

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

A.1.1 Host Initialing Initial Behavior

   Host from non-configured to configured,

   When hosts are not configured yet, we tested their behavior when
   receiving different A/M/O
   combinations in each OS platform. combinations. The states results are enumerated as the
   following, 3 operation systems respectively:
   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 differated 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.

   Result summary:

   o  A is interpreted as prescript in each OS at the initial state

   o  M is interpreted as prescript in each OS at the initial state

   o  O is interpreted as prescript in Windows 7

   o  A and M are independent in each OS at the initial state

   o  A and O are not totally independent in Linux and Mac, A=1 is
      required for O=1 triggering DHCPv6 info-request

   o  M and O are not totally independent in each OS.  M=1 has the
      implication O=1

A.1.

A.1.2 Host Transition Behavior in Flags Transition

   o SLAAC-only host receiving A=0&M=1

      * M=1
     - Window 7 would deprecate SLAAC and initiate DHCPv6

      *
     - Linux/MAC/IOS would keep SLAAC and don't initiate DHCPv6 unless
     SLAAC is expired and no continuous RA RAs

   o DHCPv6-only host receiving A=1&M=0

      * A=1
     - 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 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 and do SLAAC

      *  Linux/MAC/IOS
   only if receiving an RA message with M flag set while some would keep
   initially start DHCPv6 if RAs are absent. This result reflects the
   ambiguity problem of #1 Dependency between DHCPv6 and do SLAAC RA in above
   text.

   When the host has been configured, either by SLAAC or DHCPv6, hosts are SLAAC-configured, and then the M flag changes from
   FALSE to TRUE, some operating systems interpreting would initiate DHCPv6 while
   some would not. This reflects the problem #2 Advisory or Prescriptive.

   o O flag

   In the test, when M flag quite differently.  Windows
   7 treats is set, the O flag is implicitly set as instruction, it even released well;
   in another word, the hosts would not initial stateful DHCPv6 session
   when M=0.  Linux and OS X were likely to treat
   stateless DHCPv6 respectively. This is a reasonable behavior.

   But the O flag as advisory,
   when SLAAC was done, it won't care about M=1, and M=0 is not independent from A flag in some operating
   systems, which won't cause
   operation for the already configured initiate stateless DHCPv6 addresses.

   Please refer when A flag is FALSE.
   That is to [I-D.liu-6renum-dhcpv6-slaac-switching] for more
   details.

A.2.  Host Stateful/Stateless say, it is not applicable to have a "stateless DHCPv6 Behavior

   o  Stateless DHCPv6-configured host receiving M=1 (while keeping O=1)

      *  Window 7 would initiate
   only" configuration state for some operating systems; it is also not
   applicable for these operating systems to switch between 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 (according to O flag changing from TRUE
   to FALSE or vice versa). This reflects the problem #4 Dependencies
   between the flags.

   Authors' Addresses

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

   Email: leo.liubing@huawei.com

   Ron Bonica
   Juniper Networks
   Sterling, Virginia  20164
   USA

   Email: rbonica@juniper.net

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: jiangsheng@huawei.com

   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