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