Network Working Group B. Liu Internet Draft S. Jiang Intended status: Informational Huawei Technologies Co., Ltd Expires: November 10, 2013 B. Carpenter University of Auckland S. Venaas Cisco Systems W. George Time Warner Cable May 9, 2013 IPv6 Site Renumbering Gap Analysis draft-ietf-6renum-gap-analysis-07.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 November 10, 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. Liu, et al. Expires November 10 2013 [Page 1] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 Abstract This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements of IPv6 renumbering. Through the gap analysis, the document provides a basis for future works that identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process. Table of Contents 1. Introduction ................................................. 4 2. Overall Requirements for Renumbering ......................... 4 3. Existing Components for IPv6 Renumbering ..................... 5 3.1. Relevant Protocols and Mechanisms ....................... 5 3.2. Management Tools ........................................ 6 3.3. Procedures/Policies ..................................... 7 4. Managing Prefixes ............................................ 7 4.1. Prefix Delegation ....................................... 7 4.2. Prefix Assignment ....................................... 7 5. Address Configuration ........................................ 8 5.1. Host Address Configuration .............................. 8 5.2. Router Address Configuration ............................ 9 6. Updating Address-relevant Entries ........................... 10 6.1. DNS Records Update ..................................... 10 6.2. In-host Server Address Update .......................... 11 6.3. Parameterized IP-specific Configuration ................ 11 7. Renumbering Event Management ................................ 13 7.1. Renumbering Notification ............................... 13 7.2. Synchronization Management ............................. 14 7.3. Renumbering Monitoring ................................. 14 8. Miscellaneous ............................................... 14 8.1. Multicast .............................................. 14 8.2. Mobility ............................................... 16 9. Gap Summary ................................................. 17 9.1. Managing Prefixes ...................................... 17 9.2. Address configuration .................................. 17 9.3. Address relevant entries update ........................ 17 9.4. Renumbering event management ........................... 18 9.5. Miscellaneous .......................................... 18 10. Gaps considered unsolvable ................................. 19 Liu, et al. Expires November 10, 2013 [Page 2] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 10.1. Address Configuration ................................. 19 10.2. Address-relevant Entries Update ....................... 19 10.3. Miscellaneous ......................................... 20 11. Security Considerations .................................... 20 12. IANA Considerations......................................... 21 13. Acknowledgments ............................................ 21 14. References ................................................. 21 14.1. Normative References .................................. 21 14.2. Informative References ................................ 22 Liu, et al. Expires November 10, 2013 [Page 3] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 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 [RFC4984]. 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. The gap analysis is organized according to the main steps of a renumbering process, which include prefix management, node address (re)configuration, and updating address- relevant entries in various devices such as firewalls, routers and servers, etc. Renumbering event management is presented independently from the steps of a renumbering process, in order to identify some operational and administrative gaps in renumbering. This document starts from existing work in [RFC5887] and [RFC4192]. This document does further analysis and identifies the valuable and solvable issues, digs out of some undiscovered gaps, and gives some solution suggestions. Renumbering nodes with static addresses has a particular set of problems, thus discussion of that space has been covered in a related document [RFC6866]. 2. Overall Requirements for Renumbering This section introduces the overall goals we want to achieve in a renumbering event. In general, we need to leverage renumbering automation to avoid human intervention as much as possible at reasonable cost. Some existing mechanisms have already provided useful ability. The automation can be divided into four aspects as follows. o Prefix delegation and delivery should be automatic and accurate in aggregation and coordination. Liu, et al. Expires November 10, 2013 [Page 4] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 o Address reconfiguration should be automatically achieved through standard protocols with minimum human intervention. o Address-relevant entry updates should be performed integrally and without error. o Renumbering event management is needed to provide the functions of renumbering notification, synchronization, and monitoring. Besides automation, session survivability is another important issue during renumbering since application outage is one of the most obvious impacts that make renumbering painful and expensive. Session survivability is a fundamental issue that cannot be solved within renumbering context only. However, IPv6's ability to overlap old and new prefixes (make before break) provides an enormous advantage and to use the address lifetime mechanisms in IPv6 Stateless Address Autoconfiguration (SLAAC) and Dynamic Host Configuration Protocol for IPv6 (DHCPv6). That is fully described in [RFC4192], which provides a smooth transition mechanism from old to new prefixes. In most of the cases, since we can set the transition period long enough to cover the on-going sessions, we consider this mechanism sufficient for avoiding session brokenness issue in IPv6 site renumbering. (Please note that if multiple addresses are running simultaneously on hosts, the address selection [RFC6724] needs to be carefully handled.) 3. Existing Components for IPv6 Renumbering Since renumbering is not a new issue, some protocols and mechanisms have already been utilized for renumbering. There were also some dedicated protocols and mechanisms developed for renumbering. This section briefly reviews these existing protocols and mechanisms to provide a basis for the gap analysis. 3.1. Relevant Protocols and Mechanisms 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 the basic mechanisms for host configuration. o When renumbering a host, SLAAC [RFC4862] may be used for address configuration with the new prefix(es). 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. Liu, et al. Expires November 10, 2013 [Page 5] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure addresses by starting RENEW actions when the current addresses' lease time are expired or they receive the reconfiguration messages initiated by the DHCPv6 servers. o DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated delegation of IPv6 prefixes using the DHCPv6. o [RFC2894] defined standard ICMPv6 messages for router renumbering. This is a dedicated protocol for renumbering, but we are not aware of it being used in real network deployment. 3.2. Management Tools Some renumbering operations could be automatically processed by management tools in order to make the renumbering process more efficient and accurate. The tools may be designed specifically for renumbering, or common tools could be utilized for some of the renumbering operations. Following are examples of these tools. o IP address management (IPAM) tools. There are both commercial and open-source solutions. IPAM tools are used to manage IP address plans, and usually integrate the DHCPv6 and DNS services together as a whole solution. Many mature commercial tools can support management operations, but normally they do not have dedicated renumbering functions. However, the integrated DNS/DHCPv6 services and address management function can obviously facilitate the renumbering process. o Some organizations use third-party tools like [cfengine] to push configuration to devices. This is sometimes used as a supplement to vendor specific solutions. 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. Liu, et al. Expires November 10, 2013 [Page 6] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 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 [RFC6879] 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 IPv6 enterprise site, the key procedural issue is switching the old prefix (es) to the new one(s). A new short prefix may be divided into longer ones for subnets. So we need to carefully manage the prefixes to ensure they are synchronized and coordinated in the whole network. 4.1. Prefix Delegation Usually, the new short prefix(es) comes down from the operator(s) and is received by DHCPv6 servers or routers inside the enterprise networks (or through off-line human communication). The short prefix(es) could be automatically delegated through DHCPv6-PD. Then the downlink DHCPv6 servers or routers can begin advertising the longer prefixes to the subnets. The delegation routers might need to renumber themselves with the new delegated prefixes. So there should be a mechanism informing the router to renumber themselves by delegated prefixes; and there also should be a mechanism for the routers to derive addresses automatically based on the delegated prefixes. 4.2. Prefix Assignment When subnet routers receive the longer prefixes, they can directly assign them to the hosts. Host address configuration, rather than routers, is the primary concern for prefix assignment which is described in the following section 5.1. Liu, et al. Expires November 10, 2013 [Page 7] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 5. Address Configuration 5.1. Host Address Configuration o SLAAC/DHCPv6 interaction problems Both of the DHCPv6 and Neighbor Discovery (ND) protocols have IP address configuration function. They are suitable for different scenarios. 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 DHCPv6 according to [I.D ietf-dhc-host-gen-id]). The DHCPv6-configured hosts can reconfigure addresses by initiating RENEW sessions when the current addresses' lease times are expired or when they receive reconfiguration messages initiated by the DHCPv6 servers. Sometimes the two address configuration modes may both be available in one network. This would add more or less additional complexity for both the hosts and the network management. With the flags defined in RA (ManagedFlag indicating the DHCPv6 service available in the network; OtherConfigFlag indicating other configurations such as DNS/routing), the two separated address configuration modes are correlated. However, the ND protocol did not define the flags as prescriptive but only as advisory. This has led to variation in the behavior of hosts when interpreting the flags. Different operating systems have followed different approaches. (For more details, please refer to [I-D.liu-bonica-dhcpv6-slaac-problem] and [I-D.liu-6renum-dhcpv6-slaac-switching].) The impact of ambiguous M/O flags includes the following aspects: - DHCPv6-configured hosts might not be able to be renumbered by RA It is unclear whether a DHCPv6 configured host will accept address configuration though RA messages, especially when M flag transitioning from 1 to 0; this depends on the implementation of the operating system. It might not be possible for administrators to only use RA messages for renumbering, since renumbering might fail on some already DHCPv6-configured hosts. It means administrators have to use DHCPv6 reconfiguration for some DHCPv6- configured hosts. It is not convenient and DHCPv6 reconfiguration is not suitable for bulk usage as analyzed in below. - DHCPv6-configured hosts might not be able to learn new RA prefixes Liu, et al. Expires November 10, 2013 [Page 8] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 [RFC5887] mentioned that DHCPv6-configured hosts may want to learn about the upstream availability of new prefixes or loss of prior prefixes dynamically by deducing this from periodic RA messages. Relevant standards ([RFC4862],[RFC3315]) are ambiguous about what approach should be taken by a DHCPv6-configured host when it receives RA messages containing a new prefix. Current behavior depends on the operating system of the host and cannot be predicted or controlled by the network. - SLAAC-configured hosts might not be able to add DHCPv6 address(es) The behavior when the host receives RA messages with M flag set is unspecified. The host may start a DHCPv6 session and receive the DHCPv6 address configuration, or it may just ignore the messages. If the network side wants the hosts to start DHCPv6 configuration, it is just out of control of the network side. o DHCPv6 reconfigure bulk usage [RFC5887] mentioned that "DHCPv6 reconfiguration doesn't appear to be widely used for bulk renumbering purposes". The reconfiguration defined in [RFC3315] needs to establish a session between DHCPv6 server and client. This could be considered as a stateful approach which needs much resource on the server to maintain the renumbering sessions. This is probably one of the reasons that DHCPv6 reconfiguration is not suitable for bulk usage. Another limitation of DHCPv6 reconfiguration is that it only allows the messages to be delivered to unicast addresses. So if we want to use it for bulk renumbering, stateless DHCPv6 reconfiguration with multicast may be needed. However, this may involve protocol modification. 5.2. Router Address Configuration o Learning new prefixes 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 Liu, et al. Expires November 10, 2013 [Page 9] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 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 As [RFC2072] mentioned, some routers cache IP addresses in some situations, so routers might need to be restarted as a result of site renumbering. While most modern systems support a cache-clear function that eliminates the need for restarts, there are always exceptions that must be taken into account. o Router naming [RFC4192] suggests 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 currently it is present in most IPSec VPN implementations. However, many administrators may need to be alerted to the fact that it could be utilized to avoid manual modification during renumbering. 6. Updating Address-relevant Entries In conjunction with renumbering the nodes, any configuration or data store containing previous addresses must be updated as well. Some examples include DNS records and filters in various entities such as ACLs in firewalls/gateways. 6.1. DNS Records Update o Secure Dynamic DNS update In real network operations, DNS update is normally achieved 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. Secure Dynamic DNS Update has been widely supported by the major DNS implementations, but it hasn't been widely deployed. 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. However, it is Liu, et al. Expires November 10, 2013 [Page 10] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 still not easy to use, the operational complexity of Secure Dynamic DNS Update is still a gao. (But for some commercial DNS systems, the operational issue may be much easier, since it could be integrated with services like DHCP provided by the same vendor so that the dynamic DNS update could be silently enabled.) 6.2. In-host Server Address Update While DNS stores addresses of hosts in servers, hosts are also configured with addresses of servers such as DNS server, radius server. While renumbering, the hosts must update these addresses if the server addresses changed. (Addresses of DHCPv6 servers do not need to be updated. They are dynamically discovered using DHCPv6 relevant multicast addresses.) The DNS server addresses for hosts could be configured by DHCPv6. In stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to specify valid time for the DNS configuration. But in stateful DHCPv6, current protocols could not indicate hosts the valid time of DNS configuration. If the DNS server has been renumbered, and the DHCP lease time has not expired yet, then the hosts would still use the old DNS server address(es). It might be better that the hosts could renew the DHCP DNS configuration before the lease time, especially there might be some extreme situations that the lease time need to be long. In this case how the DHCP server could learn the proper DNS configuration valid time is also an issue. 6.3. Parameterized IP-specific Configuration Besides the DNS records and the in-host server address entries, there are also many places in which the IP addresses are configured, for example, filters such as ACL and routing policies. There are even more sophisticated cases where the IP addresses are used for deriving values, for example, using the unique portion of the loopback address to generate an ISIS net ID. Ideally, a layer of abstraction for IP-specific configuration within various devices (routers, switches, hosts, servers, etc.) is needed. However, this cannot be achieved in one step. One possible improvement is to make the IP-specific configuration parameterized. Two aspects of parameterized configuration could be considered to achieve this. o Self-contained Configuration in Individual device In an ideal way, the IP addresses can be defined as a value once, and then the administrators can use either keywords or variables to call Liu, et al. Expires November 10, 2013 [Page 11] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 the value in other places such as a sort of internal inheritance in CLI (command line interface) or other local configurations. This makes it easier to manage a renumbering event by reducing the number of places where a device's configuration must be updated. However, it still means that every device needs to be touched, but only once instead of having to inspect the whole configuration to ensure that none of the separate places that a given IP address occurs is missed. Among the current devices, some routers support defining multiple loopback interfaces which 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 can be considered as a kind of parameterized self-contained configuration. But this only applies certain use cases; it is impossible to use the loopback interfaces to represent external devices and it is not always possible to call loopback interfaces in many other configurations. Parameterized self-contained configuration is still a gap for current devices. o Unified Configuration Management among Devices This is a more formalized central configuration management system, where all changes are made in one place and the system manages how to push the changes to the individual devices. This issue contains two aspects as the following. - Configuration Aggregation Configuration 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 configuration aggregation, it is hard to get all the relevant configurations through one place. - Configuration Update Automation As mentioned in section 3.2, [LEROY] proposed a mechanism which can automatically update the configurations. The mechanism utilizes macros suitable for various devices such as routers, firewalls. to update the configurations based on the new prefix. Such automation tool is valuable for renumbering because it can reduce manual operation which is error-prone and inefficiency. Besides the macros, [LEROY] also proposed to use SOAP to deliver the macros to the devices. As well as SOAP we may consider whether Liu, et al. Expires November 10, 2013 [Page 12] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 it is possible and suitable to use other standardized protocols such as NETCONF [RFC4714]. But in current real networks, most of the devices use vendor- private protocols to update configurations, so it is not necessarily valid to assume that there is going to be a formalized configuration management system to leverage. Although there are some vendor-independent tools as mentioned in section 3.2, a standard and comprehensive way of uniformly updating configurations in multi-vendor devices is still a big gap currently. 7. Renumbering Event Management From the perspective of network management, renumbering is a kind of event which may need additional process to make it more easy and manageable. 7.1. Renumbering Notification If hosts or servers are aware of a renumbering event happening, it may benefit the relevant process. Following are several examples of such additional process that may ease the renumbering. o A notification mechanism may be needed to indicate to hosts that a renumbering event has changed some DNS records in DNS servers (normally, in an enterprise it/they is/are (a) local recursive DNS server(s).), and then the hosts might want to refresh the DNS cache. That mechanism may also need to indicate that such a change will happen at a specific time in the future. o As suggested in [RFC4192], if the DNS service can be given prior notice about a renumbering event, then people could reduce the delay in the transition to new IPv6 addresses, thus improve the efficiency of renumbering. o Router awareness: in a site with multiple domains which are connected by border routers, all border routers should be aware of renumbering in one domain or multiple domains, and update the internal forwarding tables and the address/prefix based filters accordingly to correctly handle inbound packets. Liu, et al. Expires November 10, 2013 [Page 13] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 o Ingress filtering: ISPs normally enable ingress filter to drop packets with source addresses from other ISPs at the end site routers to prevent IP spoofing [RFC2827]. In a multihomed site with multiple PA prefixes, the ingress router of ISP A should be notified if the ISP B initiates a renumbering event in order to properly update its filters to permit the new legitimate prefix (es). 7.2. Synchronization Management o DNS update synchronization The DNS changes must be coordinated with the changes of node address configuration. DNS has a latency issue of propagating information from the server to the resolver. The latency is mainly caused by TTL assigned to individual DNS records and the timing of updates from primary to secondary servers [RFC4192]. Currently, there are no mechanisms to deal with the latency issue. 7.3. Renumbering Monitoring While treating renumbering as a network event, mechanisms to monitor the renumbering process might be needed to inform the administrators whether the renumbering has been successfully done. Considering the address configuration operation might be stateless (if ND is used for renumbering), it is difficult for monitoring. 8. Miscellaneous Since multicast and mobility are special use cases which might not be included in routine/common renumbering operations, they are separately discussed as miscellaneous in this section. 8.1. Multicast In the perspective of interface renumbering operations, renumbering a multicast address is the same with renumbering a unicast address. So this section mainly discusses the issues from the perspective of the impact to the multicast application systems caused by renumbering. Renumbering also has an impact on multicast. Renumbering of unicast addresses affects multicast even if the multicast addresses are not changed. There may also be cases where the multicast addresses need to be renumbered. o Renumbering of multicast sources Liu, et al. Expires November 10, 2013 [Page 14] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 If a host that is a multicast source is renumbered, the application on the host may need to be restarted for it to successfully send packets with the new source address. For ASM (Any-Source Multicast) the impact on a receiver is that a new source appears to start sending, and it no longer receives from the previous source. Whether this is an issue depends on the application, but we believe it is likely to not be a major issue. For SSM (Source-Specific Multicast) however, there is one significant problem. The receiver needs to learn which source addresses it must join. Some applications may provide their own method for learning sources, where the source application may somehow signal the receiver. Otherwise, the receiver may e.g. need to get new SDP information with the new source address. This is similar to how to learn a new group address, see the "Renumbering of multicast addresses" topic below. o Renumbering of Rendezvous-Point If the unicast addresses of routers in a network are renumbered, then the RP (Rendezvous-Point) address is also likely to change for at least some groups. An RP address is needed by PIM-SM for providing ASM, and for Bidir PIM. Changing the RP address is not a major issue, except that the multicast service may be impacted while the new RP addresses are configured. If dynamic protocols are used for distributing group-to-RP mappings, the change can be fairly quick, and any impact should be only for a very brief time. However, if routers are statically configured, this depends on how long it takes to update all the configurations. For PIM-SM one typically switches to SPT (Shortest-Path-Tree) when the first packet is received by the last-hop routers. Forwarding on the SPT should not be impacted by change of IP address. Network operator should be careful not deprecate the previous mapping before configuring a new one, because implementations may revert to Dense Mode if no RP is configured. o Renumbering of multicast addresses In general multicast addresses can be chosen independently of the unicast addresses, and the multicast addresses can remain fixed even if the unicast addresses are renumbered. However, for IPv6 there are useful ways of deriving multicast addresses from unicast addresses, such as unicast-prefix-based IPv6 Multicast Addresses [RFC3306] and Embedded-RP IPv6 Multicast Addresses [RFC3956]. In that case the multicast addresses used may have to be renumbered. Liu, et al. Expires November 10, 2013 [Page 15] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 Renumbering group addresses may be complicated. For multicast, it is common to use literal addresses, and not DNS. When multicast addresses are changed, source applications need to be reconfigured and restarted. Multicast receivers need to learn the new group addresses to join. Note that for SSM, receivers need to learn which multicast channels to join. A channel is a source and group pair. This means that for an SSM application, a change of source address is likely to have the same effect as a change of group address. Some applications may have dynamic methods of learning which groups (and possibly sources) to join. If not, the application may have to be reconfigured and restarted. One common way for receivers to learn the necessary parameters is by use of SDP. SDP information may be distributed via various application protocols, or it may be from a file. An SDP file may be distributed via HTTP, email etc. If a user is using a web browser and clicking on a link to launch the application with the necessary data, it may be a matter of closing the current application, and re- clicking the link. In summary, currently the multicast renumbering issues are basically handled by application-specific methods. There is no standard way to guarantee multicast service could live across a renumbering event. 8.2. Mobility As described in [RFC5887], if a mobile node's home address changes unexpectedly, the node can be informed of the new global routing prefix used at the home site through the Mobile Prefix Solicitation and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. But if the mobile node is unfortunately disconnected at the time of home address renumbering, it will no longer know a valid subnet anycast address for its home agent, leaving it to deduce a valid address on the basis of DNS information. So, for Mobile IP, we need a better mechanism to handle change of home agent address while mobile is disconnected. Liu, et al. Expires November 10, 2013 [Page 16] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 9. Gap Summary 9.1. Managing Prefixes o A mechanism informing the router to renumber themselves by delegated prefixes o A mechanism for the routers to derive addresses automatically based on the delegated prefixes. 9.2. Address configuration o Host address configuration - DHCPv6-only management might not applicable on some of current implementations - DHCPv6-configured hosts might not able to be renumbered by RA on some of current implementations - DHCPv6-configured hosts might not able to learn new RA prefixes on some of current implementations - SLAAC-configured hosts might not able to add DHCPv6 address(es) on some of current implementations - DHCPv6 reconfigure not suitable for bulk usage o Router address configuration - A mechanism for interior routers in multihomed site to learn which upstream providers and prefixes were currently reachable - Cache-clear might need restart (rarely in modern routers) - Using router domain names is not widely learned/deployed by administrators 9.3. Address relevant entries update o DNS records update - Secure Dynamic DNS Update has operational complexity and seldom used in real networks o In-host server address update Liu, et al. Expires November 10, 2013 [Page 17] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 - a mechanism is needed for the hosts to renew the DHCP DNS configuration before the lease time when the DNS server is renumbered - It might be better to extend stateful DHCPv6 to indicate hosts the associated DNS server valid time when making DNS configuration. o Parameterized IP-specific Configuration - Devices don't support parameterized configuration, administrators need to touch every places where IP addresses were configured - It is hard to get all the address-relevant configurations spread in various devices through one place - uniformly update configurations in multi-vendor devices is a big gap currently 9.4. Renumbering event management o Renumbering notification - A mechanism to indicate hosts local recursive DNS is going to be renumbered - A prior notice about a renumbering event for DNS - A mechanism for border routers to know internal partial renumbering - For multihomed sites, a mechanism to notify the egress router of ISPA that egress router connecting to ISPB initiates renumbering o Synchronization management - DNS information propagating latency issue o Renumbering monitoring - Mechanisms to monitor the process and feedback of renumbering may be needed 9.5. Miscellaneous o Multicast Liu, et al. Expires November 10, 2013 [Page 18] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 - Mechanism for SSM receivers to learn the source addresses when multicast sources are renumbered o Mobility - A better mechanism to handle change of home agent address while mobile is disconnected. 10. Gaps considered unsolvable This section lists gaps have been identified by other documents but are considered unsolvable. 10.1. Address Configuration 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. 10.2. Address-relevant Entries Update o DNS entries commonly have matching Reverse DNS entries which will also need to be updated during renumbering. o DNS data structure optimization [RFC2874] proposed an experimental A6 record type for DNS recording of IPv6 address and prefix. Several extensions to DNS query and processing were also proposed. With the A6 record and the extensions, an IPv6 address could be defined by using multiple DNS records. This feature would increase the complexity of resolvers but reduce the cost of zone file maintenance, so renumbering could be easier than with the AAAA record. But the A6 record has not been widely used, and it has been moved to historic status [RFC6563]. However, the idea of structured record to separate prefix and suffix is still valuable for renumbering, but it might not be able to develop a more proper new DNS record type in a short time. o DNS authority Liu, et al. Expires November 10, 2013 [Page 19] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 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. It is an operational and policy issue and this document considers it not suitable to be solved through technical approach or bring additional protocol/mechanism to standardize the interaction between DNS systems for authority negotiations. 10.3. Miscellaneous o For transport layer, [RFC5887] said that TCP connections and UDP flows are rigidly bound to a given pair of IP addresses. o For application layer, in general, we can assert that any implementation is at risk from renumbering if it does not check whether an address is valid each time it starts session resumption (e.g. a laptop wakes from sleep state). It is also more of less risky when it opens a new communications session by using cached addresses. We considered the above two points (ID/Locator overloading in transport layer & address caching in app layer) are fundamental issues that might not be proper to deal with them just in terms of renumbering. 11. 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, 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 Secure Neighbor Discovery (SEND, [RFC3971]) deployment may be needed to validate prefixes. o Influence on Security Controls During renumbering, security controls (e.g. ACLs) protecting legitimate resources should not be interrupted. For example, if some Liu, et al. Expires November 10, 2013 [Page 20] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 addresses are in a blacklist, they should not escape from the blacklist due to renumbering. 12. IANA Considerations This draft does not request any IANA actions. 13. Acknowledgments This work adopts significant amounts of content from [RFC5887] and particularly the "DNS Authority" topic in section 10.2 is from [draft-chown-v6ops-renumber-thinkabout]. Both of the two documents are important input for this work, that some principles/considerations applied in this work are implicitly inherited from them. So thanks go to Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, and Alan Ford. Some useful materials were provided by Oliver Bonaventure and his student Damien Leroy. Many useful comments and contributions were made by Lee Howard, Robert Sparks, S. Moonesamy, Fred Baker, Eric Vyncke, Phillips Matthew, Gustav Reinsberger, Teco Boot and other members of 6renum WG. This document was prepared using 2-Word-v2.0.template.dot. 14. References 14.1. Normative References [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, et al. Expires November 10, 2013 [Page 21] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 [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. 14.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. [RFC2874] Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, August 2000. [RFC3306] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3956] P. Savola, B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3965, November 2004. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005. [RFC4714] Enns, R., "NETCONF Configuration Protocol", RFC 4714, December 2006. [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. Liu, et al. Expires November 10, 2013 [Page 22] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to Historic Status", RFC 6563, May 2012. [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC6275] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013. [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013. [I-D.ietf-dhc-secure-dhcpv6] Jiang, S., and Shen S., "Secure DHCPv6 Using CGAs", working in progress, March 2012. [I-D.liu-6renum-dhcpv6-slaac-switching] Liu, B., "DHCPv6/SLAAC Address Configuration Switching for Host Renumbering", Working in Progress, July 2012. [I-D.liu-bonica-dhcpv6-slaac-problem] Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Working in Progress, February 2013. [cfengine]http://cfengine.com/what-is-cfengine [LEROY] Leroy, D. and O. Bonaventure, "Preparing network configurations for IPv6 renumbering", International of Network Management, 2009, Liu, et al. Expires November 10, 2013 [Page 23] Internet-Draft IPv6 Site Renumbering Gap Analysis May 2013 Authors' Addresses Bing Liu Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China Email: leo.liubing@huawei.com Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Rd. Hai-Dian District, Beijing 100095 P.R. China Email: jiangsheng@huawei.com Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA Email: stig@cisco.com Liu, et al. Expires October 28, 2013 [Page 24] Internet-Draft IPv6 Site Renumbering Gap Analysis April 2013 Wesley George Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 USA Phone: +1 703-561-2540 Email: wesley.george@twcable.com