One document matched: draft-carpenter-renum-needs-work-05.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->

<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->

<?rfc toc="yes"?>            <!-- You want a table of contents -->
<?rfc symrefs="yes"?>        <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>       <!-- This sorts the references -->
<?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>

<!-- You need one entry like the following for each RFC referenced -->


<!ENTITY RFC1900 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1900'>
<!ENTITY RFC1918 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918'>
<!ENTITY RFC2629 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629'>
<!ENTITY RFC4192 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4192'>
<!ENTITY RFC4193 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193'>
<!ENTITY RFC1916 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1916'>
<!ENTITY RFC2071 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2071'>
<!ENTITY RFC2072 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2072'>
<!ENTITY RFC2874 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2874'>
<!ENTITY RFC2894 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2894'>
<!ENTITY RFC4076 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4076'>
<!ENTITY RFC2131 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131'>
<!ENTITY RFC3315 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315'>
<!ENTITY RFC4861 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861'>
<!ENTITY RFC4862 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862'>
<!ENTITY RFC3795 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3795'>
<!ENTITY RFC3007 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3007'>
<!ENTITY RFC1661 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1661'>
<!ENTITY RFC5072 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5072'>
<!ENTITY RFC3633 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633'>
<!ENTITY RFC4033 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033'>
<!ENTITY RFC4034 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034'>
<!ENTITY RFC4035 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035'>
<!ENTITY RFC4960 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960'>
<!ENTITY RFC5061 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5061'>
<!ENTITY RFC4340 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340'>
<!ENTITY RFC3736 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736'>
<!ENTITY RFC5280 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280'>
<!ENTITY RFC1332 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1332'>
<!ENTITY RFC3306 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3306'>
<!ENTITY RFC3956 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3956'>
<!ENTITY RFC3775 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775'>
<!ENTITY RFC3971 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971'>
<!ENTITY RFC4941 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941'>
<!ENTITY RFC3756 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3756'>
<!ENTITY RFC2608 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2608'>
<!ENTITY RFC2610 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2610'>
<!ENTITY RFC3059 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3059'>
<!ENTITY RFC3224 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3224'>
<!ENTITY RFC3421 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3421'>
<!ENTITY RFC3832 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3832'>
<!ENTITY RFC3958 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958'>
<!ENTITY RFC4741 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4741'>
<!ENTITY RFC3203 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3203'>
<!ENTITY RFC1958 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1958'>
<!ENTITY RFC2407 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2407'>
<!ENTITY RFC4306 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306'>
<!ENTITY RFC4191 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191'>
<!ENTITY RFC5059 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5059'>
<!ENTITY RFC5533 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5533'>
<!ENTITY RFC3118 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118'>





<!-- You need one entry like the following for each I-D referenced -->

<!ENTITY DRAFT-think SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chown-v6ops-renumber-thinkabout.xml">

<!ENTITY DRAFT-sctpnat SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xie-behave-sctp-nat-cons.xml">
<!ENTITY DRAFT-brdp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boot-autoconf-brdp.xml">
<!ENTITY DRAFT-vet SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-autoconf-dhcp.xml">
<!ENTITY DRAFT-autoc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-autoconf-manetarch.xml">
<!ENTITY DRAFT-autoc2 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernardos-manet-autoconf-survey.xml">
<!ENTITY DRAFT-autoc3 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernardos-autoconf-solution-space.xml">
<!ENTITY DRAFT-dnscont SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dickinson-dnsop-nameserver-control.xml">
<!ENTITY DRAFT-dhrtopt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dec-dhcpv6-route-option.xml">
<!ENTITY DRAFT-dhsubnet SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-subnet-alloc.xml">
<!ENTITY DRAFT-dhmifrt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.sun-mif-route-config-dhcp6.xml">
<!ENTITY DRAFT-nat66 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrw-behave-nat66.xml">
<!ENTITY DRAFT-lisp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp.xml">
<!ENTITY DRAFT-ilnp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rja-ilnp-intro.xml">
<!ENTITY DRAFT-61 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vogt-rrg-six-one.xml">
<!ENTITY DRAFT-cpe SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-cpe-router.xml">
<!ENTITY DRAFT-dnssd SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-dns-sd.xml">
<!ENTITY DRAFT-mdns SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-dnsext-multicastdns.xml">


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-carpenter-renum-needs-work-05" category="info">  


