GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5887

Internet Engineering Task Force (IETF) B. Carpenter Request for Comments: 5887 Univ. of Auckland Category: Informational R. Atkinson ISSN: 2070-1721 Extreme Networks

                                                             H. Flinck
                                                Nokia Siemens Networks
                                                              May 2010
                    Renumbering Still Needs Work

Abstract

 This document reviews the existing mechanisms for site renumbering
 for both IPv4 and IPv6, and it identifies operational issues with
 those mechanisms.  It also summarises current technical proposals for
 additional mechanisms.  Finally, there is a gap analysis identifying
 possible areas for future work.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5887.

Copyright Notice

 Copyright (c) 2010 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.

Carpenter, et al. Informational [Page 1] RFC 5887 Renumbering Still Needs Work May 2010

Table of Contents

 1. Introduction ....................................................3
 2. Existing Host-Related Mechanisms ................................5
    2.1. DHCP .......................................................5
    2.2. IPv6 Stateless Address Autoconfiguration ...................6
    2.3. IPv6 ND Router/Prefix Advertisements .......................7
    2.4. PPP ........................................................7
    2.5. DNS Configuration ..........................................8
    2.6. Dynamic Service Discovery ..................................9
 3. Existing Router-Related Mechanisms ..............................9
    3.1. Router Renumbering .........................................9
 4. Existing Multi-Addressing Mechanism for IPv6 ...................10
 5. Operational Issues with Renumbering Today ......................11
    5.1. Host-Related Issues .......................................11
         5.1.1. Network-Layer Issues ...............................11
         5.1.2. Transport-Layer Issues .............................13
         5.1.3. DNS Issues .........................................14
         5.1.4. Application-Layer Issues ...........................14
    5.2. Router-Related Issues .....................................16
    5.3. Other Issues ..............................................17
         5.3.1. NAT State Issues ...................................17
         5.3.2. Mobility Issues ....................................18
         5.3.3. Multicast Issues ...................................18
         5.3.4. Management Issues ..................................19
         5.3.5. Security Issues ....................................21
 6. Proposed Mechanisms ............................................22
    6.1. SHIM6 .....................................................22
    6.2. MANET Proposals ...........................................22
    6.3. Other IETF Work ...........................................23
    6.4. Other Proposals ...........................................23
 7. Gaps ...........................................................24
    7.1. Host-Related Gaps .........................................24
    7.2. Router-Related Gaps .......................................25
    7.3. Operational Gaps ..........................................25
    7.4. Other Gaps ................................................26
 8. Security Considerations ........................................26
 9. Acknowledgements ...............................................27
 10. Informative References ........................................27
 Appendix A.  Embedded IP Addresses ................................34

Carpenter, et al. Informational [Page 2] RFC 5887 Renumbering Still Needs Work May 2010

1. Introduction

 In early 1996, the IAB published a short RFC entitled "Renumbering
 Needs Work" [RFC1900], which the reader is urged to review before
 continuing.  Almost ten years later, the IETF published "Procedures
 for Renumbering an IPv6 Network without a Flag Day" [RFC4192].  A few
 other RFCs have touched on router or host renumbering: [RFC1916],
 [RFC2071], [RFC2072], [RFC2874], [RFC2894], and [RFC4076].
 In fact, since 1996, a number of individual mechanisms have become
 available to simplify some aspects of renumbering.  The Dynamic Host
 Configuration Protocol (DHCP) is available for IPv4 [RFC2131] and
 IPv6 [RFC3315].  IPv6 includes Stateless Address Autoconfiguration
 (SLAAC) [RFC4862], and this includes Router Advertisements (RAs) that
 include options listing the set of active prefixes on a link.  The
 Point-to-Point Protocol (PPP) [RFC1661] also allows for automated
 address assignment for both versions of IP.
 Despite these efforts, renumbering, especially for medium to large
 sites and networks, is widely viewed as an expensive, painful, and
 error-prone process, and is therefore avoided by network managers as
 much as possible.  Some would argue that the very design of IP
 addressing and routing makes automatic renumbering intrinsically
 impossible.  In fact, managers have an economic incentive to avoid
 having to renumber, and many have resorted to private addressing and
 Network Address Translation (NAT) as a result.  This has the highly
 unfortunate consequence that any mechanisms for managing the scaling
 problems of wide-area (BGP4) routing that require occasional or
 frequent site renumbering have been consistently dismissed as
 unacceptable.  But none of this means that we can duck the problem,
 because as explained below, renumbering is sometimes unavoidable.
 This document aims to explore the issues behind this problem
 statement, especially with a view to identifying the gaps and known
 operational issues.
 It is worth noting that for a very large class of users, renumbering
 is not in fact a problem of any significance.  A domestic or small
 office user whose device operates purely as a client or peer-to-peer
 node is in practice renumbered at every restart (even if the address
 assigned is often the same).  A user who roams widely with a laptop
 or pocket device is also renumbered frequently.  Such users are not
 concerned with the survival of very long-term application sessions
 and are in practice indifferent to renumbering.  Thus, this document
 is mainly concerned with issues affecting medium to large sites.

Carpenter, et al. Informational [Page 3] RFC 5887 Renumbering Still Needs Work May 2010

 There are numerous reasons why such sites might need to renumber in a
 planned fashion, including:
 o  Change of service provider, or addition of a new service provider,
    when provider-independent addressing is not an option.
 o  A service provider itself has to renumber.
 o  Change of site topology (i.e., subnet reorganisation).
 o  Merger of two site networks into one, or split of one network into
    two or more parts.
 o  During IPv6 deployment, change of IPv6 access method (e.g., from
    tunneled to native).
 The most demanding case would be unplanned automatic renumbering,
 presumably initiated by a site border router, for reasons connected
 with wide-area routing.  There is already a degree of automatic
 renumbering for some hosts, e.g., IPv6 "privacy" addresses [RFC4941].
 It is certainly to be expected that as the pressure on IPv4 address
 space intensifies in the next few years, there will be many attempts
 to consolidate usage of addresses so as to avoid wastage, as part of
 the "end game" for IPv4, which necessarily requires renumbering of
 the sites involved.  However, strategically, it is more important to
 implement and deploy techniques for IPv6 renumbering, so that as IPv6
 becomes universally deployed, renumbering becomes viewed as a
 relatively routine event.  In particular, some mechanisms being
 considered to allow indefinite scaling of the wide-area routing
 system might assume site renumbering to be a straightforward matter.
 There is work in progress that, if successful, would eliminate some
 of the motivations for renumbering.  In particular, some types of
 solutions to the problem of scalable routing for multihomed sites
 would likely eliminate both multihoming and switching to another ISP
 as reasons for site renumbering.
 Several proposed identifier/locator split schemes provide good
 examples, including at least Identifier Locator Network Protocol
 [ILNP], Locator/ID Separation Protocol [LISP], and Six/One [SIX-ONE]
 (in alphabetical order).  The recent discussion about IPv6 Network
 Address Translation (IPv6 NAT) provides a separate example [NAT66].
 While remaining highly contentious, this approach, coupled with
 unique local addresses or a provider-independent address prefix,
 would appear to eliminate some reasons for renumbering in IPv6.
 However, even if successful, such solutions will not eliminate all of
 the reasons for renumbering.  This document does not take any

Carpenter, et al. Informational [Page 4] RFC 5887 Renumbering Still Needs Work May 2010

 position about development or deployment of protocols or technologies
 that would make long-term renumbering unnecessary, but rather deals
 with practical cases where partial or complete renumbering is
 necessary in today's Internet.
 IP addresses do not have a built-in lifetime.  Even when an address
 is leased for a finite time by DHCP or SLAAC, or when it is derived
 from a DNS record with a finite time to live (TTL) value, this
 information is unavailable to applications once the address has been
 passed to an upper layer by the socket interface.  Thus, a
 renumbering event is almost certain to be an unpredictable surprise
 from the point of view of any application software using the address.
 Many of the issues listed below derive from this fact.

2. Existing Host-Related Mechanisms

