Internet DRAFT - draft-liu-6renum-dhcpv6-slaac-switching
draft-liu-6renum-dhcpv6-slaac-switching
Network Working Group B. Liu
Internet Draft Huawei Technologies Co., Ltd
Intended status: Proposed Standard W. Wang
Expires: July 18, 2013 X. Gong
University of BUPT
January 15, 2013
DHCPv6/SLAAC Address Configuration Switching for Host Renumbering
draft-liu-6renum-dhcpv6-slaac-switching-02.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 July 18, 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 July 18 2013 [Page 1]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
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 July 18 2013 [Page 2]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
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 July 18 2013 [Page 3]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
"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 July 18 2013 [Page 4]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
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 July 18 2013 [Page 5]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
- 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 July 18 2013 [Page 6]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
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 July 18 2013 [Page 7]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
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 July 18 2013 [Page 8]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
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 July 18 2013 [Page 9]
Internet-Draft draft-liu-6renum-dhcpv6-slaac-switching January 2013
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