<front>
<title abbrev="Renumbering still needs work">Renumbering still needs work</title>


<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
    <organization abbrev="Univ. of Auckland"></organization>
    <address>
      <postal>
        <street>Department of Computer Science</street>
        <street>University of Auckland</street>
        <street>PB 92019</street>
        <city>Auckland</city>
        <region></region>
        <code>1142</code>
        <country>New Zealand</country>
      </postal>
      
      <email>brian.e.carpenter@gmail.com</email>
    </address>
</author>

<author initials="R." surname="Atkinson" fullname="Randall Atkinson">
    <organization abbrev="Extreme Networks"></organization>
    <address>
      <postal>
        <street>Extreme Networks</street>
        <street>PO Box 14129</street>
        <street>Suite 100, 3306 East NC Highway 54</street>
        <city>Research Triangle Park</city>
        <region></region>
        <code>NC 27709</code>
        <country>USA</country>
      </postal>
      
    <email>rja@extremenetworks.com</email>
    </address>
</author>

<author initials="H." surname="Flinck" fullname="Hannu Flinck">
    <organization abbrev="Nokia Siemens Networks"></organization>
    <address>
      <postal>
        <street>Nokia Siemens Networks</street>
        <street>Linnoitustie 6 </street>
        <city>Espoo</city>
        <region></region>
        <code>02600</code>
        <country>Finland</country>
      </postal>
      
      <email>hannu.flinck@nsn.com</email>
    </address>
</author>

   
  
<date day="19" month="January" year="2010" />

<area>Operations</area>
<workgroup>IETF Operations Area</workgroup>

 


<abstract>

<t>This document reviews the existing mechanisms for site
renumbering for both IPv4 and IPv6, and 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.</t>
    
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">

<t>In early 1996, the IAB published a short RFC entitled
"Renumbering Needs Work" <xref target="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" <xref target="RFC4192"/>.  A few
other RFCs have touched on router or host renumbering:
<xref target="RFC1916"/>, 
<xref target="RFC2071"/>,
<xref target="RFC2072"/>, 
<xref target="RFC2874"/>,
<xref target="RFC2894"/>, 
and <xref target="RFC4076"/>. </t>

<t>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
<xref target="RFC2131"/> and IPv6 <xref target="RFC3315"/>. 
IPv6 includes Stateless Address Autoconfiguration (SLAAC)
<xref target="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) <xref target="RFC1661"/> also allows for automated
address assignment for both versions of IP.</t>

<t>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 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.</t>

<t>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. </t>


<t>There are numerous reasons why such sites might need to renumber
in a planned fashion, including:</t>

 <list style="symbols">
 <t>Change of service provider, or addition of a new service provider, when provider-independent
 addressing is not an option.</t>
 <t>A service provider itself has to renumber.</t>
 <t>Change of site topology (i.e., subnet reorganization).</t>
 <t>Merger of two site networks into one, or split of one network into two or more parts.</t>
 <t>During IPv6 deployment, change of IPv6 access method (e.g., from tunneled to native).</t>
 </list>

<t>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 <xref target="RFC4941"/>.</t>



<t>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.</t>

<t>There is work in progress that, if successful, would eliminate
some of the motivations for renumbering. In particular, some types of solution
to the problem of scalable routing for multihomed sites would likely
eliminate both multihoming, and switching to another ISP, as reasons for
site renumbering. </t>