2.1. DHCP

 At a high level, DHCP [RFC2131] [RFC3315] offers similar support for
 renumbering for both versions of IP.  A host requests an address when
 it starts up, the request might be delivered to a local DHCP server
 or via a relay to a central server, and if all local policy
 requirements are met, the server will provide an address with an
 associated lifetime, and various other network-layer parameters (in
 particular, the subnet mask and the default router address).
 From an operational viewpoint, the interesting aspect is the local
 policy.  Some sites require pre-registration of MAC (Media Access
 Control) addresses as a security measure, while other sites permit
 any MAC address to obtain an IP address.  Similarly, some sites use
 DHCP to provide the same IP address to a given MAC address each time
 (this is sometimes called "Static DHCP"), while other sites do not
 (this is sometimes called "Dynamic DHCP"), and yet other sites use a
 combination of these two modes where some devices (e.g., servers,
 Voice over IP (VoIP) handsets) have a relatively static IP address
 that is provisioned via DHCP while other devices (e.g., portable
 computers) have a different IP address each time they connect to the
 network.  As an example, many universities in the United States and
 United Kingdom require MAC address registration of faculty, staff,
 and student devices (including handheld computers with wireless
 connections).
 These policy choices interact strongly with whether the site has what
 might be called "strong" or "weak" asset management.  At the strong
 extreme, a site has a complete database of all equipment allowed to
 be connected, certainly containing the MAC address(es) for each host,
 as well as other administrative information of various kinds.  Such a
 database can be used to generate configuration files for DHCP, DNS,

Carpenter, et al. Informational [Page 5] RFC 5887 Renumbering Still Needs Work May 2010

 and any access control mechanisms that might be in use.  For example,
 only certain MAC addresses might be allowed to get an IP address on
 certain subnets.  At the weak extreme, a site has no asset
 management, any MAC address may get a first-come first-served IP
 address on any subnet, and there is no network-layer access control.
 The IEEE 802.1X standard [IEEE.802-1X] [IEEE.802-1X-REV] specifies a
 connection mechanism for wired/wireless Ethernet that is often
 combined with DHCP and other mechanisms to form, in effect, a network
 login.  Using such a network login, the user of a device newly
 connecting to the network must provide both identity and
 authentication before being granted access to the network.  As part
 of this process, the network control point will often configure the
 point of network connection for that specific user with a range of
 parameters -- such as Virtual LAN (VLAN), Access Control Lists
 (ACLs), and Quality-of-Service (QoS) profiles.  Other forms of
 network login also exist, often using an initial web page for user
 identification and authentication.  The latter approach is commonly
 used in hotels or cafes.
 In principle, a site that uses DHCP can renumber its hosts by
 reconfiguring DHCP for the new address range.  The issues with this
 are discussed below.

2.2. IPv6 Stateless Address Autoconfiguration

 SLAAC, although updated recently [RFC4862], was designed prior to
 DHCPv6 and was intended for networks where unattended automatic
 configuration was preferred.  Ignoring the case of an isolated
 network with no router, which will use link-local addresses
 indefinitely, SLAAC follows a bootstrap process.  Each host first
 gives itself a link-local address, and then needs to receive a link-
 local multicast Router Advertisement (RA) [RFC4861] that tells it the
 routeable subnet prefix and the address(es) of the default router(s).
 A node may either wait for the next regular RA or solicit one by
 sending a link-local multicast Router Solicitation.  Knowing the link
 prefix from the RA, the node may now configure its own address.
 There are various methods for this, of which the basic one is to
 construct a unique 64-bit identifier from the interface's MAC
 address.
 We will not describe here the IPv6 processes for Duplicate Address
 Detection (DAD), Neighbour Discovery (ND), and Neighbour
 Unreachability Discovery (NUD).  Suffice it to say that they work,
 once the initial address assignment based on the RA has taken place.

Carpenter, et al. Informational [Page 6] RFC 5887 Renumbering Still Needs Work May 2010

 The contents of the RA message are clearly critical to this process
 and its use during renumbering.  An RA can indicate more than one
 prefix, and more than one router can send RAs on the same link.  For
 each prefix, the RA indicates two lifetimes: "preferred" and "valid".
 Addresses derived from this prefix must inherit its lifetimes.  When
 the valid lifetime expires, the prefix is dead and the derived
 address must not be used any more.  When the preferred lifetime is
 expired (or set to zero) the prefix is deprecated, and must not be
 used for any new sessions.  Thus, setting a preferred lifetime that
 is zero or finite is SLAAC's warning that renumbering will occur.
 SLAAC assumes that the new prefix will be advertised in parallel with
 the deprecated one, so that new sessions will use addresses
 configured under the new prefix.

2.3. IPv6 ND Router/Prefix Advertisements

 With IPv6, a Router Advertisement not only advertises the
 availability of an upstream router, but also advertises routing
 prefix(es) valid on that link (subnetwork).  Also, the IPv6 RA
 message contains a flag indicating whether or not the host should use
 DHCPv6 to configure.  If that flag indicates that the host should use
 DHCPv6, then the host is not supposed to autoconfigure itself as
 outlined in Section 2.2.  However, there are some issues in this
 area, described in Section 5.1.1.
 In an environment where a site has more than one upstream link to the
 outside world, the site might have more than one valid routing
 prefix.  In such cases, typically all valid routing prefixes within a
 site will have the same prefix length.  Also, in such cases, it might
 be desirable for hosts that obtain their addresses using DHCPv6 to
 learn about the availability of upstream links dynamically, by
 deducing from periodic IPv6 RA messages which routing prefixes are
 currently valid.  This application seems possible within the IPv6
 Neighbour Discovery architecture, but does not appear to be clearly
 specified anywhere.  So, at present, this approach for hosts to learn
 about availability of new upstream links or loss of prior upstream
 links is unlikely to work with currently shipping hosts or routers.

2.4. PPP

 "The Point-to-Point Protocol (PPP)" [RFC1661] includes support for a
 Network Control Protocol (NCP) for both IPv4 and IPv6.
 For IPv4, the NCP is known as IPCP [RFC1332] and allows explicit
 negotiation of an IP address for each end.  PPP endpoints acquire
 (during IPCP negotiation) both their own address and the address of
 their peer, which may be assumed to be the default router if no
 routing protocol is operating.  Renumbering events arise when IPCP

Carpenter, et al. Informational [Page 7] RFC 5887 Renumbering Still Needs Work May 2010

 negotiation is restarted on an existing link, when the PPP connection
 is terminated and restarted, or when the point-to-point medium is
 reconnected.  Peers may propose either the local or remote address or
 require the other peer to do so.  Negotiation is complete when both
 peers are in agreement.  In practice, if no routing protocol is used,
 as in a subscriber/provider environment, then the provider proposes
 both addresses and requires the subscriber either to accept the
 connection or to abort.  Effectively, the subscriber device is
 renumbered each time it connects for a new session.
 For IPv6, the NCP is IP6CP [RFC5072] and is used to configure an
 interface identifier for each end, after which link-local addresses
 may be created in the normal way.  In practice, each side can propose
 its own identifier and renegotiation is only necessary when there is
 a collision, or when a provider wishes to force a subscriber to use a
 specific interface identifier.  Once link-local addresses are
 assigned and IP6CP is complete, automatic assignment of global scope
 addresses is performed by the same methods as with multipoint links,
 i.e., either SLAAC or DHCPv6.  Again, in a subscriber/provider
 environment, this allows renumbering per PPP session.

2.5. DNS Configuration

 A site must provide DNS records for some or all of its hosts, and of
 course these DNS records must be updated when hosts are renumbered.
 Most sites will achieve this by maintaining a DNS zone file (or a
 database from which it can be generated) and loading this file into
 the site's DNS server(s) whenever it is updated.  As a renumbering
 tool, this is clumsy but effective.  Clearly perfect synchronisation
 between the renumbering of the host and the updating of its A or AAAA
 record is impossible.  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.
 There are widespread reports that the freely available BIND DNS
 software (which is what most UNIX hosts use), Microsoft Windows (XP
 and later), and Mac OS X all include support for Secure Dynamic DNS
 Update.  So do many home gateways.  Further, there are credible
 reports that these implementations are interoperable when configured
 properly ([DNSBOOK] p. 228 and p. 506).
 Commonly used commercial DNS and DHCP servers (e.g., Windows Server)
 often are deployed with Secure Dynamic DNS Update also enabled.  In
 some cases, merely enabling both the DNS server and the DHCP server
 might enable Secure Dynamic DNS Update as an automatic side effect
 ([DNSBOOK] p. 506).  So in some cases, sites might have deployed

