Network Working Group B. Liu Internet Draft S. Jiang Intended status: Informational Huawei Technologies Co., Ltd Expires: January 11, 2012 July 11, 2011 IPv6 Site Renumbering Gap Analysis draft-liu-6renum-gap-analysis-01.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 04, 2012. 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 briefly introduces the existing mechanisms could be utilized by IPv6 site renumbering and envisions the effort could be done. This document tries to cover the most explicit issues and requirements of IPv6 renumbering. Through the gap analysis, the document provides a basis for future work to identify and develop Liu & Jiang Expires January 11, 2012 [Page 1] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 solutions or to stimulate such development as appropriate. The gap analysis is presented following a renumbering event procedure clue. Table of Contents 1. Introduction ................................................ 3 2. Overall Requirements for Renumbering ........................ 3 3. Existing Components for IPv6 Renumbering .................... 4 3.1. Relevant Protocols and Mechanisms .................... 4 3.2. Management Tools ....................................... 4 3.3. Procedures/Policies .................................... 5 4. Managing Prefixes ........................................... 5 4.1. Prefix Delegation ...................................... 5 4.2. Prefix Assignment ...................................... 5 5. Address Configuration ....................................... 6 5.1. Host Address Configuration ............................. 6 5.2. Router Address Configuration ........................... 7 5.3. Static Address Configuration ........................... 8 6. Address Relevant Entries Update ............................. 9 6.1. DNS Records Update ..................................... 9 6.2. In-host Server Address Update ......................... 10 6.3. Filters ............................................... 10 7. Renumbering Event Management ............................... 11 7.1. Renumbering Notification .............................. 11 7.2. Synchronization Management ............................ 12 7.3. Renumbering Monitoring........................... ..... 12 8. Miscellaneous .............................................. 12 8.1. Multicast ............................................. 12 8.2. Mobility .............................................. 13 9. Gap Summary ................................................ 13 9.1. Managing Prefixes ..................................... 13 9.2. Address configuration ................................. 13 9.3. Address relevant entries update ....................... 14 9.4. Renumbering event management .......................... 15 10. Security Considerations ................................... 15 11. IANA Considerations ....................................... 16 12. References ................................................ 16 12.1. Normative References ................................. 16 12.2. Informative References ............................... 17 13. Acknowledgments ........................................... 17 Liu & Jiang Expires January 11, 2012 [Page 2] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 1. Introduction As introduced in [RFC5887], renumbering, especially for medium to large sites and networks, is currently viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. If IPv6 site renumbering continues to be considered difficult, network managers will turn to Provider Independent (PI) addressing for IPv6 to attempt to minimize the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. This document performs a gap analysis to provide a basis for future work to identify and develop solutions or to stimulate such development as appropriate. Gap analysis draws on existing work in (at least) [RFC5887] and [RFC4192]. The [I-D.jiang-6renum-enterprise] contributions are incorporated into the more detailed gap analysis. In this document, we discuss the overall requirements for renumbering. The gap analysis is organized by the main steps of renumbering process, which include the prefix management, the node address (re)configuration, and address relevant entries update in various gateways, routers and servers, etc. Besides the steps, a sub- clause of renumbering event management is presented independently, which targets to help the operational/administrative process. 2. Overall Requirements for Renumbering This section introduces the overall ultimate goals we want to achieve in renumbering event. Some existing mechanisms have already provide useful help. Further efforts may be achieved in the future. o Prefix delegation and delivery should be automatic and accurate in aggregation and coordination. o Address reconfiguration should be automatically achieved through standard protocols with minimum human intervene. o Address relevant entries update should be processed integrally and error-prevented. [Open Question]Is it necessary to develop automatic entries update mechanisms? If necessary, do we need standard protocols/interface for it? Liu & Jiang Expires January 11, 2012 [Page 3] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 o [Open Question] Is it necessary/possible to develop a ''One-Click'' fully automatic renumbering technology? What scenarios have the potential possibility? o [Open Question] Is session survivability within our scope? 3. Existing Components for IPv6 Renumbering 3.1. Relevant Protocols and Mechanisms Generally, renumbering is achieved by utilizing existing protocols rather than dedicated renumbering protocols. o RA messages, defined in [RFC4861], are used to deprecate/announce old/new prefixes and to advertise the availability of an upstream router. In renumbering, it is one of basic mechanisms for host configuration. o When a host is renumbered, it may use SLAAC [RFC4862] for address configuration with the new prefix. Hosts receive RA messages which contain routable prefix(es) and the address(es) of the default router(s), then hosts can generate IPv6 address(es) by themselves. o Hosts configured through DHCPv6 [RFC3315] can reconfigure addresses by initialing RENEW sessions when the current addresses' lease time are expired or they receive the reconfiguration messages initiatedinitiated by the DHCPv6 servers. o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated delegation of IPv6 prefixes using the DHCPv6. initiated o [RFC2894] defined standard ICMPv6 messages for router renumbering. This is a dedicated protocol for renumbering, but has not been widely used. 3.2. Management Tools Some operations of renumbering could be automatically processed by management tools in order to make the renumbering process more efficient and accurate. The tools may be designed dedicated for renumbering or just common tools could be utilized for some operations in renumbering. Following are samples of the tools. Liu & Jiang Expires January 11, 2012 [Page 4] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 o [LEROY] proposed a mechanism of macros to automatically update the address relevant entries/configurations inside the DNS, firewall, etc. The macros can be delivered though SOAP protocol from a network management server to the managed devices. o Asset management tools/systems. These tools may provide the ability of managing configuration files in nodes so that it is convenient to update the address relevant configuration in these nodes. 3.3. Procedures/Policies o [RFC4192] proposed a procedure for renumbering an IPv6 network without a flag day. The document includes a set of operational suggestions which can be followed step by step by network administrators. o [I-D.jiang-6renum-enterprise] analyzes the enterprise renumbering events and gives the recommendations among the existing renumbering mechanisms. According to the different stages, renumbering considerations are described in three categories: considerations and recommendations during network design, for preparation of enterprise network renumbering, and during renumbering operation 4. Managing Prefixes When renumbering an enterprise site, a short prefix may be divided into longer prefixes for subnets. So we need to carefully manage the prefixes for prefix delivery, delegation, aggregation, synchronization, coordination, etc. 4.1. Prefix Delegation Usually, the short prefix comes down from the operator and received by DHCPv6 server or router inside the enterprise network. The short prefix could be automatically delegated through DHCPv6-PD. Then the downlink DHCP servers or routers can begin advertising the longer prefixes to the subnets. 4.2. Prefix Assignment When subnet routers receive the longer prefixes, they can directly assign them to the hosts. The prefix assignment overlaps with the host address configuration, which is described in the following section 5.1. Liu & Jiang Expires January 11, 2012 [Page 5] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 5. Address Configuration 5.1. Host Address Configuration Both of the DHCPv6 and ND protocols have IP address configuration function. They are suitable for different scenarios respectively. During renumbering, the SLAAC-configured hosts can reconfigure IP addresses by receiving ND Router Advertisement (RA) messages containing new prefix information (It should be noted that, the prefix delivery could be achieved through DHCP according to the new IETF DHC WG document [I.D ietf-dhc-host-gen-id]). The DHCPv6- configured hosts can reconfigure addresses by initiating RENEW sessions when the current addresses' lease time are expired or receiving the reconfiguration messages initiated by the DHCPv6 servers. o SLAAC and DHCPv6 address configuration co-existence While an IPv6 site is being renumbered, both DHCPv6 and ND may be used to reconfigure the host addresses. The co-existence issue mainly includes following aspects: - Dynamic upstream learning [RFC5887] mentioned that, DHCP-configured hosts may want to learn about the upstream availability of new prefixes or loss of prior prefixes dynamically by deducing from periodic RA messages. But there is no standard specifying what approach should be taken by a DHCPv6-configured host when it receives RA messages containing new prefix. It depends on the operation system of the host and cannot be predicted or controlled by the network. - DHCP/SLAAC conflict If the DHCP-managed host accepts the new prefix in RA, it may violet the DHCPv6-managed policies. But if it ignores the RA messages and there are no DHCPv6 reconfiguration messages received either, the renumbering would fail. What is worse, the host may even receive both the RA messages and DHCP-v6 reconfiguration messages and finds the prefixes in the two protocols are different. This means serious network configuration error occurring. [Open Question]It is hard for the host to identify the RA messages containing new prefix(es) representing adding an uplink or conflict caused by network configuration mistake. Liu & Jiang Expires January 11, 2012 [Page 6] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 - SLAAC-configured hosts finding DHCPv6 in use [RFC5887] mentioned RA message of ND protocol contains a "Managed Configuration" flag to indicate DHCPv6 is in use. But it is unspecified what behavior should be taken when the host receives RA messages with "M" set to 1. The gap of standard will cause ambiguous host behavior because it depends on the operation system of the host. The host may start a DHCPv6 session and receives the DHCPv6 address configuration. It is also possible that the host finds the DHCPv6 assigned prefix is different from the prefix in the RA messages, which means multiple uplinks are available or there is a serious network configuration error. Another possibility is that the host may receive no response from any DHCPv6 servers, which means the DHCPv6 service is not available and the "Managed Configuration" flag was mis- configured. o DHCPv6 reconfigure bulk usage [RFC5887] mentioned that ''DHCPv6 reconfiguration doesn't appear to be widely used for bulk renumbering purposes''. [Open Question] Using DHCPv6 reconfiguration can be considered as ''stateful'' renumbering which need sessions maintained between DHCP servers and clients. So maybe it is too heavy for the servers. So is it possible for bulk renumbering? Is there any requirement? o RA prefix lifetime limitation In section 5.5.3 of [RFC4862], it is defined that ''If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime.'' So when renumbering, if the previous RemainingLifetime is longer than two hours, it is impossible to reduce a prefix's lifetime less than two hours. This limitation is to prevent denial-of-service attack. [Open Question]This limitation requires renumbering to be planned in advance so that an immediate renumbering event is impossible. Should it be considered as a standard gap for renumbering? 5.2. Router Address Configuration o Learning new prefixes Liu & Jiang Expires January 11, 2012 [Page 7] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 As described in [RFC5887], ''if a site wanted to be multihomed using multiple provider-aggregated (PA) routing prefixes with one prefix per upstream provider, then the interior routers would need a mechanism to learn which upstream providers and prefixes were currently reachable (and valid). In this case, their Router Advertisement messages could be updated dynamically to only advertise currently valid routing prefixes to hosts. This would be significantly more complicated if the various provider prefixes were of different lengths or if the site had non-uniform subnet prefix lengths.'' o Restart after renumbering "Some routers cache IP addresses in some situations. So routers might need to be restarted as a result of site renumbering" [RFC2072]. After investigation, it seems (need further confirmation) this caused by individual implementation and only happen on the old type of routers. Therefore, it is not an issue anymore. o Router naming In [RFC4192], it is suggested that ''To better support renumbering, switches and routers should use domain names for configuration wherever appropriate, and they should resolve those names using the DNS when the lifetime on the name expires.'' As [RFC5887] described, this capability is not new, and at least it is present in most IPsec VPN implementations. But many administrators do not realize that it could be utilized to avoid manual modification during renumbering. [Open Question]Whether it is not easy to use or just suitable in few situations needs further investigation. 5.3. Static Address Configuration Further gap analysis about static address issue could consider the following suggestions (proposed by George Wesley in the mail list). o Documenting how to limit the places where static addresses must be used (vs FQDN or autoconf). o Identifying gaps and proposing solutions in other areas to reduce the number of places that static addresses are required. Liu & Jiang Expires January 11, 2012 [Page 8] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 o Documenting any gaps in [RFC4192] to make renumbering easier for a statically-numbered set of hosts and potentially identifying a problem statement for improving renumbering for static. [Open Question]Besides the open questions above, the ULA utilization issue may also need consideration. 6. Address Relevant Entries Update When nodes in a site have been renumbered, then all the entries in the site which contain the nodes' addresses must be updated. The entries mainly include DNS records and filters in various entities such as ACLs in firewalls/gateways. 6.1. DNS Records Update o DNS update automation For DNS records update, most sites will achieve it by maintaining a DNS zone file and loading this file into the site's DNS server(s). Synchronization between host renumbering and the updating of its A6 or AAAA record is hard. [RFC5887] mentioned that an alternative is to use Secure Dynamic DNS Update [RFC3007], in which a host informs its own DNS server when it receives a new address. But Secure Dynamic DNS Update hasn't been widely deployed. [Open Question]To popularize the [RFC3007] or to develop a lightweight dedicated protocol for this need to be considered. DNS entries commonly have matching Reverse DNS entries which will also need to be updated during renumbering. [Open Question]So synchronizing the procedures of forward and reverse DNS or even combining forward and reverse DNS updates in a single procedure also need to be considered. o DNS data structure optimization [RFC2874] proposed a new A6 record type for DNS recording IPv6 address/prefix. And several extensions on query and processing were also proposed. With the A6 record and the extensions, an IPv6 address can be defined by using multiple DNS records. This feature increases the complexity of resolver but reduce the cost of zone file maintenance. So renumbering could be easier than AAAA record. But the [RFC2874] has not been widely used. Liu & Jiang Expires January 11, 2012 [Page 9] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 [Open Question]Is the DNS data structure optimization such as [RFC2874] necessary for easing renumbering? If necessary, is the optimization in [RFC2874] enough? o DNS authority As described in [I-D.chown-v6ops-renumber-thinkabout], ''it is often the case in enterprises that host web servers and application servers on behalf of collaborators and customers that DNS zones out of the administrative control of the host maintain resource records concerning addresses for nodes out of their control. When the service host renumbers, they do not have sufficient authority to change the records.'' [Open Question]Whether it is only an operational issue or additional protocol/mechanism is needed to standardize the interaction between DNS systems needs to be considered. 6.2. In-host Server Address Update While DNS records addresses of hosts in servers, hosts also record addresses of servers such as DNS server, radius server, etc. While renumbering, the hosts must update the records if the server addresses changed. Addresses of DHCPv6 servers do not need to be updated. They are dynamic discovered using DHCPv6 relevant multicast addresses. o The DNS server addresses for hosts are configured by DHCPv6. But current DHCPv6 messages do not indicate hosts the lifetimes of DNS. If the DNS lifetime expired and has been renumbered, the hosts may still use the old addresses. DHCPv6 should be extended to indicate hosts the associated DNS lifetimes when making DNS configuration. How does the DHCP server could know about the DNS lifetime is another issue. 6.3. Filters o Filters Management Filters based on addresses or prefixes are usually spread in various devices. As [RFC5887] described, some address configuration data might be widely dispersed and much harder to find, even will inevitably be found only after the renumbering event. So there's a big gap for filter management. Liu & Jiang Expires January 11, 2012 [Page 10] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 In [LEROY], a server is used for managing filter update in various devices. But identifying where and which of the filters need to be updated during renumbering is still a gap. o Filter Update Automation Operation As mentioned in section 3.2, [LEROY] proposed a mechanism which can automatically update the filters. The mechanism utilizes macros suitable for various devices such as routers, firewalls etc. to update the filter entries based on the new prefix. Such automation tool is valuable for renumbering because it can reduce manual operation which is error-prone and inefficiency. [Open Question]Besides the macros, [LEROY] also proposed to use SOAP to deliver the macros to the devices. So there may be requirement of protocol standardization. [LEROY] uses application layer protocol while we may consider whether it is possible and suitable to use network layer protocol. [Open Question] Update of filters based on prefixes and filters based on addresses may have different requirements and methods. For example, the prefix-based filters may consider to be updated though DHCPv6 server, which may provide better efficient. 7. Renumbering Event Management From the perspective of network management, renumbering is a kind of event which may need additional process to make the process more easy and manageable. 7.1. Renumbering Notification If hosts or servers are aware of a renumbering event happening, it may help the relevant process. Following are several examples of such additional process may ease the renumbering. Further contributions are expected. o 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. o [RFC4192] suggests that ''reducing the delay in the transition to new IPv6 addresses applies when the DNS service can be given prior notice about a renumbering event.'' Reducing delay could improve the efficiency of renumbering. Liu & Jiang Expires January 11, 2012 [Page 11] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 7.2. Synchronization Management o DNS update synchronization DNS update synchronization focuses on the coordinating between DNS and other entities/mechanims, for example, as described in [RFC5887], synchronizing the SLAAC and DNS updates, and of reducing the SLAAC lease time and DNS TTL. [Gaps TBD] 7.3. Renumbering Monitoring While treating renumbering a network event, mechanisms to monitor the renumbering process may be needed. Considering the address configuration operation may be stateless(if ND is used for renumbering), it is difficult for monitoring. But for the DNS and filter update, it is quite possible to monitor the whole process. [Gaps TBD] 8. Miscellaneous 8.1. Multicast o The embedding of IPv6 unicast addresses into multicast addresses and the embedded-RP (Rendezvous Point)[RFC3956] will cause issues when renumbering. As [I-D.chown-v6ops-renumber-thinkabout] described, ''If the RP address changes, then the group addresses must also be changed. This may happen not only when a site is renumbered, but also if a site is restructured or the RP is moved within the site. The embedded address is used by routers to determine the RP address. Applications must use new group addresses once the RP is not available on the old address.'' o Changing the unicast source address of a multicast sender might also be an issue for receivers. As [I-D.chown-v6ops-renumber-thinkabout] described, ''If a site's unicast prefix changes, then one will also need to change the multicast addresses. By way of example, a site renumbering away from prefix 2001:DB8:BEEF::/48" might have globally-scoped multicast addresses in use under the prefix "FF3E:30:2001:DB8:BEEF::/96". One may continue using the old addresses for a while, but this should be avoided since another Liu & Jiang Expires January 11, 2012 [Page 12] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 site may inherit the prefix and they may end up using the same multicast addresses.'' 8.2. Mobility o [RFC5887] suggested that, for Mobile IP, define a better mechanism to handle change of home agent address while mobile is disconnected. 9. Gap Summary 9.1. Managing Prefixes None. (call for contributions) 9.2. Address configuration o Host address configuration - SLAAC and DHCPv6 address configuration co-existence -Dynamic upsteam learning: DHCP-configured host may want to learn about the upstream availability of new prefixes or loss of prior prefixes dynamically by deducing from periodic RA messages. -DHCP/SLAAC conflict: Prefixes in the two protocols' massages may be different, which may be caused by serious network configuration error. A diagnosis/report mechanism is needed here. -SLAAC-configured hosts find DHCPv6 is in use: RA messages contain a "Managed Configuration" flag to indicate DHCPv6 is in use. But it is unspecified what behavior should be taken when the host receives RA messages with "M" set to 1. The gap of standard will cause ambiguous host behavior. - DHCPv6 reconfigure bulk usage Maybe it is too heavy for the server. So is it possible for bulk renumbering? Is there any requirement? - RA prefix lifetime limitation If previous RemainingLifetime is longer than two hours, it is impossible to reduce a prefix's lifetime less than two hours. Is it a standard gap for renumbering? Liu & Jiang Expires January 11, 2012 [Page 13] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 o Router address configuration - Learning new prefixes If the site is multihoming, the interior routers would need a mechanism to learn which upstream providers and prefixes were currently reachable (and valid). - Restart after renumbering Some routers cache IP addresses in some situations. So routers might need to be restarted as a result of site renumbering. - Router naming Using domain names for routers is suitable in some scenarios but has not been widely deployed. Whether it is not easy to use or just suitable in few situations needs further investigation. o Static address configuration Further work is needed. 9.3. Address relevant entries update o DNS records update - DNS update automation Synchronization between host renumbering and the updating of its DNS records is hard. Forward and reverse DNS entries update may need to be combined together. - DNS data structure optimization Is the DNS data structure optimization as A6 record [RFC2874] necessary for easing renumbering? - DNS authority DNS zones are out of the administrative control. Authority collaboration is needed. o In-host server address update Liu & Jiang Expires January 11, 2012 [Page 14] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 Hosts also record addresses of servers such as DNS server addresses, radius server address, etc. While renumbering, the host must update the records if these server addresses changed. o Filters - Filters management There is a gap of filter management to identify where and which of the filters need to be updated during renumbering. Manageable filter update may be also needed. - Filter update automation operation Automation update tool is valuable for renumbering, and there may be requirement of protocol standardization to deliver of facility the tools. 9.4. Renumbering event management o Renumbering notification If hosts/servers are aware of a renumbering event happening, it may help the relevant process. A basic way is to extend current protocol messages to carry the renumbering notification. o Synchronization management - DNS update synchronization An example is synchronizing the SLAAC and DNS updates, and of reducing the SLAAC lease time and DNS TTL. [TBD] o Renumbering monitoring Mechanisms to monitor the process and feedback of renumbering may be needed. [TBD] 10. Security Considerations o Prefix Validation Prefixes from the ISP may need authentication to prevent prefix fraud. Announcing changes of site prefix to other sites (for example, Liu & Jiang Expires January 11, 2012 [Page 15] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 those that configure routers or VPNs to point to the site in question) also need validation. In the LAN, Secure DHCPv6 ([I-D.ietf-dhc-secure-dhcpv6]) or SeND ([RFC3971], Secure Neighbor Discovery) deployment may need to validate prefixes. o Influence to Security Controls During renumbering, security controls (e.g. ACLs) blocking access to legitimate resources should not be interrupted. 11. IANA Considerations None. 12. References 12.1. Normative References [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, August 2000. [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [RFC3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [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. [RFC3956] P. Savola, and B. Haberman. "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address.", RFC 3956, November 2004. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005 Liu & Jiang Expires January 11, 2012 [Page 16] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 [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 [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. [I-D.chown-v6ops-renumber-thinkabout] Chown, T., "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006. [I-D.jiang-6renum-enterprise] Jiang, S., and Liu B., " IPv6 Enterprise Network Renumbering Scenarios and Guidelines ", Working in Progress, July 2011. [LEROY] Leroy, D. and O. Bonaventure, "Preparing network configurations for IPv6 renumbering", International of Network Management, 2009, 13. Acknowledgments This work adopts significant amounts of content from [RFC5887] and [I-D.chown-v6ops-renumber-thinkabout], so thank for Brian Carpenter, Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, Alan Ford, and Stig Venaas. Some useful materials were provided by Oliver Bonaventure and his student Damien Leroy, thanks for them, too. Useful comments and contributions were made by George Wesley, and others. Liu & Jiang Expires January 11, 2012 [Page 17] Internet-Draft IPv6 Site Renumbering Gap Analysis July 2011 This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Bing Liu Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing P.R. China Email: leo.liubing@huawei.com Sheng Jiang Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing P.R. China Email: jiangsheng@huawei.com Liu & Jiang Expires January 11, 2012 [Page 18]