<t>Several proposed identifier/locator split schemes provide good examples, including at least 
Identifier Locator Network Protocol (ILNP) <xref target="I-D.rja-ilnp-intro"/>,
Locator/ID Separation Protocol (LISP) <xref target="I-D.ietf-lisp"/>,
and Six/One <xref target="I-D.vogt-rrg-six-one"/>
(in alphabetical order).
The recent discussion about IPv6 Network Address Translation (IPv6 NAT)
provides a separate example<xref target="I-D.mrw-behave-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
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. 
</t>

<t>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, 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.</t>

</section> <!-- intro -->

<section anchor="hosts" title="Existing Host-related Mechanisms">

<section title="DHCP">

<t>At high level, DHCP <xref target="RFC2131"/>
<xref target="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).</t>

<t>From an operational viewpoint, the interesting aspect is the
local policy.  Some sites require pre-registration of MAC
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, 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 US and UK universities require
MAC address registration of faculty, staff, and student devices
(including hand-held computers connected via wireless).</t>

<t>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, 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.</t>

<t>The IEEE 802.1X standard <xref target='IEEE.802-1X'/>, <xref target='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.</t>

<t>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.</t>

</section>

<section anchor="slaac" title="IPv6 Stateless Address Auto-configuration">

<t>SLAAC, although updated recently <xref target="RFC4862"/>, was
designed prior to DHCPv6, 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)
<xref target="RFC4861"/> which 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.</t>
   
<t>We will not describe here the IPv6 processes for Duplicate
Address Detection (DAD), Neighbor Discovery (ND), and Neighbor
Unreachability Discovery (NUD). Suffice it to say that they work, 
once the initial address assignment based on the RA has taken
place.</t>

<t>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 finite or
zero preferred lifetime 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.</t>
   
</section>

<section anchor="uplinks" title="IPv6 ND Router/Prefix advertisements">

<t>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 the host should use
DHCPv6 to configure or not.  If that flag indicates the host
should use DHCPv6, then the host is not supposed to
auto-configure itself as outlined in <xref target="slaac"/>.
However, there are some issues in this area, described in
<xref target="netiss"/>.</t>

<t>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.</t>

</section>


<section title="PPP">

<t>The Point-to-Point Protocol <xref target="RFC1661"/> includes
support for a Network Control Protocol (NCP) for both IPv4 and
IPv6.</t>

<t>For IPv4, the NCP is known as IPCP <xref target="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 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 abort. Effectively, the subscriber
device is renumbered each time it connects for a new
session. </t>


<t>For IPv6, the NCP is IP6CP <xref target="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.</t>

</section>

<section anchor="dnsconf" title="DNS configuration">

<t>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 <xref target="RFC3007"/>, in which a host informs its own
DNS server when it receives a new address.</t>

<t>There are widespread reports that the freely available BIND
DNS software (which is what most UNIX hosts use), Microsoft
Windows (XP and later), and MacOS 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 (<xref target="dnsbook"/> p. 228 and p. 506). </t>

<t>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 (<xref target="dnsbook"/> p. 506).  So in
some cases, sites might have deployed 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). </t>

<t>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 and Secure Dynamic DNS Update specifications are
sufficiently secure and has been encouraging DNSsec deployment,
<xref target="RFC3007"/>, <xref target="RFC4033"/>,
<xref target="RFC4034"/>, <xref target="RFC4035"/>. </t>

<t>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, <eref target="http://www.dnssec-deployment.org/"/> 
and <eref target="http://www.ntia.doc.gov/DNS/DNSSEC.html"/>.</t>

</section>

<section anchor="slp" title="Dynamic Service Discovery">

<t>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 <xref target="RFC2608"/>,
<xref target="RFC2610"/>, <xref target="RFC3059"/>,
<xref target="RFC3224"/>, <xref target="RFC3421"/> and
<xref target="RFC3832"/>.
</t>


