Skip to main content

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

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".
Authors Bing Liu , Wendong Wang , Xiangyang Gong
Last updated 2012-07-16
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-01
Network Working Group                                           B. Liu
Internet Draft                            Huawei Technologies Co., Ltd
Intended status: Proposed Standard                             W. Wang
Expires: January 14, 2013                                      X. Gong
                                                    University of BUPT
                                                         July 16, 2012

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

Status of this Memo

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

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

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

   This Internet-Draft will expire on January 14, 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

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

   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 available. But for some reason, the ND protocol didn't
   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 .......................... 8
      4.2. Adding a "ReleaseDHCPv6" Flag ........................... 8
      4.3. Host Behavior of Interpreting D/R Flag .................. 8
   5. Security Considerations ...................................... 9
   6. IANA Considerations .......................................... 9
   7. References ................................................... 9
      7.1. Normative References .................................... 9
      7.2. Informative References .................................. 9
   8. Acknowledgments .............................................. 9
   Authors' Addresses ............................................. 10

Bing Liu              Expires January 14 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 14 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 | |  Host3 |
                    +--------+ +--------+ +--------+

                         Figure 1 Test Environment

Bing Liu              Expires January 14 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.
   - Host2 is a Linux (Ubuntu 12.04, kernel 3.2.12) PC.
   - Host3 is a OS X Lion 10.7.3 MacBook.

   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;

   - OS X Lion 10.7.3: it continued sending RS, and didn't try to send
      DHCPv6 solicit (just the same with Linux);

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): the same action with Windows 7;

   - OS X Lion 10.7.3: the same action with Windows 7;

o Scenario 2

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

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

   - 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);

   - OS X Lion 10.7.3: no action, the same with Linux;

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;

   - OS X Lion 10.7.3: the same situation with Linux;

o Scenario 4

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

   - Windows 7: it released the DHCPv6 address and configured with SLAAC;

   - Linux(Ubuntu 12.04): no action;

   - OS X Lion 10.7.3: no action;

2.2.3. Conclusion

   Obviously, the operating systems interpreting the M flag quite
   differently. Windows 7 treats the flag as instruction, it even
   released DHCPv6 session when M=0. Linux and OS X were likely to treat
   the flag as advisory, when SLAAC was done, it won't care about M=1,
   and M=0 won't cause operation for the already configured DHCPv6
   addresses.

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

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

   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 or OS X it is just invalid. So in the
   following section 4, we proposed to use another two flags to indicate
   the hosts switching between SLAAC/DHCPv6.

4. Proposed Standard Update

4.1. Semantic Space of SLAAC/DHCPv6 Interaction

   We summarize the semantic instructions from network side to host side
   as the following. Some of them are already covered by existing
   implementation while some may need protocol extentions.

   - Network side provides both, let the hosts select by themselves

   It is exactly what M=1 meaning in RFC4861.

   - Network side requires the hosts to do DHCPv6 when online

   As the tests showed, when get online, all the three major OSes will
   initial DHCPv6 when M=1. Especially, when M=1 and RAs don't include
   PIO (Prefix Information Option), the host would "have to" initial
   DHCPv6 for address autoconfiguration. So we can consider this
   semantics has been covered.

   - Network side requires the already SLAAC-configured hosts to do
      DHCPv6

   As the test showed, with current ambiguous M=1 definition, OSes
   varied the behaviors. So this could be considered as a semantic gap.

   - Network side requires the hosts to release DHCPv6 addresses

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

   As analyzed in section 3, the network may need the hosts to switch
   configuration modes. With M=0, the OS behaviors are different as the
   test results showed. So this is another semantic gap.

4.2. 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.3. 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.4. 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.

   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 14 2013                [Page 8]
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

   The tests were done in a lab in BUPT. Thank Xudong Shi very much. He
   is a master student in the lab, and did a great job for the tests.

   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 14 2013                [Page 9]
Internet-Draft    draft-liu-6renum-dhcpv6-slaac-switching     July 2012

Authors' Addresses

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

   Email: leo.liubing@huawei.com

   Wendong Wang
   No.3 Teaching Building
   Beijing University of Posts and Telecommunications
   No.10 Xi-Tu-Cheng Rd.
   Hai-Dian District, Beijing
   P.R. China

   Email: wdwang@bupt.edu.cn

   Xiangyang Gong
   No.3 Teaching Building
   Beijing University of Posts and Telecommunications
   No.10 Xi-Tu-Cheng Rd.
   Hai-Dian District, Beijing
   P.R. China

   Email: xygong@bupt.edu.cn