Skip to main content

DHCPv6/SLAAC Address Configuration Switching for Host Renumbering
draft-liu-6renum-dhcpv6-slaac-switching-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Bing Liu
Last updated 2012-07-09
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-6renum-dhcpv6-slaac-switching-00
Network Working Group                                           B. Liu
Internet Draft                            Huawei Technologies Co., Ltd
Intended status: Proposed Standard                        July 9, 2012
Expires: January 7, 2013

     DHCPv6/SLAAC Address Configuration Switching for Host Renumbering
               draft-liu-6renum-dhcpv6-slaac-switching-00.txt

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list of current Internet-Drafts is
   at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2013.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   Sometimes stateful DHCPv6 address configuration and SLAAC may be both
   available in one network. In ND protocol, there is a M (ManagedFlag)
   flag defined in RA message, which indicates the hosts the DHCPv6
   service is availeble. But for some reason, the ND protocol didn't

Bing Liu                Expires January 2013                 [Page 1]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

   define the flag as prescriptive but only advisory. This draft
   proposes to use two reserved bits in RA message to let the network
   control the hosts that which address configuration mode should be
   used. This feature is useful for management, especially in a
   renumbering event.

Table of Contents

   1. Introduction ................................................. 3
   2. DHCPv6/SLAAC interaction ..................................... 3
      2.1. Host behavior defined in standards ...................... 3
      2.2. Test of desktop operating systems' behavior ............. 4
         2.2.1. Test environment ................................... 4
         2.2.2. Test scenarios and results ......................... 5
         2.2.3. Conclusion.......................................... 6
   3. Requirement of Address Configuration Switching in Renumbering                                                                       . 6
   4. Proposed Standard Update  .................................... 7
      4.1. Adding a "DHCPv6Required" Flag .......................... 7
      4.2. Adding a "ReleaseDHCPv6" Flag ........................... 7
      4.3. Host Behavior of Interpreting D/R Flag .................. 7
   5. Security Considerations ...................................... 8
   6. IANA Considerations .......................................... 8
   7. References ................................................... 8
      7.1. Normative References .................................... 8
      7.2. Informative References .................................. 8
   8. Acknowledgments .............................................. 8
   Authors' Addresses .............................................. 9

Bing Liu               Expires January 7 2013                [Page 2]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

1. Introduction

   In IPv6, both of the DHCPv6 [RFC3315] and Neighbor Discovery [RFC4861]
   protocols can provide automatic IP address configuration for the
   hosts. They are known as stateful address auto-configuration and
   SLAAC (stateless address auto-configuration)[RFC4862], and are
   suitable for different scenarios respectively.

   Sometimes the two address configuration modes may be both available
   in one network. This would add more or less additional complexity for
   both the hosts and the network management. In ND protocol, there is a
   M (ManagedFlag) flag defined in RA message, which indicates the hosts
   the DHCPv6 service status in the network. So with using the flag, the
   two separated address configuration modes are somehow correlated. But
   for some reason, the ND protocol didn't define the flag as
   prescriptive but only advisory. This may vary the behavior of hosts
   when interpreting the M flag. (Note that, there is another O
   "OtherConfigFlag" flag also indicates the DHCPv6 service status, but
   it is not in the scope of this draft since it is not about address
   configuration.)

   In RFC5887(Renumbering Still Needs Work),it also concerned the M flag
   issue, it said, "Until this ambiguous behaviour is clearly resolved
   by the IETF, operational problems are to be expected, since different
   host operating systems have taken different approaches." In this
   draft, we provided a brief test result in section 3 to identify
   "different host operating systems have taken different approaches".

   This issue may cause inconvenience to the networks that need strong
   management (for example, the enterprise networks), because the host
   behavior of address configuration is somehow un-controlled by the
   network side so that it may violate the management policies. So in
   section 4, we proposed to use one of the reserved bits in RA message
   to let the network control the hosts that which address configuration
   mode should be used. We believe this feature is useful for management,
   especially in a renumbering event.

2. DHCPv6/SLAAC interaction

2.1. Host behavior defined in standards

   In earlier SLAAC specification [RFC2462], the host behavior of
   interpreting M flag is as below:

Bing Liu               Expires January 7 2013                [Page 3]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

   "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 autoconfiguration 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 autoconfiguration, 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 for some reason, the updated SLAAC specification [RFC4862]
   removed the relative description, it said in the RFC "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.)" So it feels
   like the IETF encourages operating system vendors to behave as they
   prefer to do. In the following section 2.2, we provided a test about
   current desktop operating systems' behavior of DHCPv6/SLAAC
   interaction.

2.2. Test of desktop operating systems' behavior

2.2.1. Test environment

                                                /-----\
                 +---------+                  //       \\
                 |  DHCPv6 |                 |  Router   |
                 |  server |                  \\       //
                 +----+----+                    \--+--/
                      |                            |
                      |                            |
                      |                            |
                 -----+-----+-----------------+----+-------
                            |                 |
                            |                 |
                            |                 |
                       +----+---+        +----+---+
                       |        |        |        |
                       |  Host1 |        |  Host2 |
                       +--------+        +--------+

                         Figure 1 Test environment

Bing Liu               Expires January 7 2013                [Page 4]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

   As the figure 1 shows, it is a simple LAN environment. The DHCPv6
   server is a Linux (Ubuntu 10.04)-based PC installing dibbler-server.
   Host1 is a Windows 7 PC, while host2 is a Linux (Ubuntu 12.04, kernel
   3.2.12) PC. (Editor's note: we intended to include Mac OS for test,
   but for some reason we haven't done yet, however, current test
   results have already showed the behavior of OSes varying.)

   Note that, we only tested M flag behavior, O flag was not included.
   Because O flag is about other configuration beyond address
   configuration, it is out of the scope of this draft.