<t>Multicast DNS (mDNS) and DNS Service Discovery are already widely 
deployed in BSD, Linux, MacOS X, UNIX, and Windows systems, and 
are also widely used for both link-local name resolution and for 
DNS-based dynamic service discovery 
<xref target="I-D.cheshire-dnsext-multicastdns"/>,
<xref target="I-D.cheshire-dnsext-dns-sd"/>.
In many environments, the combination of mDNS
and DNS Service Discovery (e.g. using SRV records <xref target="RFC3958"/>) can be 
important tools for reducing dependency on configured addresses. 
 </t>

</section>

</section> <!-- hosts -->

<section anchor="routers" title="Existing Router-related Mechanisms">

<section title="Router renumbering">

<t>Although DHCP was originally conceived for host configuration,
it can also be used for some aspects of router configuration. The
DHCPv6 Prefix Delegation options <xref target="RFC3633"/> are
intended for this. For 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. </t>

<t>An ICMPv6 extension to allow router renumbering for IPv6 is
specified in <xref target="RFC2894"/>, but there appears to be
little experience with it.  It is not mentioned as a useful
mechanism by <xref target="RFC4192"/>.  </t>

<t> <xref target="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. </t>

<t> <xref target="I-D.ietf-v6ops-ipv6-cpe-router"/> requires that a
customer premises router use DHCPv6 to obtain an address prefix from
its upstream ISP, as well as using IPv6 RA messages
to establish a default IPv6 route (when IPv6 is in use). </t>

</section>

</section> <!-- routers -->

<section anchor="ula" title="Existing Multi-addressing Mechanism for IPv6">


<t>IPv6 was designed to support multiple addresses per interface
and multiple prefixes per subnet. As described in
<xref target="RFC4192"/>, this allows for a phased approach to
renumbering (adding the new prefix and addresses before removing
the old ones).</t>

<t>As an additional result of the multi-addressing mechanism, 
a site might choose to use Unique Local Addressing (ULA)
<xref target="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 <xref target="RFC1918"/>; such VPNs
would not be affected by renumbering.
</t>  

<t>The IPv6 model also includes "privacy" addresses which are
constructed with pseudo-random interface identifiers to conceal
actual MAC addresses <xref target="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. </t>

</section>


<section anchor="opissues" title="Operational Issues with Renumbering Today">

<t>For IPv6, a useful description of practical aspects was
drafted in <xref target="I-D.chown-v6ops-renumber-thinkabout"/>,
as a complement to <xref target="RFC4192"/>. As indicated there,
a primary requirement is to minimize 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 usage of the old and new
prefixes greatly mitigates disruption to ongoing sessions, as
explained in <xref target="RFC4192"/>. This approach is in
practice excluded for IPv4, largely because IPv4 lacks a 
State-Less Address Auto-Configuration (SLAAC) mechanism.</t>

<section title="Host-related issues">
<section anchor="netiss" title="Network layer issues">

<t>For IPv4, the vast majority of client systems (PCs,
workstations, and hand-held 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) far 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. </t>

<t>The FORCERENEW extension is defined for DHCP for IPv4 <xref target='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. </t>

<t>Procedures for using a DHCP approach to site renumbering will
be very different depending 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 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.</t>

<t>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.</t>
   
<t>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.</t>

<t>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 <xref target='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.  </t>

<t>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. </t>

<t>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 behavior and operational confusion.</t>

<t>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. </t>  


<t>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
DIP switches.  Such systems create special problems that no
general-purpose solution is likely to address.</t>

</section>

<section anchor="tcpudp" title="Transport layer issues">

<t>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 <xref target="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, <xref target="handley"/>), interruptions to
TCP and UDP sessions seem inevitable if renumbering occurs at
either session endpoint. The same appears to be true of DCCP
<xref target="RFC4340"/>.</t>

<t>In contrast, SCTP already supports dynamic multi-homing of
session end-points, so SCTP sessions ought not be adversely
impacted by renumbering the SCTP session end-points
<xref target="RFC4960"/>, <xref target="RFC5061"/>.</t>

</section>   

<section title="DNS issues">

<t>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
<xref target="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.</t>

<t>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.</t>

