[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-liu-bonica-v6ops-dhcpv6-slaac-problem) 00 01 02 03 04 05 06 07

V6OPS                                                             B. Liu
Internet-Draft                                                  S. Jiang
Intended status: Informational                       Huawei Technologies
Expires: November 3, 2015                                        X. Gong
                                                                 W. Wang
                                                         BUPT University
                                                             May 2, 2015


    DHCPv6/SLAAC Interaction Problems on Address Auto-configuration
                draft-ietf-v6ops-dhcpv6-slaac-problem-04

Abstract

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

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

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 November 3, 2015.

Copyright Notice

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



Liu, et al.             Expires November 3, 2015                [Page 1]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The M, O and A Flags  . . . . . . . . . . . . . . . . . . . .   3
     2.1.  M (Managed) Flag  . . . . . . . . . . . . . . . . . . . .   3
     2.2.  O (Otherconfig) Flag  . . . . . . . . . . . . . . . . . .   4
     2.3.  A (Autonomous) Flag . . . . . . . . . . . . . . . . . . .   4
   3.  Behavior Ambiguity Analysis . . . . . . . . . . . . . . . . .   4
   4.  Observed Divergent Host Behaviors . . . . . . . . . . . . . .   5
   5.  Operational Problems  . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Inappropriate Sources . . . . . . . . . . . . . . . . . .   6
     5.2.  Renumbering Issues  . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Test Results . . . . . . . . . . . . . . . . . . . .   8
     A.1.  Test Environment  . . . . . . . . . . . . . . . . . . . .   8
     A.2.  Host Behavior in the Initial State  . . . . . . . . . . .   9
     A.3.  Host Behavior in State Transitions  . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   IPv6 [RFC2460] hosts invoke Neighbor Discovery (ND) [RFC4861]
   procedures in order to discover which auto-configuration mechanisms
   are available to them.  The following is a list of auto-configuration
   mechanisms:

   o  DHCPv6 [RFC3315]

   o  Stateless Address Autoconfiguration (SLAAC) [RFC4862]

   ND specifies an ICMPv6 [RFC4443] Router Advertisement (RA) message.
   Routers periodically broadcast the RA message to all on-link nodes.
   They also unicast RA messages in response to solicitations.  The RA
   message contains:




Liu, et al.             Expires November 3, 2015                [Page 2]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


   o  an M (Managed) flag

   o  an O (OtherConfig) flag

   o  zero or more Prefix Information (PI) Options

   The M flag indicates that addresses are available from DHCPv6.  The O
   flag indicates that other configuration information (e.g., DNS-
   related information) is available from DHCPv6.  The PI Option
   includes a prefix, an A (Autonomous) flag and other fields.  The A
   flag indicates that the prefix can be used for SLAAC.  The M and O
   flags are advisory, not prescriptive (although A flag is also
   advisory in definition in standard, it is quite prescriptive in
   implementations).  For example, the M flag indicates that addresses
   are available from DHCPv6.  It does not indicate that hosts are
   required to acquire addresses from DHCPv6.  Similar statements can be
   made about the O flag.

   Because of the advisory definition of the flags, in some cases
   different operating systems appear divergent behaviors.  This
   document analyzes possible divergent host behaviors might happen
   (some of the possible divergent behaviors are already observed in
   popular operating systems) and the operational problems might caused
   by divergent behaviors.

2.  The M, O and A Flags

   This section briefly reviews how the M, O and A flags are defined in
   [RFC4861].

2.1.  M (Managed) Flag

   The M flag indicates that addresses are available from DHCPv6.  If
   the M flag is set, the O flag is redundant and can be ignored because
   DHCPv6 will return all available configuration information.

   M and A flag semantics are independent of one another.  The M flag
   indicates that addresses are available from DHCPv6, regardless of the
   A flag setting.  The following settings are all allowed:

   o  M=0 A=0

   o  M=0 A=1

   o  M=1 A=0

   o  M=1 A=1




Liu, et al.             Expires November 3, 2015                [Page 3]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