Carpenter, et al. Informational [Page 8] RFC 5887 Renumbering Still Needs Work May 2010

 Secure Dynamic DNS Update already, without realising it.  An
 additional enhancement would be for DHCP clients to implement support
 for the "Client FQDN" option (Option 81).
 Since address changes are usually communicated to other sites via the
 DNS, the latter's security is essential for secure renumbering.  The
 Internet security community believes that the current DNS Security
 (DNSsec) and Secure Dynamic DNS Update specifications are
 sufficiently secure and has been encouraging DNSsec deployment
 ([RFC3007] [RFC4033] [RFC4034] [RFC4035]).
 As of this writing, there appears to be significantly more momentum
 towards rapid deployment of DNS Security standards in the global
 public Internet than previously.  Several country-code Top-Level
 Domains (ccTLDs) have already deployed signed TLD root zones (e.g.,
 Sweden's .SE).  Several other TLDs are working to deploy signed TLD
 root zones by published near-term deadlines (e.g., .GOV, .MIL).  In
 fact, it is reported that .GOV has been signed operationally since
 early February 2009.  It appears likely that the DNS-wide root zone
 will be signed in the very near future.  See, for example,
 <http://www.dnssec-deployment.org/> and
 <http://www.ntia.doc.gov/DNS/DNSSEC.html>.

2.6. Dynamic Service Discovery

 The need for hosts to contain pre-configured addresses for servers
 can be reduced by deploying the Service Location Protocol (SLP).  For
 some common services, such as network printing, SLP can therefore be
 an important tool for facilitating site renumbering.  See [RFC2608],
 [RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832].
 Multicast DNS (mDNS) and DNS Service Discovery are already widely
 deployed in BSD, Linux, Mac OS X, UNIX, and Windows systems, and are
 also widely used for both link-local name resolution and for DNS-
 based dynamic service discovery [MDNS] [DNSSD].  In many
 environments, the combination of mDNS and DNS Service Discovery
 (e.g., using SRV records [RFC3958]) can be important tools for
 reducing dependency on configured addresses.

3. Existing Router-Related Mechanisms

3.1. Router Renumbering

 Although DHCP was originally conceived for host configuration, it can
 also be used for some aspects of router configuration.  The DHCPv6
 Prefix Delegation options [RFC3633] are intended for this.  For

Carpenter, et al. Informational [Page 9] RFC 5887 Renumbering Still Needs Work May 2010

 example, DHCPv6 can be used by an ISP to delegate or withdraw a
 prefix for a customer's router, and this can be cascaded throughout a
 site to achieve router renumbering.
 An ICMPv6 extension to allow router renumbering for IPv6 is specified
 in [RFC2894], but there appears to be little experience with it.  It
 is not mentioned as a useful mechanism by [RFC4192].
 [RFC4191] extends IPv6 router advertisements to convey default router
 preferences and more-specific routes from routers to hosts.  This
 could be used as an additional tool to convey information during
 renumbering, but does not appear to be used in practice.
 [CPE] requires that a customer premises router use DHCPv6 to obtain
 an address prefix from its upstream ISP and use IPv6 RA messages to
 establish a default IPv6 route (when IPv6 is in use).

4. Existing Multi-Addressing Mechanism for IPv6

 IPv6 was designed to support multiple addresses per interface and
 multiple prefixes per subnet.  As described in [RFC4192], this allows
 for a phased approach to renumbering (adding the new prefix and
 addresses before removing the old ones).
 As an additional result of the multi-addressing mechanism, a site
 might choose to use Unique Local Addressing (ULA) [RFC4193] for all
 on-site communication, or at least for all communication with on-site
 servers, while using globally routeable IPv6 addresses for all off-
 site communications.  It would also be possible to use ULAs for all
 on-site network management purposes, by assigning ULAs to all
 devices.  This would make these on-site activities immune to
 renumbering of the prefix(es) used for off-site communication.
 Finally, ULAs can be safely shared with peer sites with which there
 is a VPN connection, which cannot be done with ambiguous IPv4
 addresses [RFC1918]; such VPNs would not be affected by renumbering.
 The IPv6 model also includes "privacy" addresses that are constructed
 with pseudo-random interface identifiers to conceal actual MAC
 addresses [RFC4941].  This means that IPv6 stacks and client
 applications already need to be agile enough to handle frequent IP
 address changes (e.g., in the privacy address), since in a privacy-
 sensitive environment the address lifetime likely will be rather
 short.

Carpenter, et al. Informational [Page 10] RFC 5887 Renumbering Still Needs Work May 2010

5. Operational Issues with Renumbering Today

 For IPv6, a useful description of practical aspects was drafted in
 [THINK], as a complement to [RFC4192].  As indicated there, a primary
 requirement is to minimise the disruption caused by renumbering.
 This applies at two levels: disruption to site operations in general
 and disruption to individual application sessions in progress at the
 moment of renumbering.  In the IPv6 case, the intrinsic ability to
 overlap use of the old and new prefixes greatly mitigates disruption
 to ongoing sessions, as explained in [RFC4192].  This approach is in
 practice excluded for IPv4, largely because IPv4 lacks a Stateless
 Address Autoconfiguration (SLAAC) mechanism.

5.1. Host-Related Issues

5.1.1. Network-Layer Issues

 For IPv4, the vast majority of client systems (PCs, workstations, and
 handheld computers) today use DHCP to obtain their addresses and
 other network-layer parameters.  DHCP provides for lifetimes after
 which the address lease expires.  So it should be possible to devise
 an operational procedure in which lease expiry coincides with the
 moment of renumbering (within some margin of error).  In the simplest
 case, the network administrator just lowers all DHCP address lease
 lifetimes to a very short value (e.g., a few minutes).  It does this
 long enough before a site-wide change that each node will
 automatically pick up its new IP address within a few minutes of the
 renumbering event.  In this case, it would be the DHCP server itself
 that automatically accomplishes client renumbering, although this
 would cause a peak of DHCP traffic and therefore would not be
 instantaneous.  DHCPv6 could accomplish a similar result.
 The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203].
 This is specifically unicast-only; a DHCP client must discard a
 multicast FORCERENEW.  This could nevertheless be used to trigger the
 renumbering process, with the DHCP server cycling through all its
 clients issuing a FORCERENEW to each one.  DHCPv6 has a similar
 feature, i.e., a unicast RECONFIGURE message, that can be sent to
 each host to inform it to check its DHCPv6 server for an update.
 These two features do not appear to be widely used for bulk
 renumbering purposes.
 Procedures for using a DHCP approach to site renumbering will be very
 different depending on whether the site uses strong or weak asset
 management.  With strong asset management, and careful operational
 planning, the subnet addresses and masks will be updated in the
 database, and a script will be run to regenerate the DHCP MAC-to-IP
 address tables and the DNS zone file.  DHCP and DNS timers will be

Carpenter, et al. Informational [Page 11] RFC 5887 Renumbering Still Needs Work May 2010

 set temporarily to small values.  The DHCP and DNS servers will be
 fed the new files, and as soon as the previous DHCP leases and DNS
 TTLs expire, everything will follow automatically, as far as the host
 IP layer is concerned.  In contrast, with weak asset management, and
 a casual operational approach, the DHCP table will be reconfigured by
 hand, the DNS zone file will be edited by hand, and when these
 configurations are installed, there will be a period of confusion
 until the old leases and TTLs expire.  The DHCP FORCERENEW or
 RECONFIGURE messages could shorten this confusion to some extent.
 DHCP, particularly for IPv4, has acquired a very large number of
 additional capabilities, with approximately 170 options defined at
 the time of this writing.  Although most of these do not carry IP
 address information, some do (for example, options 68 through 76 all
 carry various IP addresses).  Thus, renumbering mechanisms involving
 DHCP have to take into account more than the basic DHCP job of
 leasing an address to each host.
 SLAAC is much less overloaded with options than DHCP; in fact, its
 only extraneous capability is the ability to convey a DNS server
 address.  Using SLAAC to force all hosts on a site to renumber is
 therefore less complex than DHCP, and the difference between strong
 and weak asset management is less marked.  The principle of
 synchronising the SLAAC and DNS updates, and of reducing the SLAAC
 lease time and DNS TTL, does not change.
 We should note a currently unresolved ambiguity in the interaction
 between DHCPv6 and SLAAC from the host's point of view.  RA messages
 include a 'Managed Configuration' flag known as the M bit, which is
 supposed to indicate that DHCPv6 is in use.  However, it is
 unspecified whether hosts must interpret this flag rigidly (i.e., may
 or must only start DHCPv6 if it is set, or if no RAs are received) or
 whether hosts are allowed or are recommended to start DHCPv6 by
 default.  An added complexity is that DHCPv6 has a 'stateless' mode
 [RFC3736] in which SLAAC is used to obtain an address, but DHCPv6 is
 used to obtain other parameters.  Another flag in RA messages, the
 'Other configuration' or O bit, indicates this.
 Until this ambiguous behaviour is clearly resolved by the IETF,
 operational problems are to be expected, since different host
 operating systems have taken different approaches.  This makes it
 difficult for a site network manager to configure systems in such a
 way that all hosts boot in a consistent way.  Hosts will start SLAAC,
 if so directed by appropriately configured RA messages.  However, if
 one operating system also starts a DHCPv6 client by default, and
 another one starts it only when it receives the M bit, systematic
 address management is impeded.