<t>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. </t>

</section>

<section anchor="appiss" title="Application layer issues">

<t>Ideally, we would carry out a renumbering analysis for each
application protocol. To some extent, this has been done, in
<xref target="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
analysing specifications whether an actual implementation is
sensitive to renumbering.  Indeed, such analysis might be quite
impossible in the case of proprietary applications.</t>

<t>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 time-to-live, 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. </t>

<t>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 <xref target="Appendix1"/>.) </t>

<t>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. </t>

<t>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 insulates applications
software from many aspects of renumbering. It would be helfpul to have
similarly abstract, DNS oriented, Networking APIs openly specified and widely
available for C and C++. </t>



<t>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. </t>

<t>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. </t>

<t>As noted in <xref target="slp"/>,
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.</t>

</section>
</section>

<section title="Router-related issues">

<t> <xref target="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 is 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
<xref target="RFC2072"/> are:</t>

<list style="symbols">

<t>Some routers cache IP addresses in some situations. So routers
might need to be restarted as a result of site renumbering.</t>

<t>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.</t>

</list>
<t>On the latter point, the capability to use FQDNs as endpoint names in IPsec VPNs
is not new and is standard (see  <xref target="RFC2407"/> Section 4.6.2.3 and
<xref target="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.) </t>
   
<t>In IPv6, if a site wanted to be multi-homed 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. </t>
   
</section>

<section title="Other issues">
<section title="NAT state issues">

<t>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
<xref target="I-D.xie-behave-sctp-nat-cons"/>, depending whether
a single or multiple NATs are involved. </t>

<t>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.</t>
   
</section>

<section title="Mobility issues">

<t>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
<xref target="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. </t>

<t> By 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 AAA system is able to allocate dynamically a home
address and home agent for the mobile node. </t>

</section>

 <section title="Multicast issues">

<t>As discussed in
<xref target="I-D.chown-v6ops-renumber-thinkabout"/>, IPv6
multicast can be used to help rather than hinder renumbering, 
for example by using multicast as a discovery protocol (as in
IPv6 Neighbor Discovery).  On the other hand, the embedding of
IPv6 unicast addresses into multicast addresses specified in
<xref target="RFC3306"/> and the embedded-RP (Rendezvous Point)
in <xref target="RFC3956"/> will cause issues when renumbering. </t>

<t>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</t>

<t>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) <xref target="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. </t>

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

</section>

<section anchor="managt" title="Management issues">

<t>Today, static IP addresses are routinely embedded in numerous
configuration files and network management databases, including
MIB modules. Ideally, all 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).</t>

<t>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. Synchronizing updates between
independent sites can cause unpredictable delays. 
Note that <xref target="ula"/>
suggests that IPv6 ULAs can mitigate this problem, but of course
only for VPNs and routes which are suitable for ULAs rather than
globally routeable addresses.  The majority of external adresses
to be configured will not be ULAs.</t>

<t>See <xref target="Appendix1"/> for an extended list of
possible static or embedded addresses.</t>

<t>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. </t>

<t>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.</t>

<t>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. </t>

<t>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.</t>

<t>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 <xref target="RFC1958"/> (point 4.1). 
Just as we noted in  <xref target="appiss"/> 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. </t>

<t>By definition there is then at least one place
(i.e., the DNS zone file or the database that it is derived from)
where address information is nevertheless inevitable.</t>

<t>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 <xref target="RFC1958"/> (point 3.11). </t>

<t>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 
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 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.</t>

<t>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.</t>

<t>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. </t>

</section>

<section anchor= "seciss" title="Security issues">

<t>For IPv6, addresses are intended to be protected against
forgery during neighbor discovery by SEcure Neighbor Discovery
(SEND) <xref target="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. </t>


<t>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). </t>

<t>There will be operational and security issues if an X.509v3
PKI Certificate includes a subjectAltName extension that contains
an iPAddress <xref target="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.</t>
 