2.2.  O (Otherconfig) Flag

   The O flag indicates that other configuration information (e.g., DNS-
   related information) is available from DHCPv6.  If the M flag is set,
   the O flag is redundant and can be ignored because DHCPv6 will return
   all available configuration information.

   O and A flag semantics are independent of one another.  The O flag
   indicates that other configuration is available from DHCPv6,
   regardless of the A flag setting.  The following settings 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.  A (Autonomous) Flag

   The A flag indicates that the prefix that is also carried by the PI
   option can be used for SLAAC.  A flag semantics are independent of M
   and O flag semantics.  The A flag indicates that the prefix can be
   used by SLAAC, regardless of the M and O flag settings.

3.  Behavior Ambiguity Analysis

   The flags definition ambiguity 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, it is
      unclear whether RA (with M=1) is required to trigger DHCPv6; in
      other words, It is unclear whether hosts should initiate DHCPv6 by
      themselves If there are no RAs at all.

   2) Interpretation on Flags Transition

      When flags are in transition, e.g. the host is already SLAAC-
      configured, then M flag changes from FALSE to TRUE, it is not
      clear whether the host should start DHCPv6 or not; or vise versa,



Liu, et al.             Expires November 3, 2015                [Page 4]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


      the host is already both SLAAC/DHCPv6 configured, then M flag
      change from TRUE to FALSE, it is also not clear whether the host
      should turn DHCPv6 off or not.

   3) Relationship between Address Configuring Method and Address
   Lifetime

      When one address configuration method is off, that is, the A flag
      or M flag changes from TRUE to FALSE, it is not clear whether the
      host should immediately 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, when both M and
      O flags are TRUE, it is not clear whether the host should initiate
      one stateful DHCPv6 session to get both address and info-
      configuration or initiate two independent sessions (one is
      dedicated for address configuration and the other is for
      information configuration).  When A and M flags are FALSE and O
      flag is TRUE, it is not clear whether the host should initiate a
      stand-alone stateless DHCPv6 session.

   Divergent behaviors on all the four aspects have been observed among
   some popular operating systems as described in Section 4 below.

4.  Observed Divergent Host Behaviors

   The authors tested several popular operating systems in order to
   determine what behaviors the M, O and A flag elicit.  In some cases,
   the M, O and A flags elicit divergent behaviors.  The table below
   characterizes those cases.  For test details, please refer to
   Appendix A.

















Liu, et al.             Expires November 3, 2015                [Page 5]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


   Host State         Input  Behavior

   Host has not       No RA  Some popular operating systems acquire
   acquired any              addresses from DHCPv6.  Others do not.
   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 setting. Others do so, but
                      O=1    only if A=1

   Host has acquired  RA     Some operating systems release DHCPv6
   addresses from     with M addresses immediately. Some release DHCPv6
   DHCPv6 only (M =   =0     addresses when they expire.
   1)

   Host has acquired  RA     Some operating systems acquire DHCPv6
   addresses from     with M addresses immediately. Others do so only if
   SLAAC only (A=1)   = 1    their SLAAC addresses expire and cannot be
                             refreshed.

5.  Operational Problems

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

5.1.  Inappropriate Sources

   Some operating systems base their decision to acquire configuration
   information upon inappropriate sources.  For example, some operating
   systems acquire other configuration information if M=0, O=1, and A=1,
   but not if M=0, O=1 and A=0.  In other words, on some operating
   systems, it is impossible to acquire other information from DHCPv6
   (stateless DHCPv6 configuration) unless addresses are acquired from
   either DHCPv6 or SLAAC.

5.2.  Renumbering Issues

   According to [RFC6879] a renumbering exercise can include the
   following steps:

   o  Causing hosts that have acquired addresses from one auto-
      configuration mechanism to release those addresses and acquire new
      addresses from another auto-configuration mechanism

   o  Causing hosts that have acquired addresses from one auto-
      configuration mechanism to release those addresses and acquire new
      addresses from the same auto-configuration mechanism



Liu, et al.             Expires November 3, 2015                [Page 6]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


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

   Ideally, these steps could be initiated by broadcasting RA message
   onto the subnetwork that is being renumbered.  Sadly, this is not
   possible, because the RA message may elicit a different behavior from
   each host.  According to Section 4, renumbering operations would have
   the following limitations:

   o  When M flag is turned off, some operating systems release DHCPv6
      acquired addresses immediately, while other will retain then until
      they expire.  This means a flash switch from DHCPv6 to SLAAC would
      happen on some hosts.  Normally, the "make-before-break" approach
      proposed in [RFC4192] is considered better than flash renumbering.

   o  On some operating systems, if a host has acquired addresses from
      SLAAC, it is impossible to acquire additional addresses from
      DHCPv6.  This may be required as part of a renumbering operation.

