doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc5887.txt b/doc/rfc/rfc5887.txt
new file mode 100644
index 0000000..6158615
--- /dev/null
+++ b/doc/rfc/rfc5887.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+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]
+