<t>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 which is listed in a black list
can escape that list by renumbering itself.</t>

<t>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 <xref target="dnsconf"/>),
now that there is strong DNS Security deployment momentum. </t>


</section>
</section>

</section> <!-- opissues -->


<section anchor="propmech" title="Proposed Mechanisms">

This section lists several mechanisms or proposed mechanisms,
which exist today or might exist in the near future, that
appear likely to help ease the pain of site renumbering.
The authors believe it would be worthwhile for the Internet
community to explore these ideas further.

<section title="SHIM6">

<t>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
<xref target="RFC5533"/>.  At least in principle,
this property could be used during renumbering to alleviate the
problem described in <xref target="tcpudp"/>. </t>

<t>SHIM6 is an example of a class of solutions with this or a similar property; others are HIP, MOBIKE,
Mobile IPv6, SCTP and proposals for multipath TCP. </t>

</section>
   
<section title="MANET proposals">

<t>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. </t>

<t>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
<xref target="I-D.boot-autoconf-brdp"/>.</t>

<t>At present, the IETF AutoConf WG
[<eref target="http://www.ietf.org/html.charters/autoconf-charter.html"/>]
is working on address auto-configuration mechanisms for MANET
networks that also seem useful for ordinary non-mobile 
non-MANET networks   
<xref target="I-D.ietf-autoconf-manetarch"/>.  This work is
extensively surveyed in
<xref target="I-D.bernardos-manet-autoconf-survey"/> and
<xref target="I-D.bernardos-autoconf-solution-space"/>.  Other
work in the same area, e.g.,
<xref target="I-D.templin-autoconf-dhcp"/>, might also be
relevant. </t>

<t>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
<xref target="managt"/> 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.</t>


</section>

<section title="Other IETF work">

<t>A DHCPv6 extension has been proposed which could convey alternative
routes, in addition to the default router address, to IPv6 hosts
<xref target="I-D.dec-dhcpv6-route-option"/>. 
Other DHCP options are also on the table
that may offer information about
address prefixes and routing to DHCP or DHCPv6 clients,
such as <xref target="I-D.ietf-dhc-subnet-alloc"/> and 
<xref target="I-D.sun-mif-route-config-dhcp6"/>. It is conceivable that
these might be extended as a way of informing hosts dynamically
of prefix changes. 
</t>


<t>In the area of management tools, NETCONF
<xref target="RFC4741"/> is suitable for the configuration of any
network element or server, so could in principle be used to
support secure remote address renumbering. </t>

<t>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 
<xref target="I-D.dickinson-dnsop-nameserver-control"/>. </t>

</section>

<section title="Other Proposals">

<t>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 <xref target="scrocker"/>. While this might be viewed
as provocative, it would force the issue by making renumbering
compulsory. </t>


</section>
</section> <!-- propmech -->


<section anchor="gaps" title="Gaps">

<t>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.</t>


<section title="Host-related gaps">

<t>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. </t>

<t>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. </t>

<t>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. </t>

<t>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 LDAP, a fully standardized approach seems desirable. </t>

<t>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 <xref target="RFC3118"/> to be deployed. </t>

<t>The IETF should resolve the 'IPv6 ND M/O flag debate' once
and for all, with default, mandatory and optional behaviors of
hosts being fully specified. </t>

<t>The host behavior for upstream link learning suggested in
<xref target="uplinks"/> should be documented.</t>

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

    
</section>

<section title="Router-related gaps">

<t>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.</t>

<t>A MANET solution that's solid enough to apply to fully
operational small to medium fixed sites for voluntary or
involuntary renumbering. </t>

<t>A MANET-style solution that can be applied convincingly to
large or very large sites for voluntary renumbering. </t>

<t> A useful short-term measure would be to ensure that <xref target="RFC2894"/> 
and <xref target="RFC3633"/> can be used in practice. </t>

</section>

<section title="Operational gaps">

<t>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.</t>

<t>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.</t>

