Network Working Group B. Liu Internet Draft Huawei Technologies Co., Ltd Intended status: Informational June 29, 2013 Expires: December 31, 2013 IPv6 Site Renumbering Operational Guidelines draft-liu-opsarea-ipv6-renumbering-guidelines-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 December 31, 2013. Copyright Notice Copyright (c) 2012 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. Bing Liu Expires December 31, 2013 [Page 1] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 Abstract This document gives some basic operational guidelines for an IPv6 site renumbering event. This document considers an renumbering event as several basic operational stages as numbering, adding a new prefix, and deprecating old prefix(es) and guidelines are given according to each stage. Besides the general guidelines, this document also gives some considerations on some specific operations such as ND/DHCPv6 collaboration, DHCPv6 reconfiguration, secure dynamic DNS update and multicast. Table of Contents 1. Introduction ................................................. 3 2. Numbering Operations.......................................... 3 2.1. Using FQDN (Fully Qualified Domain Names) ............... 3 2.2. Using ULAs (Unique Local Addresses) ..................... 4 2.3. Leveraging the loopback interface ....................... 4 2.4. Router numbering ........................................ 4 2.5. Static addresses ........................................ 5 3. Adding a new prefix .......................................... 5 4. Deprecating old prefix(es) ................................... 6 4.1. Deprecating SLAAC prefix ................................ 6 4.2. Deprecating DHCPv6 old addresses ........................ 6 5. ND/DHCPv6 Collaboration ...................................... 6 5.1. Host Numbering .......................................... 6 5.1.1. Address Provisioning ............................... 6 5.1.2. Information Provisioning ........................... 7 5.2. Adding a new prefix ..................................... 7 5.3. Deprecating a prefix .................................... 8 6. DHCPv6 reconfiguration ....................................... 8 7. Secure Dynamic DNS Update .................................... 8 8. Other Operational Considerations ............................. 9 9. Security Considerations ...................................... 9 10. IANA Considerations.......................................... 9 11. Acknowledgments ............................................. 9 12. References .................................................. 9 12.1. Normative References ................................... 9 12.2. Informative References ................................ 10 Bing Liu Expires December 31, 2013 [Page 2] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 1. Introduction For IPv6 renumbering, there have been several works addressing on it. [RFC4192] describes a procedure that can be used to renumber a network from one prefix to another smoothly through a "make-before- break" transition. [RFC5887] makes a comprehensive analysis and pointed out there are still some work to do in the future. Making [RFC5887] as a starting point, [RFC6879] illustrates IPv6 enterprise renumbering scenarios and gives some considerations to ease renumbering while [I.D-ietf-6renum-gap-analysis](to be a RFC soon) identifies gaps in the scenarios. In general, this draft considers the make-before-break approach in [RFC4192] as a basic method of IPv6 enterprise renumbering. Since [RFC4192] already includes some basic operational approaches, this document focusing on operational guidelines which reflex the new learning from [RFC5887], [RFC6879], and [I.D-ietf-6renum-gap- analysis]. This document considers a renumbering event as several basic operational stages which are numbering, adding a new prefix, and deprecating old prefix(es). Guidelines are given according to each stage. Besides the general operations, this document also gives some considerations on specific operations including ND/DHCPv6 collaboration, DHCPv6 reconfiguration, secure dynamic DNS update and multicast. 2. Numbering Operations Operations in numbering stage is important for future renumbering, since it might impact the renumbering operations/mechanisms selection or even causes some troubles if not operated properly. Generally, this section complies the considerations in [RFC6879] section 4.1 (considerations and current methods during network design). Some topics are briefly re-generated from [RFC6879] or other documents to make this section as stand-alone complete guidelines. 2.1. Using FQDN (Fully Qualified Domain Names) If a node using FQDN, when renumbering, the address only need to be updated once in the node and in the correspond DNS record(s), then every places using the FQDN could learn the new address through DNS queries. This is a significant benefit for easing renumbering and is usually very suitable for servers, tunnels etc. However, this good feature seems not been widely used in real network deployment. Bing Liu Expires December 31, 2013 [Page 3] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 Since FQDN relies on DNS, the administrators need to know it has all the limitations of DNS systems. 2.2. Using ULAs (Unique Local Addresses) For some internal-only nodes, it is practical to number them with ULAs, then renumbering events caused by external factors (ISP change, ISP renumbering .etc) could be avoided. ULAs could also co-exist with PA (Provider Aggregated) GUAs (Global Unicast Addresses). The benefit is to ensure stable and specific local communications regardless of any ISP failure. It should be noticed that, if ULAs are co-exist with PA addresses, the administrators need to carefully handle the address selection policies in the nodes to make sure a ULA-ULA address pair, since a ULA-PA address pair might cause connection failure. This issue could be silently solved in the future, since the revised address selection algorithm standard (RFC6724) has enable ULA-ULA pair selection as default. Another operational concern is to make sure the ULA correspond DNS records should not be propagated outside the local recruit DNS servers. 2.3. Leveraging the loopback interface Some current routers support defining multiple loopback interfaces that can be called in other configurations. For example, when defining a tunnel, it can call the defined loopback interface to use its address as the local address of the tunnel. This feature makes renumbering easier by reducing the number of places where a device's address configuration must be updated. 2.4. Router numbering [RFC2894] defined standard ICMPv6 messages for router numbering/renumbering. This is a dedicated protocol, but we are not aware of it being used in real network deployment. So in real networks, routers are basically numbered though human intervene. For routers, an OAM (Operations Administration and Management) plane is usually needed. The administrators could also leverage ULAs to number the router loopback interfaces so that the OAM plane is logically separated from the data forwarding plane so that the OAM connectivity could be immune of the data plane impact. Bing Liu Expires December 31, 2013 [Page 4] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 2.5. Static addresses As analyzed in [RFC6866], Static address configurations might not be avoided in some situations, for example, the address-based software licensing. However, the administrators should note that "static" doesn't necessarily mean "manual". Manual configurations should be avoided as much as possible since it would be highly burdensome and error prone to type/remeber the IPv6 addresses. Administrators should leverage tools to configure/manage the static addresses. 3. Adding a new prefix o Add a prefix to the network infrastructure The operations of adding a new prefix in a network infrastructure has been well addressed in section 2.3 and 2.4 in [RFC4192]. To briefly summarize it, there are several main procedures as the following: - The new prefix is added to the routing infrastructure, firewall filters, ingress/egress filters, and other forwarding and filtering functions - Routes for the new link prefixes may be injected by routing protocols into the routing subsystem - The RA (Router Advertisement) messages should not cause hosts to perform SLAAC on the new link prefixes since the new prefix might has not been stable - Once the new prefix in network infrastructure is in place and tested, then assign the new addresses to the hosts - The new addresses will not be used until they are inserted into the DNS o A temporary multihoming environment Add a new prefix usually meaning add a new ISP uplink. So when the new prefix has been added into the network, then it became a temporary multihoming environment with multiple PA prefixes. If the ISPs enable ingress filtering at the edge, then the administrators need to deal with the source address selection and the exit router selection issues. For the latter, currently there is no Bing Liu Expires December 31, 2013 [Page 5] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 well-used solution, so the administrator might need to communicate with the ISP for not filtering the prefixes. o Making the new prefix higher priority When the new prefix is stable, the new sessions should always choose the new address as the source address. This consideration is to avoid the new sessions might be long enough to exceed the old/new address overlap period so that the session survivability would be broken. The probability is especially high at the end of overlap period. To achieve this effort, the administrators could advertise the old prefix as deprecated through RA messages for the SLAAC hosts; for DHCPv6 hosts, the administrators need to deal with the address selection policy tables in the hosts. 4. Deprecating old prefix(es) 4.1. Deprecating SLAAC prefix For the SLAAC-configured hosts, the prefix deprecation operation could be done through standard RA messages. First, the administrators could make the router to deprecate the prefix, and at the end of the overlap period, the administrators could advertise the prefix with very short lifetime so that the old prefix would be invalid soon. 4.2. Deprecating DHCPv6 old addresses For DHCPv6-configured hosts, the T1 time has to be short enough that the addresses could expire before they are deprecated. Then the hosts could get the new addresses through renew hebaviour. 5. ND/DHCPv6 Collaboration 5.1. Host Numbering IPv6 has overlapped functions between ND and DHCPv6, they fit in different scenarios. [I-D.liu-bonica-dhcpv6-slaac-problem] identified some operational problems of the protocol interactions, so the administrators need careful plan and cooperation of these two mechanisms. 5.1.1. Address Provisioning There could be three kind of possible address provisioning models, which are discussed as the following. Bing Liu Expires December 31, 2013 [Page 6] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 o SLAAC-only prefix provisioning It's efficient to run DHCP-PD between routers and DHCPv6 server, and SLACC on the downlinks. This combination could leverage the numbering/renumbering operations the maxim automation. o DHCPv6-only address provisioning If administrators want a DHCPv6-only managed network, then it is recommended to turn SLAAC off through A=0 (the Autonomous flag) and keep RA working with M flag set (the Managed flag). Because as identified in [I-D.liu-bonica-dhcpv6-slaac-problem], some operation systems would not initiate DHCPv6 session until they received the M flag set in RA messages. o SLAAC/DHCPv6 co-existence prefix/address provisioning In normal cases, it is recommended to use only one address provisioning model for a host. But there might be some special situations in which both the two models are needed simultaneously. For example, the network need to be multihomed, and one uplink uses DHCPv6 for management while the other uses SLAAC. Then the SLAAC link need always keeping the M flag set to make sure all the host would initiate DHCPv6 sessions beside the SLAAC configuration. 5.1.2. Information Provisioning - Currently only ND could provide routing information to hosts, RA should be always on - Using stateful DHCPv6 for info provisioning as well as addresses - Using stateless DHCPv6 for info provisioning and SLAAC for address provisioning - Using ND for both address and info (currently only support routing and DNS) 5.2. Adding a new prefix - The new prefix might use different address provisioning - For already DHCPv6-configured hosts, it is not applicable to add another DHCPv6 session parall, DHCPv6's architecture is not well supporting multiple provisioning domains yet, the administrators need to avoid this kind of use cases. Bing Liu Expires December 31, 2013 [Page 7] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 - For already SLAAC-configured hosts, they might ignore the M transitioning from 0 to 1, so still using SLAAC for adding a new prefix is better than adding a DHCPv6 address provisioning 5.3. Deprecating a prefix TBD. 6. DHCPv6 reconfiguration DHCPv6 reconfiguration is a standard function defined in [RFC3315]. This function is quite practical for bulk renumbering triggered by the servers. It is very suitable for DHCPv6-only managed networks. There is no significant additional burden to maintaining the state required to send Reconfigures to every client. A power outage restart scenario takes similar burden for the DHCP systems comparing to bulk reconfiguration. As the authors learned, mainstream commercial DHCP servers that could handle a typical enterprise power outage restart. If the administrators want the reconfiguration be effective, they need to group the DHCP clients based on prefix in the server, so that the reconfiguration could be triggered by prefix change. However, the reconfiguration has not been widely used since it has not been widely supported yet, but as the author investigated, it is already on some DHCP implementations' feature list in the near future. So it is foreseeable that DHCPv6 reconfiguration could be a effective tool for renumbering. 7. Secure Dynamic DNS Update Using dynamic DNS update could significantly improve the efficiency and automation of renumbering. DDNS has vital security threats, so in real deployment, Secure Dynamic DNS Update [RFC3007] is always needed and already has been widely supported by the major DNS implementations. However, normal hosts are not suitable to do the update mainly because of the complexity of key management issues inherited from secure DNS mechanisms, so current practices usually assign the DHCP servers to act as DNS clients to request the DNS server updating relevant records [RFC4704]. The key management problem is tractable in the case of updates for a limited number of servers, so Dynamic DNS updates could serve as a suitable solution for keeping server DNS records up to date on a typical enterprise network. However, this solution is not easily applicable to hosts in general. Bing Liu Expires December 31, 2013 [Page 8] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 To address the larger use case of arbitrary non-server hosts being renumbered, DHCP servers have to learn the relevant hosts have changed their addresses and thus trigger the DDNS update. If the hosts were numbered and also renumbered by DHCP, then it is easy for the DHCP servers to learn the address changes; but if the hosts were numbered by SLAAC, then there could be trouble. The key distribution could be much easier on DHCP servers, but then stronger security protection between hosts and DHCP servers is needed. Generally, this could be considered as an operational issue. One possible way is to put all the regular hosts in their own zone, e.g. ddns.sample.com. So when a host registers with DHCP, it gets a PTR record for its IP address, and an A record with its name. For an instance, there is one node whose name is EXAPLE, so it is registered automatically by the DHCP server as EXAPLE.ddns.sample.com. Additionally, DHCP clients can't overwrite existing non-DHCP names in the DNS, because DHCP servers follow RFC 4703, which prevents this. So even if the network doesn't use a separate zone, a DHCP server won't honor a client's update if it presents a un-matching name (e.g. "www" name). 8. Other Operational Considerations TBD (if there would be). 9. Security Considerations TBD. 10. IANA Considerations This draft does not request any IANA actions. 11. Acknowledgments Many useful comments and contributions were made by Sheng Jiang, Brian Carpenter, Ted Lemon, Joel Jaeggli .etc. This document was prepared using 2-Word-v2.0.template.dot. 12. References 12.1. Normative References [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. Bing Liu Expires December 31, 2013 [Page 9] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 [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. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 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. 12.2. Informative References [RFC2072] H. Berkowitz, "Router Renumbering Guide", RFC2072, January 1997. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998. [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, August 2000. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006. [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013. Bing Liu Expires December 31, 2013 [Page 10] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013. [I-D.ietf-6man-addr-select-opt] Matsumoto, A.M., Fujisaki T.F., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Working in Progress, April 2013. [I-D.liu-bonica-dhcpv6-slaac-problem] Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Working in Progress, February 2013. Bing Liu Expires December 31, 2013 [Page 11] Internet-Draft IPv6 Site Renumbering Operational Guidelines June 2013 Author's Addresses Bing Liu Huawei Technologies Co., Ltd Huawei Building, 156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China Email: leo.liubing@huawei.com