6.  Security Considerations

   As this memo does not introduce any new protocols or procedures, it
   does not introduce any new security vulnerabilities.

7.  IANA Considerations

   This draft does not request any IANA action.

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

   Special thanks to Ron Bonica who made a lot of significant
   contribution to this draft, including draft editing and presentations
   which dramatically improved this work.

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








Liu, et al.             Expires November 3, 2015                [Page 7]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


9.  References

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

9.2.  Informative References

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

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC6879]  Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
              Network Renumbering Scenarios, Considerations, and
              Methods", RFC 6879, February 2013.

Appendix A.  Test Results

A.1.  Test Environment













Liu, et al.             Expires November 3, 2015                [Page 8]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


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

                        Figure 1: Test Environment

   The test environment depicted Figure 1 in was replicated on a single
   server using VMware.  For simplicity of 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 installed on Ubuntu 11.04 virtual
      host

   o  Host 1: Window 7 / Window 8.1 Virtual Host

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

   o  Host 3: Mac OS X v10.9 Virtual Host

   o  Host 4: IOS 8.0 (model: Apple iPhone 5S, connected via wifi)

A.2.  Host Behavior in the Initial State

   The bullet list below describes host behavior in the initial state,
   when the host has not yet acquired any auto-configuration
   information.  Each bullet item represents an input and the behavior
   elicited by that input.

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

      *  Windows 8.1 acquired addresses and other information from
         DHCPv6.



Liu, et al.             Expires November 3, 2015                [Page 9]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


      *  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 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 and DHCPv6.  It also
         acquired non-address information from DHCPv6.

      *  All the other host acquired addresses from SLAAC

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

      *  Windows 8.1 acquired addresses from SLAAC and DHCPv6.  It also
         acquired other information from DHCPv6.

      *  All the other hosts acquired addresses from SLAAC and other
         information from DHCPv6.

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

      *  All hosts acquired addresses from SLAAC and DHCPv6.  They also
         acquired other information from DHCPv6.

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

      *  All hosts acquired addresses from SLAAC and DHCPv6.  They also
         acquired other information from DHCPv6.

   As showed above, four inputs result in divergent behaviors.





Liu, et al.             Expires November 3, 2015               [Page 10]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


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 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, receiving A in transition from 1 to 0. )

      *  All the 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 in transition from 0 to
      1.)

      *  Windows 7 acquires addresses from DHCPv6, immediately.

      *  Ubuntu 14.04/OSX 10.9/IOS 8.0 acquires addresses from DHCPv6
         only if the SLAAC addresses are allowed to expire

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

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

      *  Windows 7 immediately released the DHCPv6 address

      *  Windows 8.1/Ubuntu 14.04/OSX 10.9/IOS 8.0 keep the DHCPv6
         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 in transition from 0 to
      1.)

      *  All host acquire addresses from SLAAC

   o  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 in transition
      from 0 to 1 with keeping O=1 )

      *  Windows 7 acquires addresses and refreshes other information
         from DHCPv6

      *  Ubuntu 14.04/OSX 10.9/IOS 8.0 does nothing




Liu, et al.             Expires November 3, 2015               [Page 11]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


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

   o  Old state (M = 1, O = 1, A = x), New state (M = 0, O = 1, A = x)
      (This means a Stateful DHCPv6-configured host, which is regardless
      of SLAAC configured or not, receiving M in transition from 0 to 1
      with keeping O=1 )

      *  Windows 7 released all DHCPv6 addresses and refreshes all
         DHCPv6 other information.

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

Authors' Addresses

   Bing Liu
   Huawei Technologies
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, 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


   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









Liu, et al.             Expires November 3, 2015               [Page 12]


Internet-Draft  draft-ietf-v6ops-dhcpv6-slaac-problem-04        May 2015


   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










































Liu, et al.             Expires November 3, 2015               [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/