Carpenter, et al. Informational [Page 12] RFC 5887 Renumbering Still Needs Work May 2010

 Also, it should be noted that on an isolated LAN, neither RA nor
 DHCPv6 responses will be received, and the host will remain with only
 its self-assigned link-local address.  One could also have a
 situation where a multihomed network uses SLAAC for one address
 prefix and DHCPv6 for another, which would clearly create a risk of
 inconsistent host behaviour and operational confusion.
 Neither the SLAAC approach nor DHCP without pre-registered MAC
 addresses will work reliably in all cases of systems that are
 assigned fixed IP addresses for practical reasons.  Of course, even
 systems with static addressing can be configured to use DHCP to
 obtain their IP address(es).  Such use of "Static DHCP" usually will
 ease site renumbering when it does become necessary.  However, in
 other cases, manual or script-driven procedures, likely to be site-
 specific and definitely prone to human error, are needed.  If a site
 has even one host with a fixed, manually configured address,
 completely automatic host renumbering is very likely to be
 impossible.
 The above assumes the use of typical off-the-shelf hardware and
 software.  There are other environments, often referred to as
 embedded systems, where DHCP or SLAAC might not be used and even
 configuration scripts might not be an option; for example, fixed IP
 addresses might be stored in read-only memory, or even set up using
 Dual In-Line Package (DIP) switches.  Such systems create special
 problems that no general-purpose solution is likely to address.

5.1.2. Transport-Layer Issues

 TCP connections and UDP flows are rigidly bound to a given pair of IP
 addresses.  These are included in the checksum calculation, and there
 is no provision at present for the endpoint IP addresses to change.
 It is therefore fundamentally impossible for the flows to survive a
 renumbering event at either end.  From an operational viewpoint, this
 means that a site that plans to renumber itself is obliged either to
 follow the overlapped procedure described in [RFC4192] or to announce
 a site-wide outage for the renumbering process, during which all user
 sessions will fail.  In the case of IPv4, overlapping of the old and
 new addresses is unlikely to be an option, and in any case is not
 commonly supported by software.  Therefore, absent enhancements to
 TCP and UDP to enable dynamic endpoint address changes (for example,
 [HANDLEY]), interruptions to TCP and UDP sessions seem inevitable if
 renumbering occurs at either session endpoint.  The same appears to
 be true of Datagram Congestion Control Protocol (DCCP) [RFC4340].

Carpenter, et al. Informational [Page 13] RFC 5887 Renumbering Still Needs Work May 2010

 In contrast, Stream Control Transmission Protocol (SCTP) already
 supports dynamic multihoming of session endpoints, so SCTP sessions
 ought not be adversely impacted by renumbering the SCTP session
 endpoints [RFC4960] [RFC5061].

5.1.3. DNS Issues

 The main issue is whether the site in question has a systematic
 procedure for updating its DNS configuration.  If it does, updating
 the DNS for a renumbering event is essentially a clerical issue that
 must be coordinated as part of a complete plan, including both
 forward and reverse mapping.  As mentioned in [RFC4192], the DNS TTL
 will be manipulated to ensure that stale addresses are not cached.
 However, if the site uses a weak asset management model in which DNS
 updates are made manually on demand, there will be a substantial
 period of confusion and errors will be made.
 There are anecdotal reports that many small user sites do not even
 maintain their own DNS configuration, despite running their own web
 and email servers.  They point to their ISP's resolver, request the
 ISP to install DNS entries for their servers, but operate internally
 mainly by IP address.  Thus, renumbering for such sites will require
 administrative coordination between the site and its ISP(s), unless
 the DNS servers in use have Secure Dynamic DNS Update enabled.  Some
 commercial DNS service firms include Secure Dynamic DNS Update as
 part of their DNS service offering.
 It should be noted that DNS entries commonly have matching Reverse
 DNS entries.  When a site renumbers, these reverse entries will also
 need to be updated.  Depending on a site's operational arrangements
 for DNS support, it might or might not be possible to combine forward
 and reverse DNS updates in a single procedure.

5.1.4. Application-Layer Issues

 Ideally, we would carry out a renumbering analysis for each
 application protocol.  To some extent, this has been done, in
 [RFC3795].  This found that 34 out of 257 Standards-Track or
 Experimental application-layer RFCs had explicit address
 dependencies.  Although this study was made in the context of IPv4 to
 IPv6 transition, it is clear that all these protocols might be
 sensitive to renumbering.  However, the situation is worse, in that
 there is no way to discover by analyzing specifications whether an
 actual implementation is sensitive to renumbering.  Indeed, such
 analysis might be quite impossible in the case of proprietary
 applications.

Carpenter, et al. Informational [Page 14] RFC 5887 Renumbering Still Needs Work May 2010

 The sensitivity depends on whether the implementation stores IP
 addresses in such a way that it might refer back to them later,
 without allowing for the fact that they might no longer be valid.  In
 general, we can assert that 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.  This could be done, for
 example, by knowing and respecting the relevant DNS TTL, or by
 resolving relevant Fully-Qualified Domain Names (FQDNs) again.  A
 common experience is that even when FQDNs are stored in configuration
 files, they are resolved only once, when the application starts, and
 they are cached indefinitely thereafter.  This is insufficient.  Of
 course, this does not apply to all application software; for example,
 several well-known web browsers have short default cache lifetimes.
 There are even more egregious breaches of this principle, for
 example, software license systems that depend on the licensed host
 computer having a particular IP address.  Other examples are the use
 of literal IP addresses in URLs, HTTP cookies, or application proxy
 configurations.  (Also see Appendix A.)
 In contrast, there are also many application suites that actively
 deal with connectivity failures by retrying with alternative
 addresses or by repeating DNS lookups.  This places a considerable
 burden of complexity on application developers.
 It should be noted that applications are in effect encouraged to be
 aware of and to store IP addresses by the very nature of the socket
 API calls gethostbyname() and getaddrinfo().  It is highly
 unfortunate that many applications use APIs that require the
 application to see and use lower-layer objects, such as network-layer
 addresses.  However, the BSD Sockets API was designed and deployed
 before the Domain Name System (DNS) was created, so there were few
 good options at the time.  This issue is made worse by the fact that
 these functions do not return an address lifetime, so that
 applications have no way to know when an address is no longer valid.
 The extension of the same model to cover IPv6 has complicated this
 problem somewhat.  An application using the socket API is obliged to
 contain explicit logic if it wishes to benefit from the availability
 of multiple addresses for a given remote host.  If a programming
 model were adopted in which only FQDNs were exposed to applications,
 and addresses were cached with appropriate lifetimes within the API,
 most of these problems would disappear.  It should be noted that at
 least the first part of this is already available for some
 programming environments.  A common example is Java, where only FQDNs
 need to be handled by application code in normal circumstances, and
 no additional application logic is needed to deal with multiple
 addresses, which are handled by the run-time system.  This is highly
 beneficial for programmers who are not networking experts, and

Carpenter, et al. Informational [Page 15] RFC 5887 Renumbering Still Needs Work May 2010

 insulates applications software from many aspects of renumbering.  It
 would be helpful to have similarly abstract, DNS-oriented, Networking
 APIs openly specified and widely available for C and C++.
 Some web browsers intentionally violate the DNS TTL with a technique
 called "DNS Pinning."  DNS Pinning limits acceptance of server IP
 address changes, due to a JavaScript issue where repeated address
 changes can be used to induce a browser to scan the inside of a
 firewalled network and report the results to an outside attacker.
 Pinning can persist as long as the browser is running, in extreme
 cases perhaps months at a time.  Thus, we can see that security
 considerations 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, to ensure that they are listening on a port
 and socket bound to the new address.  In an IPv6 multi-addressed
 host, server applications need to be able to listen on more than one
 address simultaneously, in order to cover an overlap during
 renumbering.  Not all server applications are written to do this, and
 a name-based API as just mentioned would have to provide for this
 case invisibly to the server code.
 As noted in Section 2.6, the Service Location Protocol (SLP), and
 multicast DNS with SRV records for service discovery, have been
 available for some years.  For example, many printers deployed in
 recent years automatically advertise themselves to potential clients
 via SLP.  Many modern client operating systems automatically
 participate in SLP without requiring users to enable it.  These tools
 appear not to be widely known, although they can be used to reduce
 the number of places that IP addresses need to be configured.

5.2. Router-Related Issues

 [RFC2072] gives a detailed review of the operational realities in
 1997.  A number of the issues discussed in that document were the
 result of the relatively recent adoption of classless addressing;
 those issues can be assumed to have vanished by now.  Also, DHCP was
 a relative newcomer at that time, and can now be assumed to be
 generally available.  Above all, the document underlines that
 systematic planning and administrative preparation are needed, and
 that all forms of configuration file and script must be reviewed and
 updated.  Clearly this includes filtering and routing rules (e.g.,
 when peering with BGP, but also with intradomain routing as well).
 Two particular issues mentioned in [RFC2072] are:
 o  Some routers cache IP addresses in some situations.  So routers
    might need to be restarted as a result of site renumbering.