<t>Deploy multi-prefix usage of IPv6, including ULAs to provide stable
internal addresses. In particular, address management tools
need to support the multi-prefix model and ULAs. </t>

<t>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. </t>

<t>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 <xref target="dleroy"/>. </t>

<t>Document functional requirements for site renumbering tools or
toolkits. </t>

<t>Document operational procedures useful for site
renumbering.</t>

<t>In general, document renumbering instructions as part of every
product manual. </t>

<t>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. </t>

</section>

<section title="Other gaps">

<t>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).</t>

<t>For Mobile IP, define a better mechanism to handle change of home agent
address while mobile is disconnected. </t>

</section>

</section> <!-- gaps -->




<section anchor="security" title="Security Considerations">

<t>Known current issues are discussed in <xref target="seciss"/>.
Security issues related to SLAAC are discussed in
<xref target="RFC3756"/>. DHCP authentication is defined in <xref target="RFC3118"/>. </t>

<t>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  <xref target="appiss"/>,
this may result in defensive techniques such as "DNS pinning"
which create difficulty when renumbering. </t>

<t>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 pre-existing trust relationship between such
sites.</t>
   
</section> <!-- security -->


<section anchor="iana" title="IANA Considerations">
   <t>This document requires no action by the IANA. </t>
</section> <!-- iana -->


<section anchor="ack" title="Acknowledgements">

 <t>Significant amounts of text have been adapted from
<xref target="I-D.chown-v6ops-renumber-thinkabout"/>, which reflects work
carried out during the 6NET project funded by the Information Society 
Technologies Programme of the European Commission. The authors
of that draft 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.
</t>

<t>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.</t>

<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>

</section> <!-- ack -->


<section anchor ="changes" title="Change log [RFC Editor to remove]">

<t>draft-carpenter-renum-needs-work-00: original version, 2008-10-23</t>

<t>draft-carpenter-renum-needs-work-01: additional text in many
places, started gap analysis, additional author, 2008-12-21</t>

<t>draft-carpenter-renum-needs-work-02: added discussion of 802.1X, SLP, FORCERENEW, reverse DNS,
FQDN-based configuration, DNS pinning, RA and DHCPv6 route preferences;
minor edits, additional references, 2009-02-18</t>

<t>draft-carpenter-renum-needs-work-03: updated following IETF74 feedback, expanded
discussion of multicast, more discussion of multi-prefix issues, 2009-05-07</t>

<t>draft-carpenter-renum-needs-work-04: updated following IETF Last Call comments, 2009-10-22</t>

<t>draft-carpenter-renum-needs-work-05: updated following IESG comments, 2009-12-19</t>

</section> <!-- changes -->

</middle>

<back>

<references title="Informative References">

&RFC1900;
&RFC1918;
&RFC2629;
&RFC4192;
&RFC4193;
&RFC1916;
&RFC2071;
&RFC2072;
&RFC2874;
&RFC2894;
&RFC4076;
&RFC2131;
&RFC3315;
&RFC4861;
&RFC4862;
&RFC3795;
&RFC1661;
&RFC5072;
&RFC3633;
&RFC3007;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC4960;
&RFC5061; 
&RFC4340;
&RFC3736;
&RFC5280;
&RFC1332;
&RFC3306;
&RFC3956;
&RFC3775;
&RFC3971;
&RFC4941;
&RFC3756;
&RFC4741; 
&RFC2608;
&RFC2610;
&RFC3059;
&RFC3224;
&RFC3421;
&RFC3832;
&RFC3958;
&RFC3203;
&RFC1958;
&RFC2407;
&RFC4306;
&RFC4191;
&RFC5059;
&RFC5533;
&RFC3118;

&DRAFT-think;
&DRAFT-sctpnat;
&DRAFT-brdp;
&DRAFT-autoc;
&DRAFT-autoc2;
&DRAFT-autoc3;
&DRAFT-vet;
&DRAFT-dnscont;
&DRAFT-dhrtopt;
&DRAFT-dhsubnet;
&DRAFT-dhmifrt;
&DRAFT-nat66;
&DRAFT-lisp;
&DRAFT-ilnp;
&DRAFT-61;
&DRAFT-cpe;
&DRAFT-mdns;
&DRAFT-dnssd;