2.2.2. Test scenarios and results

o Scenario 0

   Hosts get online, no RA received.

   - Windows 7: continued sending RS messages for a while, if there is
      no RA replied, it then began to send DHCPv6 solicit;

   - Linux-kernel_3.2.12(Ubuntu 12.04): it continued sending RS, and
      didn't try to send DHCPv6 solicit;

o Scenario 1

   Hosts hadn't configured addresses yet, then if RA messages with M=0
   received, obviously they'll do SLAAC; if M=1, which meant SLAAC and
   DHCPv6 were available simultaneously in the link, the behavior is as
   the following:

   - Windows 7: using both SLAAC and DHCPv6 to configure the addresses,
      regardless of whether the prefixes in SLAAC/DHCPv6 are identical
      of not;

   - Linux-kernel_3.2.12(Ubuntu 12.04): exactly the same action with
      Windows 7;

o Scenario 2

   Hosts were already SLAAC-configured only, then received RA messages
   with M=1:

   - Windows 7: using DHCPv6 to configure another address while keep the
      former SLAAC-configured address;

   - Linux(Ubuntu 12.04): no action.(Note that, it's different with
      scenarios 1)

Bing Liu               Expires January 7 2013                [Page 5]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

o Scenario 3

   Hosts already configured by DHCPv6 only, then received RA messages:

   - Windows 7: If M=1, it configured another address with SLAAC and
      kept the DHCPv6 configuration; else M=0, it released the DHCPv6
      address and configured with SLAAC;

   - Linux-kernel_3.2.12(Ubuntu 12.04): there's no DHCPv6-only situation
      for it, only in scenario 1 when M=1 it would configured with SLAAC
      and DHCPv6 simultaneously.

o Scenario 4

   Hosts already configured with SLAAC/DHCPv6 simultaneously, then RA
   messages with M=0 received:

   (Note: sorry, we haven't covered this scenario yet, will be added in
   the next version)

2.2.3. Conclusion

   Obviously, the two operating systems interpreted the M flag quite
   differently. Windows 7 treats the flag as instruction, it even
   released DHCPv6 session when M=0. Linux was likely to treat the flag
   as advisory, when SLAAC was done, it won't care about M=1.

3. Requirement of Address Configuration Switching in Renumbering

   During IPv6 renumbering, the SLAAC-configured hosts can reconfigure
   IP addresses by receiving ND Router Advertisement (RA) messages
   containing 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. In [I-D.ietf-6renum-enterprise], it described
   several renumbering scenarios in enterprise network. For example, the
   network may split, merge, grow, relocate or reorganize. In these
   situations, it is possible that SLAAC-configured hosts may need to
   switch to DHCPv6-managed, or verse vice.

   As discussed in section 2, the semantic of M bit is ambiguous, for
   example, M=0 is efficient for Windows 7 PCs to switch from DHCPv6-
   managed to SLAAC, but for Linux it is just invalid. So in the

Bing Liu               Expires January 7 2013                [Page 6]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

   following section 4, we proposed to use another two flags to indicate
   the hosts switching between SLAAC/DHCPv6.

4. Proposed Standard Update

4.1. Adding a "DHCPv6Required" Flag

   We propose to add a flag in the standard RA message format[RFC4861],
   the "DHCPv6Required" D flag, which will occupy one bit in the
   reserved field as showed in the following figure 2.

4.2. Adding a "ReleaseDHCPv6" Flag

   We propose to add one more flag in the standard RA message format,
   the "ReleaseDHCPv6" R flag, which will occupy one more bit in the
   reserved field as showed in the following figure 2.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Cur Hop Limit |M|O|D|R| Rsvd  |       Router Lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Reachable Time                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Retrans Timer                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

       Figure 2 DHCPv6Required and ReleaseDHCPv6 flags in RA message

4.3. Host Behavior of Interpreting D/R Flag

   When a host has not configured its addresses (just like scenario 0 in
   section 2.2) and receives RA messages with D=1, it MUST initiate a
   DHCPv6 stateful address autoconfiguration process and SHOULD NOT do
   SLAAC.

   When a host has been SLAAC-configured, and receives D=1, it MUST
   initiate a DHCPv6 stateful address autoconfiguration process and
   SHOULD deprecate SLAAC-configured addresses.

   When a host has been address-configured with DHCPv6, and receives RA
   messages with R=1, it SHOULD release current DHCPv6 address
   configuration and do SLAAC.

Bing Liu               Expires January 7 2013                [Page 7]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

5. Security Considerations

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

6. IANA Considerations

   None.

7. References

7.1. Normative References

   [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and
             M. Carney, "Dynamic Host Configuration Protocol for IPv6
             (DHCPv6)", RFC 3315, July 2003.

   [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

   [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
             Still Needs Work", RFC 5887, May 2010.

   [I-D.ietf-6renum-gap-analysis]
             Liu, B., and Jiang, S., "IPv6 Site Renumbering Gap
             Analysis", Working in Progress, March 2012

   [I-D.ietf-6renum-enterprise]
             Jiang, S., and B. Liu, "IPv6 Enterprise Network Renumbering
             Scenarios and Guidelines ", Working in Progress, March 2012.

8. Acknowledgments

   This work adopts some content from [I-D.ietf-6renum-gap-analysis].

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

Bing Liu               Expires January 7 2013                [Page 8]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

Authors' Addresses

   Bing Liu
   Huawei Technologies Co., Ltd
   Huawei Q14 Building, No.156 Beiqing Rd.,
   Zhong-Guan-Cun Environmental Protection Park, Hai-Dian District
   EMail: leo.liubing@huawei.com