Carpenter, et al. Informational [Page 16] RFC 5887 Renumbering Still Needs Work May 2010

 o  Addresses might be used by configured tunnels, including VPN
    tunnels, although at least the Internet Key Exchange (IKE)
    supports the use of Fully-Qualified Domain Names instead.
 On the latter point, the capability to use FQDNs as endpoint names in
 IPsec VPNs is not new and is standard (see [RFC2407], Section 4.6.2.3
 and [RFC4306], Section 3.5).  This capability is present in most
 IPsec VPN implementations.  There does seem to be an "educational" or
 "awareness" issue that many system/network administrators do not
 realise that it is there and works well as a way to avoid manual
 modification during renumbering.  (Of course, even in this case, a
 VPN may need to be reconnected after a renumbering event, but most
 products appear to handle this automatically.)
 In IPv6, 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.

5.3. Other Issues

5.3.1. NAT State Issues

 When a renumbering event takes place, entries in the state table of
 any Network Address Translator that happen to contain the affected
 addresses will become invalid and will eventually time out.  Since
 TCP and UDP sessions are unlikely to survive renumbering anyway, the
 hosts involved will not be additionally affected.  The situation is
 more complex for multihomed SCTP [SCTPNAT], depending on whether a
 single or multiple NATs are involved.
 A NAT itself might be renumbered and might need a configuration
 change during a renumbering event.  One of the authors has a NAT-
 enabled home gateway that obtains its exterior address from the
 residential Internet service provider by acting as a DHCP client.
 That deployment has not suffered operational problems when the ISP
 uses DHCP to renumber the gateway's exterior IP address.  A critical
 part of that success has been configuring IKE on the home gateway to
 use a "mailbox name" for the user's identity type (rather than using
 the exterior IP address of the home gateway) when creating or
 managing the IP Security Associations.

Carpenter, et al. Informational [Page 17] RFC 5887 Renumbering Still Needs Work May 2010

5.3.2. Mobility Issues

 A mobile node using Mobile IP that is not currently in its home
 network will be adversely affected if either its current care-of
 address or its home address is renumbered.  For IPv6, if the care-of
 address changes, this will be exactly like moving from one foreign
 network to another, and Mobile IP will re-bind with its home agent in
 the normal way.  If its home address changes unexpectedly, it 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 [RFC3775].  The situation is more
 tricky if the mobile node is detached at the time of the renumbering
 event, since 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.
 In contrast to Mobile IPv6, Mobile IPv4 does not support prefix
 solicitation and prefix advertisement messages, limiting its
 renumbering capability to well-scheduled renumbering events when the
 mobile node is connected to its home agent and managed by the home
 network administration.  Unexpected home network renumbering events
 when the mobile node is away from its home network and not connected
 to the home agent are supported only if a relevant Authentication,
 Authorisation, and Accounting (AAA) system is able to allocate
 dynamically a home address and home agent for the mobile node.

5.3.3. Multicast Issues

 As discussed in [THINK], IPv6 multicast can be used to help rather
 than hinder renumbering, for example, by using multicast as a
 discovery protocol (as in IPv6 Neighbour Discovery).  On the other
 hand, the embedding of IPv6 unicast addresses into multicast
 addresses specified in [RFC3306] and the embedded-RP (Rendezvous
 Point) in [RFC3956] will cause issues when renumbering.
 For both IPv4 and IPv6, changing the unicast source address of a
 multicast sender might also be an issue for receivers, especially for
 Source-Specific Multicast (SSM).  Applications need to learn the new
 source addresses and new multicast trees need to be built
 For IPv4 or IPv6 with Any-Source Multicast (ASM), renumbering can be
 easy.  If sources are renumbered, from the routing perspective,
 things behave just as if there are new sources within the same
 multicast group.  There may be application issues though.  Changing
 the RP address is easy when using Bootstrap Router (BSR) [RFC5059]
 for dynamic RP discovery.  BSR is widely used, but it is also common
 to use static config of RP addresses on routers.  In that case,
 router configurations must be updated too.

Carpenter, et al. Informational [Page 18] RFC 5887 Renumbering Still Needs Work May 2010

 If any multicast ACLs are configured, they raise the same issue as
 unicast ACLs mentioned elsewhere.

5.3.4. Management Issues

 Today, static IP addresses are routinely embedded in numerous
 configuration files and network management databases, including MIB
 modules.  Ideally, all of these would be generated from a single
 central asset management database for a given site, but this is far
 from being universal practice.  It should be noted that for IPv6,
 where multiple routing prefixes per interface and multiple addresses
 per interface are standard practice, the database and the
 configuration files will need to allow for this (rather than for a
 single address per host, as is normal practice for IPv4).
 Furthermore, because of routing policies and VPNs, a site or network
 might well embed addresses from other sites or networks in its own
 configuration data.  (It is preferable to embed FQDNs instead, of
 course, whenever possible.)  Thus, renumbering will cause a ripple
 effect of updates for a site and for its neighbours.  To the extent
 that these updates are manual, they will be costly and prone to
 error.  Synchronising updates between independent sites can cause
 unpredictable delays.  Note that Section 4 suggests that IPv6 ULAs
 can mitigate this problem, but of course only for VPNs and routes
 that are suitable for ULAs rather than globally routeable addresses.
 The majority of external addresses to be configured will not be ULAs.
 See Appendix A for an extended list of possible static or embedded
 addresses.
 Some address configuration data are relatively easy to find (for
 example, site firewall rules, ACLs in site border routers, and DNS).
 Others might be widely dispersed and much harder to find (for
 example, configurations for building routers, printer addresses
 configured by individual users, and personal firewall
 configurations).  Some of these will inevitably be found only after
 the renumbering event, when the users concerned encounter a problem.
 The overlapped model for IPv6 renumbering, with old and new addresses
 valid simultaneously, means that planned database and configuration
 file updates will proceed in two stages -- add the new information
 some time before the renumbering event, and remove the old
 information some time after.  All policy rules must be configured to
 behave correctly during this process (e.g., preferring the new
 address as soon as possible).  Similarly, monitoring tools must be
 set up to monitor both old and new during the overlap.

Carpenter, et al. Informational [Page 19] RFC 5887 Renumbering Still Needs Work May 2010

 However, it should be noted that the notion of simultaneously
 operating multiple prefixes for the same network, although natural
 for IPv6, is generally not supported by operational tools such as
 address management software.  It also increases the size of IGP
 routing tables in proportion to the number of prefixes in use.  For
 these reasons, and due to its unfamiliarity to operational staff, the
 use of multiple prefixes remains rare.  Accordingly, the use of ULAs
 to provide stable on-site addresses even if the off-site prefix
 changes is also rare.
 If both IPv4 and IPv6 are renumbered simultaneously in a dual-stack
 network, additional complications could result, especially with
 configured IP-in-IP tunnels.  This scenario should probably be
 avoided.
 Use of FQDNs rather than raw IP addresses wherever possible in
 configuration files and databases will reduce/mitigate the potential
 issues arising from such configuration files or management databases
 when renumbering is required or otherwise occurs.  This is advocated
 in [RFC1958] (point 4.1).  Just as we noted in Section 5.1.4 for
 applications, this is insufficient in itself; some devices such as
 routers are known to only resolve FQDNs once, at start-up, and to
 continue using the resulting addresses indefinitely.  This may
 require routers to be rebooted, when they should instead be resolving
 the FQDN again after a given timeout.
 By definition, there is at least one place (i.e., the DNS zone file
 or the database from which it is derived) where address information
 is nevertheless inevitable.
 It is also possible that some operators may choose to configure
 addresses rather than names, precisely to avoid a possible circular
 dependency and the resulting failure modes.  This is arguably even
 advocated in [RFC1958] (point 3.11).
 It should be noted that the management and administration issues
 (i.e., tracking down, recording, and updating all instances where
 addresses are stored rather than looked up dynamically) form the
 dominant concern of managers considering the renumbering problem.
 This has led many sites to continue the pre-CIDR (Classless Inter-
 Domain Routing) approach of using a provider-independent (PI) prefix.
 Some sites, including very large corporate networks, combine PI
 addressing with NAT.  Others have adopted private addressing and NAT
 as a matter of choice rather than obligation.  This range of
 techniques allows for addressing plans that are independent of the
 ISP(s) in use, and allows a straightforward approach to multihoming.
 The direct cost of renumbering is perceived to exceed the indirect
 costs of these alternatives.  Additionally, there is a risk element

