Network Working Group S. Jiang Internet Draft B. Liu Intended status: Best Current Practice Huawei Technologies Co., Ltd Expires: August 5, 2011 January 26, 2011 IPv6 Site Renumbering Guidelines and Further Works draft-jiang-ipv6-site-renum-guideline-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 August 5, 2011. 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 This document analyzes the existing issues for IPv6 site renumbering. It also analyzes the possible directions to solve these issues and gives recommendations. This document only takes the perspective of network and network protocols. Renumbering in IPv4 networks, in the Jiang & Liu Expires August 5, 2011 [Page 1] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 dual-stack network or in the IPv4/IPv6 transition networks are out of scope. This document only takes the perspective of network and network protocols. According to the different stages, these issues are described in three categories: considerations during network design, considerations for routine network management, and considerations during renumbering operation. Recommended solutions or strategies are also described. Issues that still remain unsolvable are listed as the fourth category. Although we list a few non-network issues in this document, we consider them as issues that ISPs or network providers cannot affect. So, these issues are considered to be unsolvable and not explore further in these document, though they may be solved by OS implementations or application implementations. We summary the requests that need to extend current protocols as further works at the end of this document. Table of Contents 1. Introduction ................................................. 3 2. Network Renumbering Considerations and Solutions/Strategies... 3 2.1. Considerations/issues during network design ............. 4 2.2. Considerations/issues for the routine network management. 5 2.3. Considerations/issues during renumbering operation....... 6 2.4. Issues that still remain unsolvable ..................... 8 2.5. Issues that need further analysis ....................... 9 3. Non-network issues ........................................... 9 4. Requests to extend current protocol ......................... 10 5. Security Considerations ..................................... 11 6. IANA Considerations ......................................... 11 7. Acknowledgements ............................................ 11 8. Change Log [RFC Editor please remove] ....................... 11 9. References .................................................. 11 9.1. Normative References ................................... 11 9.2. Informative References ................................. 12 Author's Addresses ............................................. 13 Jiang & Liu Expires August 5, 2011 [Page 2] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 1. Introduction [RFC5887] has reviewed the existing mechanisms for site renumbering for both IPv4 and IPv6, and identified operational issues with those mechanisms. However, the discussion and analysis were too wide. It exposure many issues, but not give enough analysis on whether these issues are solvable and how. Even the document itself indicates more fractionized and detailed analysis is needed. On another side, the mechanisms analyzed in the document are still not in used. This document focuses on IPv6 network renumbering only, by leaving IPv4 out of scope. Renumbering in IPv4 networks, in the dual-stack network or in the IPv4/IPv6 transition networks are out of scope. This is also consistent preference from IETF renumber mail list by the time of writing up. This document is mainly concerned with issues affecting medium to large sites, which is taken as the conclusion from [RFC5887]. It takes the analysis conclusions from [RFC5887] and other relevant documents as the primary input. This document only takes the perspective of network and network protocols. According to the different stages, these issues are described in three categories: considerations during network design, considerations for routine network management, and considerations during renumbering operation. Recommended solutions or strategies are also described. Issues that still remain unsolvable are listed as the fourth category. Issues that need further analysis are temporarily listed for now. They should all be relocated into abovementioned four categories. Although we list a few non-network issues in this document, we consider them as issues that ISPs or network providers cannot affect. So, these issues are considered to be unsolvable and not explore further in these document, though they may be solved by OS implementations or application implementations. At the end of this document, we summary the requests that need to extend current protocols. 2. Network Renumbering Considerations and Solutions/Strategies The purpose of this section is not to describe the renumbering operation or event completely or entirely, but to expose the existing issues and give the recommended solutions or strategies. Jiang & Liu Expires August 5, 2011 [Page 3] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 2.1. Considerations/issues during network design This section describes the renumbering relevant considerations or issues that a network architect should carefully plan when he builds or designs a new network. - Address configuration models In IPv6 networks, there are two auto-configuration models for address assignment: the Stateless Address Auto-Configuration (SLAAC) by Neighbor Discovery (ND, [RFC4861, RFC4862]) and the stateful address configuration by Dynamic Host Configuration Protocol for IPv6 (DHCPv6, [RFC3315]). (Manual address configuration is not scalable in medium to large sites, hence be out of scope.) SLAAC is considered easier to renumbering by broadcasting a Router Advertisement message with a new prefix. DHCPv6 can also trigger the renumbering process by sending unicast RECONFIGURE messages though it may cause large number of interactions between hosts and DHCPv6 server. However, DHCPv6 reconfiguration "doesn't appear to be widely used for bulk renumbering purposes" [RFC5887]. In principle, a network should choice only one address configuration model and employs either ND or DHCPv6. However, since DHCPv6 is also used to configure many other network parameters, there are ND and DHCPv6 co-existing scenarios. The current protocols do not effectively prevent that both SLAAC and DHCPv6 address assignment are used in the same network (see M bit analysis in section 5.1.1 [RFC5887]. It is network architects' job to make sure only one configuration model is employed. Even in a large network that contains several subnet works, it is recommended not to mixture the two address configuration models though isolately using them in different subnet works may reduce the risk partly. On another side, new protocol extension may help to diagnose the fault situation. This diagnose function could be particularly useful in the scenario where a multihomed network uses SLAAC for one address prefix and DHCPv6 for another. - DNS It is recommended that the site have an automatic and systematic procedure for updating/synchronising its DNS records, including both forward and reverse mapping. Manually on-demand updating Jiang & Liu Expires August 5, 2011 [Page 4] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 model is considered as a harmful problem creator in renumbering event. In order to simplify the operation procedure, the network architect should combine the forward and reverse DNS updates in a single procedure. If a small site depends on its ISP's DNS system rather than maintains its own one. When renumbering, it requires administrative coordination between the site and its ISP. Alternatively, the DNS synchronizing may be completed through the Secure Dynamic DNS Update. - Security Any automatic renumbering scheme has a potential exposure to hijacking at the moment that a new address is announced. Proper network security mechanisms should be employed. Secure Neighbour Discovery (SEND, [RFC3971]), which does not widely deployed, is recommended to replace ND. Alternatively, certain lightweight renumbering specific security mechanism may be developed in the future. DHCPv6 build-in secure mechanisms, like Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages [RFC3315] are recommended. - Miscellaneous Addresses should not be used to configure network connectivity, such as tunnels. A site or network should also avoid to embed addresses from other sites or networks in its own configuration data. Instead, the Fully-Qualified Domain Names should be used. Thusness, these connectivities can survive after renumbering events. This also applies to host-based connectivities. Service Location Protocol and multicast DNS with SRV records for service discovery can reduce the number of places that IP addresses need to be configured. 2.2. Considerations/issues for the routine network management This session describes several recommendations for the routine network management. To adopt these recommendations, a site could be renumbered easier. However, these recommendations are not cost free. They are possible to increase the daily burden of networks. Therefore, only these networks that are expected to be renumbered soon or very frequent should adopt these recommendations with the balance consideration between daily cost and renumbering cost. Jiang & Liu Expires August 5, 2011 [Page 5] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 - Reduce the address preferred time or valid time or both. Long-lifetime addresses may cause issues for renumbering events. Particularly, some offline hosts may reconnect back using these addresses after renumbering events. Shorter preferred lifetime with relevant long valid lifetime may get short transition period for renumbering event and avoid address renew too frequent. - Reduce the DNS record TTL. The DNS record TTL on the local DNS server should be manipulated to ensure that stale addresses are not cached. - Reduce the DNS configuration lifetime on the hosts. Since the DNS server could be renumbered as well, the DNS configuration lifetime on the hosts should also be reduced if renumbering events are expected. The DNS configuration can be done through either ND [RFC6106] or DHCPv6 [RFC3646]. However, DHCPv6 DNS option does not include associated lifetime. It should be updated. - Reduce the NAT mapping session keepalive time. Idle NAT mapping session may be keep alive for a long period if the external network addresses space is plenteous and the internal network address architecture is stable. However, renumbering events mean to restructure the internal network address architecture fully or partly. Reducing the NAT mapping session keepalive time may help to tear down the idle TCP connectivities. This will reduce the TCP surviving issue during the renumbering event. 2.3. Considerations/issues during renumbering operation Renumbering events are not instantaneous events. Normally, there is a transition period, in which both the old prefix and the new prefix are used in the site. Better network design and management, better pre-preparation and longer transition period are helpful to reduce the issues during renumbering operation. - Transition period If renumbering transition period is longer than all addresses life, after which the addresses lease expire, each host will automatically pick up its new IP address. In this case, it would Jiang & Liu Expires August 5, 2011 [Page 6] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 be the DHCP server or Router Advertisement itself that automatically accomplishes client renumbering. - Network initiative enforced renumbering If the network has to enforce renumbering before addresses lease expire, the network should initiate enforcement messages, either in Router Advertisement messages or DHCPv6 RECONFIGURE messages. - DNS record update and DNS configuration on hosts DNS records should be updated if hosts are renumbered. If the site depends on ISP's DNS system, it should report the new host's DNS records to its ISP. During the transition period, both old and new DNS records are valid. If the TTL of DNS records is shorter than the transition period, administrative operation may not be necessary. DNS configuration on hosts should be updated if local recursive DNS servers are renumbered. During the transition period, both old and new DNS addresses may co-exist on the hosts. If the lifetime of DNS configuration is shorter than the transition period, name resolving failure may not be reduced to minimum. A notification mechanism may be needed to indicate the hosts that a renumbering event of local re DNS happen or is going to take place recursive. - Router awareness In a site with multiple border routers, portion renumbering should be aware by all border routers in order to correctly handle inbound packets. Internal forwarding tables need to be updated. - Border filtering In a multihomed site, an egress router to ISP A could normally filter packets with source addresses from other ISPs. The egress router connecting to ISP A should be notified if the egress router connecting to ISP B initiates a renumbering event in order to properly act filter function. - NAT or tunnel concentrator renumbering NAT or tunnel concentrator itself might be renumbered. This change should be reconfigured to relevant hosts or router. Jiang & Liu Expires August 5, 2011 [Page 7] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 2.4. Issues that still remain unsolvable This section lists a few issues that still remain unsolvable. Some of them may be inherently unsolvable. - It is not possible to reduce a prefix's lifetime to below two hours. So, renumbering should not be an unplanned sudden event. This issue could only be avoided by early planning. - Manual or script-driven procedures will break the completely automatic host renumbering. - Some environments like embedded systems might not use DHCP or SLAAC and even configuration scripts might not be an option. This creates special problems that no general-purpose solution is likely to address. - TCP and UDP flows can't survive at renumbering event at either end. - Some address configuration data might be widely dispersed and much harder to find, even will inevitably be found only after the renumbering event. - The embedding of IPv6 unicast addresses into multicast addresses and the embedded-RP (Rendezvous Point) will cause issues when renumbering. - Changing the unicast source address of a multicast sender might also be an issue for receivers. - When a renumbering event takes place, entries in the state table of NAT or tunnel concentrator that happen to contain the affected addresses will become invalid and will eventually time out. However, this can be considered as harmless though it takes sources on these devices for a while. - A site that is listed in a black list can escape that list by renumbering itself. The site itself of course will not initiatively to report its renumbering and the black list may not be able to monitor or discover the renumbering event. Some of these issues can be considered as harmless or have minimum impacts. Jiang & Liu Expires August 5, 2011 [Page 8] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 2.5. Issues that need further analysis This section lists a few issues that still need further analysis. Some of them may be addressed in later version of this document and relocated into other sections. Some of them may be worthy separated document. (Editor note: if all issues addressed, this section should be removed.) - "Some routers cache IP addresses in some situations. So routers might need to be restarted as a result of site renumbering" [RFC2072]. It seems this caused by individual implementation and only happen on the old type of routers. (Author note: to be removed, if confirmed) - Multihomed site, using SLAAC for one address prefix and DHCPv6 for another, would clearly create a risk of inconsistent host behaviour and operational confusion. - It seems so far the renumbering studies only focusing on the individual network using a single prefix. In a large network, a short prefix may be used. The prefix is assigned to be longer and prefixes and delegated to several sub-networks. To make the scenario even more complicated, it may be some sub-networks employ SLAAS while some others are managed by DHCPv6. How to coordinate among these sub-networks to be renumbered together may be worth of analyzing. - The impact of portion renumbering may need to be analyzed further. 3. Non-network issues Although we focus on network side, in this section, we also list a few non-network issues. They are out of network providers/operators reach. Therefore, from network perspective, these issues are considered to be unsolvable though they may be solved by OS implementations or application/service implementations. It is out of scope to explore these issues further. - Any implementation is at risk from renumbering if it does not check that an address is valid each time it opens a new communications session - Socket API encourages applications to be aware of and to store IP address. And the API relative functions do not return an address lifetime so that applications have no way to know the address is no longer valid. Jiang & Liu Expires August 5, 2011 [Page 9] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 - "DNS Pining": limits acceptance of server IP address changes for JavaScript security considerations and it may directly damage the ability of applications to deal with renumbering. - Server applications might need to be restarted when the host they contain is renumbered. In an IPv6 multi-addressed host, server applications need to be able to listen on more than one address simultaneously. Name-based APIs or implementations are recommended. - When a nameserver is renumbered, the host may not be aware or notified immediately; or even the host is notified, but it still considers the old nameserver is available. The host will at some point find it unavailable. This will cause name resolving failure though these failure may be recoverable. - Renumbering may cause issues for ACLs or group login services. 4. Requests to extend current protocol As mentioned in section 2, the following request to extend the current protocols. - A diagnose function to detect and report the confliction of SLAAC and DHCPv6 address assignment. - The current protocol needs to be extended if it does not support to combine the forward and reverse DNS updates in a single procedure. (Author note: it seems possible. If so, remove this item.) - DHCPv6 should be extended to indicate hosts the associated DNS lifetimes when making DNS configuration. - A lightweight renumbering specific security mechanism may be developed if SEND is too weight to be widely deployed. - If the issues of coordination among these sub-networks to be renumbered together are confirmed, new interaction may need to be defined to achieve the cooperation. - A notification mechanism may be needed to indicate the hosts that a renumbering event of local recursive DNS happen or is going to take place recursive. Jiang & Liu Expires August 5, 2011 [Page 10] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 - NAT or tunnel concentrator configuration procedure may need to be extended to be able to notify the host the renumbering of NAT or tunnel concentrator. 5. Security Considerations A site that is listed in a black list can escape that list by renumbering itself. Any automatic renumbering scheme has a potential exposure to hijacking at the moment that a new address is announced. Proper network security mechanisms should be employed. SEND is recommended to replace ND. Alternatively, certain lightweight renumbering specific security mechanism may be developed in the future. DHCPv6 build-in secure mechanisms, like Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] or authentication of DHCPv6 messages [RFC3315] are recommended. The security updates will need to be made in two stages (immediately before and immediately after the event). [Editor note: this section needs further work.] 6. IANA Considerations This draft does not request any IANA action. 7. Acknowledgements This work is illumined by RFC5887, so thank for RFC 5887 authors, Brian Carpeter, Randall Atkinson and Hannu Flinck. Useful ideas were also illumined by documents from Tim Chown and Fred Bark. 8. Change Log [RFC Editor please remove] draft-jiang-ipv6-site-renumbering-ps-00, original version, 2011-01-28 9. References 9.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. Jiang & Liu Expires August 5, 2011 [Page 11] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 [RFC3646] R. Droms, "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ", RFC3646, December 2003. [RFC3736] R. Droms, "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3971] J. Arkko, Ed., J. Kempf, B. Zill, and P. Nikander "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 [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. [RFC6106] J. Jeong, Ed., S. Park, L. Beloeil, and S. Madanapalli "IPv6 Router Advertisement Option for DNS Configuration", RFC 6106, November 2011. 9.2. Informative References [RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. [I-D.ietf-dhc-secure-dhcpv6] Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working in progress. Jiang & Liu Expires August 5, 2011 [Page 12] Internet-Draftdraft-jiang-ipv6-site-renum-guideline-00.txt January 2011 Author's Addresses Sheng Jiang Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Email: shengjiang@huawei.com Bing Liu Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Email: leo.liubing@huawei.com Jiang & Liu Expires August 5, 2011 [Page 13]