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