Carpenter, et al. Informational [Page 20] RFC 5887 Renumbering Still Needs Work May 2010

 stemming from the complex dependencies of renumbering: it is hard to
 be fully certain that the renumbering will not cause unforeseen
 service disruptions, leading to unknown additional costs.
 A relevant example in a corporate context is VPN configuration data
 held in every employee laptop, for use while on travel and connecting
 securely from remote locations.  Typically, such VPNs are statically
 configured using numeric IP addresses for endpoints and even with
 prefix lists for host routing tables.  Use of VPN configurations with
 FQDNs to name fixed endpoints, such as corporate VPN gateways, and
 with non-address identity types would enable existing IP Security
 with IKE to avoid address renumbering issues and work well for highly
 mobile users.  This is all possible today with standard IPsec and
 standard IKE.  It just requires VPN software to be configured with
 names instead of addresses, and thoughtful network administration.
 It should be noted that site and network operations managers are
 often very conservative, and reluctant to change operational
 procedures that are working reasonably well and are perceived as
 reasonably secure.  They quite logically argue that any change brings
 with it an intrinsic risk of perturbation and insecurity.  Thus, even
 if procedural changes are recommended that will ultimately reduce the
 risks and difficulties of renumbering (such as using FQDNs protected
 by DNSsec where addresses are used today), these changes might be
 resisted.

5.3.5. Security Issues

 For IPv6, addresses are intended to be protected against forgery
 during neighbour discovery by SEcure Neighbour Discovery (SEND)
 [RFC3971].  This appears to be a very useful precaution during
 dynamic renumbering, to prevent hijacking of the process by an
 attacker.  Any automatic renumbering scheme has a potential exposure
 to such hijacking at the moment that a new address is announced.
 However, at present it is unclear whether or when SEND might be
 widely implemented or widely deployed.
 Firewall rules will certainly need to be updated, and any other cases
 where addresses or address prefixes are embedded in security
 components (access control lists, AAA systems, intrusion detection
 systems, etc.).  If this is not done in advance, legitimate access to
 resources might be blocked after the renumbering event.  If the old
 rules are not removed promptly, illegitimate access might be possible
 after the renumbering event.  Thus, the security updates will need to
 be made in two stages (immediately before and immediately after the
 event).

Carpenter, et al. Informational [Page 21] RFC 5887 Renumbering Still Needs Work May 2010

 There will be operational and security issues if an X.509v3 Public
 Key Infrastructure (PKI) Certificate includes a subjectAltName
 extension that contains an iPAddress [RFC5280], and if the
 corresponding node then undergoes an IP address change without a
 concurrent update to the node's PKI Certificate.  For these reasons,
 use of the dNSName rather than the iPAddress is recommended for the
 subjectAltName extension.  Any other use of IP addresses in
 cryptographic material is likely to be similarly troublesome.
 If a site is, for some reason, listed by IP address in a white list
 (such as a spam white list), this will need to be updated.
 Conversely, a site that is listed in a black list can escape that
 list by renumbering itself.
 The use of IP addresses instead of FQDNs in configurations is
 sometimes driven by a perceived security need.  Since the name
 resolution process has historically lacked authentication,
 administrators prefer to use raw IP addresses when the application is
 security sensitive (firewalls and VPN are two typical examples).  It
 might be possible to solve this issue in the next few years with
 DNSsec (see Section 2.5), now that there is strong DNS Security
 deployment momentum.

6. Proposed Mechanisms

6.1. SHIM6

 SHIM6, proposed as a host-based multihoming mechanism for IPv6, has
 the property of dynamically switching the addresses used for
 forwarding the actual packet stream while presenting a constant
 address as the upper-layer identifier for the transport layer
 [RFC5533].  At least in principle, this property could be used during
 renumbering to alleviate the problem described in Section 5.1.2.
 SHIM6 is an example of a class of solutions with this or a similar
 property; others are Host Identity Protocol (HIP), IKEv2 Mobility and
 Multihoming (MOBIKE), Mobile IPv6, SCTP, and proposals for multi-path
 TCP.

6.2. MANET Proposals

 The IETF working groups dealing with mobile ad hoc networks have been
 working on a number of mechanisms for mobile routers to discover
 available border routers dynamically, and for those mobile routers to
 be able to communicate that information to hosts connected to those
 mobile routers.