<reference anchor='dnsbook'>
<front>
<title>DNS and BIND (5th edition)</title>
<author initials="P." surname="Albitz" fullname="Paul Albitz"/>
<author initials="C." surname="Liu" fullname="Cricket Liu"/>
<date year='2006'/>
</front>
<seriesInfo name="O'Reilly" value='' />
</reference>

<reference anchor='IEEE.802-1X'>
<front>
<title>Port-Based Network Access Control: 
IEEE Standard for Local and Metropolitan Area Networks 802.1X-2004</title>
<author> <organization>Institute of Electrical and Electronics Engineers</organization></author>
<date month='December' year='2009'/>
</front>
</reference>

<reference anchor='IEEE.802-1X-REV'>
<front>
<title>802.1X-REV - Revision of 802.1X-2004 - Port Based Network Access Control: 
IEEE Standard for Local and Metropolitan Area Networks</title>
<author> <organization>Institute of Electrical and Electronics Engineers</organization></author>
<date  year='2009'/>
</front>
</reference>



<reference anchor='scrocker' target='http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF/wednesday/Renumbering_Crocker.pdf'>
<front>
<title>Renumbering Considered Normal
</title>
<author initials="S." surname="Crocker" fullname="Steve Crocker"/>
<date year='2006'/>
</front>
</reference>

<reference anchor='dleroy'
target='http://inl.info.ucl.ac.be/system/files/dleroy-nem-2009.pdf'>
<front>
<title>Preparing network configurations for IPv6 renumbering</title>
<author initials="D." surname="Leroy" fullname="Damien Leroy"/>
<author initials="O." surname="Bonaventure" fullname="Olivier Bonaventure"/>
<date year='2009'/>
</front>
<seriesInfo name='International Journal of Network Management' value='' />
</reference>




<reference anchor='handley' target='http://www.ietf.org/proceedings/08jul/slides/RRG-2.pdf'>
<front>
<title>Multipath Transport, Resource Pooling, and implications
for Routing</title>
<author initials="M." surname="Handley" fullname="Mark Handley"/>
<author initials="D." surname="Wischik" fullname="Damon Wischik"/>
<author initials="M." surname="Bagnulo" fullname="Marcelo Bagnulo Braun"/>
<date year='2008'/>
</front>
</reference>


    
</references>

<section anchor="Appendix1" title="Embedded IP addresses">

<t>This Appendix lists common places where IP addresses might be
embedded. The list was adapted from
<xref target="I-D.chown-v6ops-renumber-thinkabout"/>.</t>

<list type="symbols">

<t>Provider based prefix(es)</t>

<t>Names resolved to IP addresses in firewall at startup time
</t>

<t>IP addresses in remote firewalls allowing access to remote
services</t>

<t>IP-based authentication in remote systems allowing access to
online bibliographic resources</t>

<t>IP address of both tunnel end points for IPv6 in IPv4 tunnel
</t>

<t>Hard-coded IP subnet configuration information</t>

<t>IP addresses for static route targets</t>

<t>Blocked SMTP server IP list (spam sources)</t>

<t>Web .htaccess and remote access controls</t>

<t>Apache .Listen. directive on given IP address</t>

<t>Configured multicast rendezvous point</t>

<t>TCP wrapper files</t>

<t>Samba configuration files</t>

<t>DNS resolv.conf on Unix </t>

<t>Any network traffic monitoring tool</t>

<t>NIS/ypbind via the hosts file</t>

<t>Some interface configurations</t>

<t>Unix portmap security masks</t>

<t>NIS security masks</t>

<t>PIM-SM Rendezvous Point address on multicast routers</t>

</list>

</section>

</back>
</rfc>