Carpenter, et al. Informational [Page 22] RFC 5887 Renumbering Still Needs Work May 2010

 Recently, some MANET work has appeared on a "Border Router Discovery
 Protocol (BRDP)" that might be useful work towards a more dynamic
 mechanism for site interior router renumbering [BRDP].
 At present, the IETF AUTOCONF WG
 (http://www.ietf.org/html.charters/autoconf-charter.html) is working
 on address autoconfiguration mechanisms for MANET networks that also
 seem useful for ordinary non-mobile non-MANET networks [AUTOC].  This
 work is extensively surveyed in [AUTOC2] and [AUTOC3].  Other work in
 the same area, e.g., [RFC5558], might also be relevant.
 MANETs are, of course, unusual in that they must be able to
 reconfigure themselves at all times and without notice.  Hence, the
 type of hidden static configurations discussed above in Section 5.3.4
 are simply intolerable in MANETs.  Thus, it is possible that when a
 consensus is reached on autoconfiguration for MANETs, the selected
 solution(s) might not be suitable for the more general renumbering
 problem.  However, it is certainly worthwhile to explore applying
 techniques that work for MANETs to conventional networks also.

6.3. Other IETF Work

 A DHCPv6 extension has been proposed that could convey alternative
 routes, in addition to the default router address, to IPv6 hosts
 [DHRTOPT].  Other DHCP options are also on the table that may offer
 information about address prefixes and routing to DHCP or DHCPv6
 clients, such as [DHSUBNET] and [DHMIFRT].  It is conceivable that
 these might be extended as a way of informing hosts dynamically of
 prefix changes.
 In the area of management tools, Network Configuration (NETCONF)
 Protocol [RFC4741] is suitable for the configuration of any network
 element or server, so could in principle be used to support secure
 remote address renumbering.
 The DNSOP WG has considered a Name Server Control Protocol (NSCP)
 based on NETCONF that provides means for consistent DNS management
 including potential host renumbering events [DNSCONT].

6.4. Other Proposals

 A proposal has been made to include an address lifetime as an
 embedded field in IPv6 addresses, with the idea that all prefixes
 would automatically expire after a certain period and become
 unrouteable [CROCKER].  While this might be viewed as provocative, it
 would force the issue by making renumbering compulsory.

Carpenter, et al. Informational [Page 23] RFC 5887 Renumbering Still Needs Work May 2010

7. Gaps

 This section seeks to identify technology gaps between what is
 available from existing open specifications and what appears to be
 needed for site renumbering to be tolerable.

7.1. Host-Related Gaps

 It would be beneficial to expose address lifetimes in the socket API,
 or any low-level networking API.  This would allow applications to
 avoid using stale addresses.
 The various current discussions of a name-based transport layer or a
 name-based network API also have potential to alleviate the
 application-layer issues noted in this document.  Application
 development would be enhanced by the addition of a more abstract
 network API that supports the C and C++ programming languages.  For
 example, it could use FQDNs and Service Names, rather than SockAddr,
 IP Address, protocol, and port number.  This would be equivalent to
 similar interfaces already extant for Java programmers.
 Moving to a FQDN-based transport layer might enhance the ability to
 migrate the IP addresses of endpoints for TCP/UDP without having to
 interrupt a session, or at least in a way that allows a session to
 restart gracefully.
 Having a single registry per host for all address-based configuration
 (/etc/hosts, anyone?), with secure access for site network
 management, might be helpful.  Ideally, this would be remotely
 configurable, for example, leveraging the IETF's current work on
 networked-device configuration protocols (NetConf).  While there are
 proprietary versions of this approach, sometimes based on Lightweight
 Directory Access Protocol (LDAP), a fully standardised approach seems
 desirable.
 Do we really need more than DHCP or SLAAC for regular hosts?  Do we
 need an IPv4 equivalent of SLAAC?  How can the use of DHCP FORCERENEW
 and DHCPv6 RECONFIGURE for bulk renumbering be deployed?  FORCERENEW
 in particular requires DHCP authentication [RFC3118] to be deployed.
 The IETF should resolve the 'IPv6 ND M/O flag debate' once and for
 all, with default, mandatory and optional behaviours of hosts being
 fully specified.
 The host behaviour for upstream link learning suggested in
 Section 2.3 should be documented.

Carpenter, et al. Informational [Page 24] RFC 5887 Renumbering Still Needs Work May 2010

 It would be helpful to have multi-path, survivable, extensions for
 both UDP and TCP (or institutionalise some aspects of SHIM6).

7.2. Router-Related Gaps

 A non-proprietary secure mechanism to allow all address-based
 configuration to be driven by a central repository for site
 configuration data.  NETCONF might be a good starting point.
 A MANET solution that's solid enough to apply to fully operational
 small to medium fixed sites for voluntary or involuntary renumbering.
 A MANET-style solution that can be applied convincingly to large or
 very large sites for voluntary renumbering.
 A useful short-term measure would be to ensure that [RFC2894] and
 [RFC3633] can be used in practice.

7.3. Operational Gaps

 Since address changes are usually communicated via the DNS, the
 latter's security is essential for secure renumbering.  Thus, we
 should continue existing efforts to deploy DNSsec globally, including
 not only signing the DNS root, DNS TLDs, and subsidiary DNS zones,
 but also widely deploying the already available DNSsec-capable DNS
 resolvers.
 Similarly, we should document and encourage widespread deployment of
 Secure Dynamic DNS Update both in DNS servers and also in both client
 and server operating systems.  This capability is already widely
 implemented and widely available, but it is not widely deployed at
 present.
 Deploy multi-prefix usage of IPv6, including Unique Local Addresses
 (ULAs) to provide stable internal addresses.  In particular, address
 management tools need to support the multi-prefix model and ULAs.
 Ensure that network monitoring systems will function during
 renumbering, in particular to confirm that renumbering has completed
 successfully or that some traffic is still using the old prefixes.
 Document and encourage systematic site databases and secure
 configuration protocols for network elements and servers (e.g.,
 NETCONF).  The database should store all the information about the
 network; scripts and tools should derive all configurations from the
 database.  An example of this approach to simplify renumbering is
 given at [LEROY].

Carpenter, et al. Informational [Page 25] RFC 5887 Renumbering Still Needs Work May 2010

 Document functional requirements for site renumbering tools or
 toolkits.
 Document operational procedures useful for site renumbering.
 In general, document renumbering instructions as part of every
 product manual.
 Recommend strongly that all IPv6 deployment plans, for all sizes of
 site or network, should include provision for future renumbering.
 Renumbering should be planned from day one when the first lines of
 the configuration of a network or network service are written.  Every
 IPv6 operator should expect to have to renumber the network one day
 and should plan for this event.

7.4. Other Gaps

 Define a secure mechanism for announcing changes of site prefix to
 other sites (for example, those that configure routers or VPNs to
 point to the site in question).
 For Mobile IP, define a better mechanism to handle change of home
 agent address while mobile is disconnected.

8. Security Considerations

 Known current issues are discussed in Section 5.3.5.  Security issues
 related to SLAAC are discussed in [RFC3756].  DHCP authentication is
 defined in [RFC3118].
 For future mechanisms to assist and simplify renumbering, care must
 be taken to ensure that prefix or address changes (especially changes
 coming from another site or via public sources such as the DNS) are
 adequately authenticated at all points.  Otherwise, misuse of
 renumbering mechanisms would become an attractive target for those
 wishing to divert traffic or to cause major disruption.  As noted in
 Section 5.1.4, this may result in defensive techniques such as "DNS
 pinning", which create difficulty when renumbering.
 Whatever authentication method(s) are adopted, key distribution will
 be an important aspect.  Most likely, public key cryptography will be
 needed to authenticate renumbering announcements passing from one
 site to another, since one cannot assume a preexisting trust
 relationship between such sites.

Carpenter, et al. Informational [Page 26] RFC 5887 Renumbering Still Needs Work May 2010

9. Acknowledgements

 Significant amounts of text have been adapted from [THINK], which
 reflects work carried out during the 6NET project funded by the
 Information Society Technologies Programme of the European
 Commission.  The authors of that document have agreed to their text
 being submitted under the IETF's current copyright provisions.
 Helpful material about work following on from 6NET was also provided
 by Olivier Festor of INRIA.
 Useful comments and contributions were made (in alphabetical order)
 by Jari Arkko, Fred Baker, Olivier Bonaventure, Teco Boot, Stephane
 Bortzmeyer, Dale Carder, Gert Doering, Ralph Droms, Pasi Eronen,
 Vijay Gurbani, William Herrin, Cullen Jennings, Eliot Lear, Darrel
 Lewis, Masataka Ohta, Dan Romascanu, Dave Thaler, Iljitsch van
 Beijnum, Stig Venaas, Nathan Ward, James Woodyatt, and others.

10. Informative References

 [AUTOC]       Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad
               hoc Network Architecture", Work in Progress,
               November 2007.
 [AUTOC2]      Bernardos, C., Calderon, M., and H. Moustafa, "Survey
               of IP address autoconfiguration mechanisms for MANETs",
               Work in Progress, November 2008.
 [AUTOC3]      Bernardos, C., Calderon, M., and H. Moustafa, "Ad-Hoc
               IP Autoconfiguration Solution Space Analysis", Work
               in Progress, November 2008.
 [BRDP]        Boot, T. and A. Holtzer, "Border Router Discovery
               Protocol (BRDP) based Address Autoconfiguration", Work
               in Progress, July 2009.
 [CPE]         Singh, H., Beebee, W., Donley, C., Stark, B., and O.
               Troan, Ed., "Basic Requirements for IPv6 Customer Edge
               Routers", Work in Progress, May 2010.
 [CROCKER]     Crocker, S., "Renumbering Considered Normal", 2006,
               <http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF
               /wednesday/Renumbering_Crocker.pdf>.
 [DHMIFRT]     Sun, T. and H. Deng, "Route Configuration by DHCPv6
               Option for Hosts with Multiple Interfaces", Work
               in Progress, March 2009.

Carpenter, et al. Informational [Page 27] RFC 5887 Renumbering Still Needs Work May 2010

 [DHRTOPT]     Dec, W. and R. Johnson, "DHCPv6 Route Option", Work
               in Progress, March 2010.
 [DHSUBNET]    Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
               "Subnet Allocation Option", Work in Progress, May 2010.
 [DNSBOOK]     Albitz, P. and C. Liu, "DNS and BIND", 5th Edition,
               O'Reilly, 2006.
 [DNSCONT]     Dickinson, J., Morris, S., and R. Arends, "Design for a
               Nameserver Control Protocol", Work in Protocol,
               October 2008.
 [DNSSD]       Cheshire, S. and M. Krochmal, "DNS-Based Service
               Discovery", Work in Progress, March 2010.
 [HANDLEY]     Handley, M., Wischik, D., and M. Bagnulo, "Multipath
               Transport, Resource Pooling, and implications for
               Routing", 2008,
               <http://www.ietf.org/proceedings/08jul/
               slides/RRG-2.pdf>.
 [IEEE.802-1X] Institute of Electrical and Electronics Engineers,
               "Port-Based Network Access Control:  IEEE Standard for
               Local and Metropolitan Area Networks 802.1X-2004",
               December 2009.
 [IEEE.802-1X-REV]
               Institute of Electrical and Electronics Engineers,
               "802.1X-REV - Revision of 802.1X-2004 - Port Based
               Network Access Control:  IEEE Standard for Local and
               Metropolitan Area Networks", 2009.
 [ILNP]        Atkinson, R., "ILNP Concept of Operations", Work
               in Progress, February 2010.
 [LEROY]       Leroy, D. and O. Bonaventure, "Preparing network
               configurations for IPv6 renumbering", International
               Journal of Network Management, 2009, <http://
               inl.info.ucl.ac.be/system/files/dleroy-nem-2009.pdf>.
 [LISP]        Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
               "Locator/ID Separation Protocol (LISP)", Work
               in Progress, April 2010.
 [MDNS]        Cheshire, S. and M. Krochmal, "Multicast DNS", Work
               in Progress, March 2010.

Carpenter, et al. Informational [Page 28] RFC 5887 Renumbering Still Needs Work May 2010

 [NAT66]       Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network
               Address Translation (NAT66)", Work in Progress,
               March 2009.
 [RFC1332]     McGregor, G., "The PPP Internet Protocol Control
               Protocol (IPCP)", RFC 1332, May 1992.
 [RFC1661]     Simpson, W., "The Point-to-Point Protocol (PPP)",
               STD 51, RFC 1661, July 1994.
 [RFC1900]     Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
               RFC 1900, February 1996.
 [RFC1916]     Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser,
               "Enterprise Renumbering: Experience and Information
               Solicitation", RFC 1916, February 1996.
 [RFC1918]     Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
               and E. Lear, "Address Allocation for Private
               Internets", BCP 5, RFC 1918, February 1996.
 [RFC1958]     Carpenter, B., "Architectural Principles of the
               Internet", RFC 1958, June 1996.
 [RFC2071]     Ferguson, P. and H. Berkowitz, "Network Renumbering
               Overview: Why would I want it and what is it anyway?",
               RFC 2071, January 1997.
 [RFC2072]     Berkowitz, H., "Router Renumbering Guide", RFC 2072,
               January 1997.
 [RFC2131]     Droms, R., "Dynamic Host Configuration Protocol",
               RFC 2131, March 1997.
 [RFC2407]     Piper, D., "The Internet IP Security Domain of
               Interpretation for ISAKMP", RFC 2407, November 1998.
 [RFC2608]     Guttman, E., Perkins, C., Veizades, J., and M. Day,
               "Service Location Protocol, Version 2", RFC 2608,
               June 1999.
 [RFC2610]     Perkins, C. and E. Guttman, "DHCP Options for Service
               Location Protocol", RFC 2610, June 1999.
 [RFC2874]     Crawford, M. and C. Huitema, "DNS Extensions to Support
               IPv6 Address Aggregation and Renumbering", RFC 2874,
               July 2000.

Carpenter, et al. Informational [Page 29] RFC 5887 Renumbering Still Needs Work May 2010

 [RFC2894]     Crawford, M., "Router Renumbering for IPv6", RFC 2894,
               August 2000.
 [RFC3007]     Wellington, B., "Secure Domain Name System (DNS)
               Dynamic Update", RFC 3007, November 2000.
 [RFC3059]     Guttman, E., "Attribute List Extension for the Service
               Location Protocol", RFC 3059, February 2001.
 [RFC3118]     Droms, R. and W. Arbaugh, "Authentication for DHCP
               Messages", RFC 3118, June 2001.
 [RFC3203]     T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP
               reconfigure extension", RFC 3203, December 2001.
 [RFC3224]     Guttman, E., "Vendor Extensions for Service Location
               Protocol, Version 2", RFC 3224, January 2002.
 [RFC3306]     Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
               Multicast Addresses", RFC 3306, August 2002.
 [RFC3315]     Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
               and M. Carney, "Dynamic Host Configuration Protocol for
               IPv6 (DHCPv6)", RFC 3315, July 2003.
 [RFC3421]     Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C.,
               and W. Jerome, "Select and Sort Extensions for the
               Service Location Protocol (SLP)", RFC 3421,
               November 2002.
 [RFC3633]     Troan, O. and R. Droms, "IPv6 Prefix Options for
               Dynamic Host Configuration Protocol (DHCP) version 6",
               RFC 3633, December 2003.
 [RFC3736]     Droms, R., "Stateless Dynamic Host Configuration
               Protocol (DHCP) Service for IPv6", RFC 3736,
               April 2004.
 [RFC3756]     Nikander, P., Kempf, J., and E. Nordmark, "IPv6
               Neighbor Discovery (ND) Trust Models and Threats",
               RFC 3756, May 2004.
 [RFC3775]     Johnson, D., Perkins, C., and J. Arkko, "Mobility
               Support in IPv6", RFC 3775, June 2004.
 [RFC3795]     Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in
               Currently Deployed IETF Application Area Standards
               Track and Experimental Documents", RFC 3795, June 2004.

Carpenter, et al. Informational [Page 30] RFC 5887 Renumbering Still Needs Work May 2010

 [RFC3832]     Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C.,
               and W. Jerome, "Remote Service Discovery in the Service
               Location Protocol (SLP) via DNS SRV", RFC 3832,
               July 2004.
 [RFC3956]     Savola, P. and B. Haberman, "Embedding the Rendezvous
               Point (RP) Address in an IPv6 Multicast Address",
               RFC 3956, November 2004.
 [RFC3958]     Daigle, L. and A. Newton, "Domain-Based Application
               Service Location Using SRV RRs and the Dynamic
               Delegation Discovery Service (DDDS)", RFC 3958,
               January 2005.
 [RFC3971]     Arkko, J., Kempf, J., Zill, B., and P. Nikander,
               "SEcure Neighbor Discovery (SEND)", RFC 3971,
               March 2005.
 [RFC4033]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "DNS Security Introduction and Requirements",
               RFC 4033, March 2005.
 [RFC4034]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "Resource Records for the DNS Security
               Extensions", RFC 4034, March 2005.
 [RFC4035]     Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "Protocol Modifications for the DNS Security
               Extensions", RFC 4035, March 2005.
 [RFC4076]     Chown, T., Venaas, S., and A. Vijayabhaskar,
               "Renumbering Requirements for Stateless Dynamic Host
               Configuration Protocol for IPv6 (DHCPv6)", RFC 4076,
               May 2005.
 [RFC4191]     Draves, R. and D. Thaler, "Default Router Preferences
               and More-Specific Routes", RFC 4191, November 2005.
 [RFC4192]     Baker, F., Lear, E., and R. Droms, "Procedures for
               Renumbering an IPv6 Network without a Flag Day",
               RFC 4192, September 2005.
 [RFC4193]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
               Addresses", RFC 4193, October 2005.
 [RFC4306]     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
               RFC 4306, December 2005.

Carpenter, et al. Informational [Page 31] RFC 5887 Renumbering Still Needs Work May 2010

 [RFC4340]     Kohler, E., Handley, M., and S. Floyd, "Datagram
               Congestion Control Protocol (DCCP)", RFC 4340,
               March 2006.
 [RFC4741]     Enns, R., "NETCONF Configuration Protocol", RFC 4741,
               December 2006.
 [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.
 [RFC4941]     Narten, T., Draves, R., and S. Krishnan, "Privacy
               Extensions for Stateless Address Autoconfiguration in
               IPv6", RFC 4941, September 2007.
 [RFC4960]     Stewart, R., "Stream Control Transmission Protocol",
               RFC 4960, September 2007.
 [RFC5059]     Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
               "Bootstrap Router (BSR) Mechanism for Protocol
               Independent Multicast (PIM)", RFC 5059, January 2008.
 [RFC5061]     Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
               Kozuka, "Stream Control Transmission Protocol (SCTP)
               Dynamic Address Reconfiguration", RFC 5061,
               September 2007.
 [RFC5072]     S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
               PPP", RFC 5072, September 2007.
 [RFC5280]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
               Housley, R., and W. Polk, "Internet X.509 Public Key
               Infrastructure Certificate and Certificate Revocation
               List (CRL) Profile", RFC 5280, May 2008.
 [RFC5533]     Nordmark, E. and M. Bagnulo, "Shim6: Level 3
               Multihoming Shim Protocol for IPv6", RFC 5533,
               June 2009.
 [RFC5558]     Templin, F., "Virtual Enterprise Traversal (VET)",
               RFC 5558, February 2010.
 [SCTPNAT]     Xie, Q., Stewart, R., Holdrege, M., and M. Tuexen,
               "SCTP NAT Traversal Considerations", Work in Progress,
               November 2007.

Carpenter, et al. Informational [Page 32] RFC 5887 Renumbering Still Needs Work May 2010

 [SIX-ONE]     Vogt, C., "Six/One: A Solution for Routing and
               Addressing in IPv6", Work in Progress, October 2009.
 [THINK]       Chown, T., "Things to think about when Renumbering an
               IPv6 network", Work in Progress, September 2006.

Carpenter, et al. Informational [Page 33] RFC 5887 Renumbering Still Needs Work May 2010

Appendix A. Embedded IP Addresses

 This Appendix lists common places where IP addresses might be
 embedded.  The list was adapted from [THINK].
    Provider based prefix(es)
    Names resolved to IP addresses in firewall at startup time
    IP addresses in remote firewalls allowing access to remote
    services
    IP-based authentication in remote systems allowing access to
    online bibliographic resources
    IP address of both tunnel end points for IPv6 in IPv4 tunnel
    Hard-coded IP subnet configuration information
    IP addresses for static route targets
    Blocked SMTP server IP list (spam sources)
    Web .htaccess and remote access controls
    Apache .Listen. directive on given IP address
    Configured multicast rendezvous point
    TCP wrapper files
    Samba configuration files
    DNS resolv.conf on Unix
    Any network traffic monitoring tool
    NIS/ypbind via the hosts file
    Some interface configurations
    Unix portmap security masks
    NIS security masks
    PIM-SM Rendezvous Point address on multicast routers

Carpenter, et al. Informational [Page 34] RFC 5887 Renumbering Still Needs Work May 2010

Authors' Addresses

 Brian Carpenter
 Department of Computer Science
 University of Auckland
 PB 92019
 Auckland  1142
 New Zealand
 EMail: brian.e.carpenter@gmail.com
 Randall Atkinson
 Extreme Networks
 PO Box 14129
 Suite 100, 3306 East NC Highway 54
 Research Triangle Park, NC  27709
 USA
 EMail: rja@extremenetworks.com
 Hannu Flinck
 Nokia Siemens Networks
 Linnoitustie 6
 Espoo  02600
 Finland
 EMail: hannu.flinck@nsn.com

Carpenter, et al. Informational [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5887.txt · Last modified: 2010/05/27 18:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki