[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 5887

Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                               R. Atkinson
Expires: April 25, 2009                                 Extreme Networks
                                                        October 23, 2008


                      Renumbering still needs work
                  draft-carpenter-renum-needs-work-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 25, 2009.

Abstract

   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.










Carpenter & Atkinson     Expires April 25, 2009                 [Page 1]

Internet-Draft        Renumbering still needs work          October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Existing Host-related Mechanisms . . . . . . . . . . . . . . .  4
     2.1.  DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  PPP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  IPv6 Stateless Address Auto-configuration  . . . . . . . .  4
     2.4.  IPv6 ND Router/Prefix advertisements . . . . . . . . . . .  5
     2.5.  DNS configuration  . . . . . . . . . . . . . . . . . . . .  6
   3.  Existing Router-related Mechanisms . . . . . . . . . . . . . .  6
     3.1.  Router renumbering . . . . . . . . . . . . . . . . . . . .  7
   4.  Operational Issues with Renumbering Today  . . . . . . . . . .  7
     4.1.  Host-related issues  . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  Network layer issues . . . . . . . . . . . . . . . . .  7
       4.1.2.  Transport layer issues . . . . . . . . . . . . . . . .  9
       4.1.3.  DNS issues . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.4.  Application layer issues . . . . . . . . . . . . . . . 10
     4.2.  Router-related issues  . . . . . . . . . . . . . . . . . . 10
     4.3.  Other issues . . . . . . . . . . . . . . . . . . . . . . . 11
       4.3.1.  NAT state issues . . . . . . . . . . . . . . . . . . . 11
       4.3.2.  Mobility issues  . . . . . . . . . . . . . . . . . . . 11
       4.3.3.  Multicast issues . . . . . . . . . . . . . . . . . . . 11
       4.3.4.  Management issues  . . . . . . . . . . . . . . . . . . 11
       4.3.5.  Security issues  . . . . . . . . . . . . . . . . . . . 12
   5.  Proposed Mechanisms  . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  SHIM6  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  MANET proposals  . . . . . . . . . . . . . . . . . . . . . 13
   6.  Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Host-related gaps  . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Router-related gaps  . . . . . . . . . . . . . . . . . . . 13
     6.3.  Operational gaps . . . . . . . . . . . . . . . . . . . . . 13
     6.4.  Other gaps . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   11. Informative References . . . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Embedded IP addresses . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18











Carpenter & Atkinson     Expires April 25, 2009                 [Page 2]

Internet-Draft        Renumbering still needs work          October 2008


1.  Introduction

   [[ This is a first draft; some sections are incomplete.  The authors
   invite comments. ]]

   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 atomic mechanisms have become
   available to simplify some aspects of renumbering.  The Dynamic Host
   Configuration Protocol is available for IPv4 [RFC2131] and IPv6
   [RFC3315].  IPv6 includes Stateless Address Autoconfiguration (SLAAC)
   [RFC4862], and this includes Router Advertisements that include
   options listing the set of active prefixes on a link.  PPP [RFC1661],
   [RFC5072] also automates 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.  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.  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 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.  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 may assume site renumbering to be a straightforward matter.

   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
   lost 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 software using
   the address.  Many of the issues listed below derive from this fact.




Carpenter & Atkinson     Expires April 25, 2009                 [Page 3]

Internet-Draft        Renumbering still needs work          October 2008


2.  Existing Host-related Mechanisms

2.1.  DHCP

   At 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 may 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.  Do MAC addresses have to be pre-registered, or can any MAC
   interface be given an IP address?  Will the same IP address be
   assigned to the same MAC address every time, according to a
   predefined scheme?  (In this case, DHCP is used to mimic manual fixed
   address assignments.)  Alternatively, will the IP addresses in a
   subnet be assigned on a first-come, first-served basis?

   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 administrative information of various kinds.  Such a
   database can be used to generate configuration files for DHCP, DNS
   and any access control mechanisms that may be in use.  For example,
   only certain MAC addresses may 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.

   A site that uses DHCP can in principle renumber its hosts by
   reconfiguring DHCP for the new address range.  The issues with this
   are discussed below.

2.2.  PPP

   [[ Note - need some text from someone knowledgeable about PPP. ]]

2.3.  IPv6 Stateless Address Auto-configuration

   SLAAC, although updated recently [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-



Carpenter & Atkinson     Expires April 25, 2009                 [Page 4]

Internet-Draft        Renumbering still needs work          October 2008


   local multicast Router Advertisement (RA) [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.

   We will not describe here the processes of duplicate address
   detection, neighbor discovery, and neighbor unreachability discovery.
   Suffice it to say that they work, once the initial address assignment
   based on the RA has taken place.

   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.

2.4.  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 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 Section 2.3.  However, there are some issues in this
   area, described in Section 4.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 have been told (via the IPv6 RA message)
   to configure using DHCPv6 (rather than auto-configuring) to
   dynamically learn about the availability of upstream links by
   dynamically learning (from the periodic IPv6 RA messages) which
   routing prefixes are currently valid.  This application seems



Carpenter & Atkinson     Expires April 25, 2009                 [Page 5]

Internet-Draft        Renumbering still needs work          October 2008


   possible within the IPv6 Neighbour Discovery architecture, but this
   application does not appear to be clearly specified anywhere.  So at
   present this approach for hosts learning about availability of new
   upstream links or loss of prior upstream links is unlikely to work
   with currently shipping hosts or routers.

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.  The alternative is to use DNS dynamic 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 MacOS X all include support for Secure Dynamic DNS
   Update.  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.  MS Exchange)
   often are deployed with Dynamic DNS also enabled.  In some cases,
   merely enabling both the DNS server and the DHCP server might enable
   Dynamic DNS also ([dnsbook] p. 506).  So in some cases, sites might
   have deployed Dynamic DNS without realising it.

   The network security community appears to believe that the current
   DNS Security and Secure Dynamic DNS Update specifications are
   reasonably secure for most deployment environments [RFC3007],
   [RFC4033], [RFC4034], [RFC4035].

   The authors note that at the time of this writing there appears to be
   significantly more momentum towards rapid deployment of DNS Security
   standards in the global public Internet than previously.  See for
   example <http://www.dnssec-deployment.org/> and
   <http://www.ntia.doc.gov/DNS/DNSSEC.html>.


3.  Existing Router-related Mechanisms






Carpenter & Atkinson     Expires April 25, 2009                 [Page 6]

Internet-Draft        Renumbering still needs work          October 2008


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
   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. [[ Say more. ]]

   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 suggested as a useful mechanism by [RFC4192].


4.  Operational Issues with Renumbering Today

   For IPv6, a useful description of practical aspects was drafted in
   [I-D.chown-v6ops-renumber-thinkabout], as a complement to [RFC4192].

   [[ Note: need to extract issues from that draft. ]]

4.1.  Host-related issues

4.1.1.  Network layer issues

   For IPv4, the vast majority of client systems (PCs and workstations)
   today use DHCP to obtained their addresses and other network layer
   parameters.  Since DHCP provides for lifetimes after which the
   address lease expires, 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 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.  It has a useful extra feature, a "reconfig-init"
   message that can be sent to all hosts to inform them to check their
   DHCPv6 server for an update.

   Using such an approach with DHCP 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



Carpenter & Atkinson     Expires April 25, 2009                 [Page 7]

Internet-Draft        Renumbering still needs work          October 2008


   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 DHCPv6 "reconfig-init" message 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 the
   lease time and 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. 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.  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.

   The SLAAC approach, or DHCP without pre-registered MAC addresses, do
   not work for servers, or for any other systems that are assigned
   fixed IP addresses for historical reasons.  Manual or script-driven
   procedures, likely to be site-specific and definitely prone to human
   error, are needed.  Unless a site has no hosts with fixed addresses,



Carpenter & Atkinson     Expires April 25, 2009                 [Page 8]

Internet-Draft        Renumbering still needs work          October 2008


   completely automatic host renumbering is therefore very unlikely to
   be possible.

   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 may not be used and even
   configuration scripts are not an option; for example, fixed IP
   addresses may be stored in read-only memory.  Such systems create
   special problems that no general-purpose solution is likely to
   address.

4.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 for them 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
   DCCP [RFC4340].

   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 [RFC4960], [RFC5061].

4.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.  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.







Carpenter & Atkinson     Expires April 25, 2009                 [Page 9]

Internet-Draft        Renumbering still needs work          October 2008


4.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 analysing specifications whether an
   actual implementation is sensitive to renumbering.  Indeed, such
   analysis may be quite impossible in the case of proprietary
   applications.

   The sensitivity depends on whether the implementation stores IP
   addresses in such a way that it may refer back to them later, without
   allowing for the fact that they may no longer be valid.  In general,
   we can assert that any implementation that does not check that an
   address is valid (e.g., by resolving relevant FQDNs again) each time
   it opens a new communications session is at risk from renumbering.
   There are quite 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.)

4.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 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 [RFC2072] are:
   o  Addresses are cached in routers - routers may need to be
      restarted.
   o  Addresses used by configured tunnels [and today, VPNs] may be
      overlooked.

   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



Carpenter & Atkinson     Expires April 25, 2009                [Page 10]

Internet-Draft        Renumbering still needs work          October 2008


   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.

4.3.  Other issues

4.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 [I-D.xie-behave-sctp-nat-cons],
   depending whether a single or multiple NATs are involved.

   A NAT itself may be renumbered and may need a configuration change
   during a renumbering event.

4.3.2.  Mobility issues

   A mobile node using Mobile IP that is not currently in its home
   network will be affected if either its current care-of address or its
   home address is renumbered. [[ Expert input required. ]]

4.3.3.  Multicast issues

   [[ Can be found in [I-D.chown-v6ops-renumber-thinkabout] ]]

4.3.4.  Management issues

   Today, IP addresses are routinely embedded in numerous configuration
   files and network management databases, including MIBs.  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.  Furthermore, because of routing policies and VPNs, a site
   or network may well embed addresses from other sites or networks in
   its own configuration data.  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.

   Use of FQDNs rather than raw IP addresses wherever possible in
   configuration files and databases might reduce/mitigate the potential
   issues arising from such configuration files or management databases
   when renumbering is required or otherwise occurs.  However, by



Carpenter & Atkinson     Expires April 25, 2009                [Page 11]

Internet-Draft        Renumbering still needs work          October 2008


   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.

   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) is the
   dominant concern of managers considering the renumbering problem.
   This has led to a strong managerial preference for continuing the
   pre-CIDR approach of a provider-independent (PI) prefix, or even for
   using private addressing and NAT as a matter of choice rather than
   obligation.  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.

4.3.5.  Security issues

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

   There will be operational and security issues if an X.509v3 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 which is listed in a black list can escape that
   list by renumbering itself.


5.  Proposed Mechanisms

5.1.  SHIM6

   SHIM6, proposed as a host-based multihoming mechanism for IPv6, has
   the property of switching addresses dynamically in the actual packet
   stream while presenting a constant upper layer identifier to the
   transport layer [I-D.ietf-shim6-proto].  At least in principle, this
   property could be used during renumbering to alleviate the problem



Carpenter & Atkinson     Expires April 25, 2009                [Page 12]

Internet-Draft        Renumbering still needs work          October 2008


   described in Section 4.1.2.

5.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.  This work continues.

   Recently, some MANET work has appeared on a Border Router Discovery
   Protocol that might be useful work towards a more dynamic mechanism
   for site interior router renumbering [I-D.boot-autoconf-brdp].

   At present, the IETF AutoConf WG
   [<http://www.ietf.org/html.charters/autoconf-charter.html>] is
   working on address auto-configuration mechanisms for MANET networks
   that seem likely to be useful for ordinary non-mobile non-MANET
   networks also [I-D.ietf-autoconf-manetarch].  Other work in the same
   area, e.g.  [I-D.templin-autoconf-dhcp], may also be relevant.


6.  Gaps

6.1.  Host-related gaps

   TBD

6.2.  Router-related gaps

   TBD

6.3.  Operational gaps

   TBD

6.4.  Other gaps

   TBD


7.  Security Considerations

   TBD

   [[ Notes:

   A. Some sort of authentication capability ought to be available for



Carpenter & Atkinson     Expires April 25, 2009                [Page 13]

Internet-Draft        Renumbering still needs work          October 2008


   sites that want this.

   B. SEND appears to be very difficult to actually deploy and operate.
   At present it is unclear whether or when SEND might be widely
   implemented or widely deployed.

   C. Key distribution is normally the hard part, rather than the actual
   authentication mechanism.

   D. Issues for privacy addresses?. ]]


8.  IANA Considerations

   This document requires no action by the IANA.


9.  Acknowledgements

   Useful comments and suggestions were made by Hannu Flinck.

   This document was produced using the xml2rfc tool [RFC2629].


10.  Change log

   draft-carpenter-renum-needs-work-00: original version, 2008-10-23


11.  Informative References

   [I-D.boot-autoconf-brdp]
              Boot, T. and A. Holtzer, "Border Router Discovery Protocol
              (BRDP) based Address Autoconfiguration",
              draft-boot-autoconf-brdp-00 (work in progress), July 2008.

   [I-D.chown-v6ops-renumber-thinkabout]
              Chown, T., "Things to think about when Renumbering an IPv6
              network", draft-chown-v6ops-renumber-thinkabout-05 (work
              in progress), September 2006.

   [I-D.ietf-autoconf-manetarch]
              Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc
              Network Architecture", draft-ietf-autoconf-manetarch-07
              (work in progress), November 2007.

   [I-D.ietf-shim6-proto]
              Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming



Carpenter & Atkinson     Expires April 25, 2009                [Page 14]

Internet-Draft        Renumbering still needs work          October 2008


              Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work
              in progress), February 2008.

   [I-D.templin-autoconf-dhcp]
              Templin, F., "Virtual Enterprise Traversal (VET)",
              draft-templin-autoconf-dhcp-18 (work in progress),
              October 2008.

   [I-D.xie-behave-sctp-nat-cons]
              Xie, Q., Stewart, R., Holdrege, M., and M. Tuexen, "SCTP
              NAT Traversal Considerations",
              draft-xie-behave-sctp-nat-cons-03 (work in progress),
              November 2007.

   [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.

   [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.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
              IPv6 Address Aggregation and Renumbering", RFC 2874,
              July 2000.

   [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.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,



Carpenter & Atkinson     Expires April 25, 2009                [Page 15]

Internet-Draft        Renumbering still needs work          October 2008


              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 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.

   [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.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 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.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.



Carpenter & Atkinson     Expires April 25, 2009                [Page 16]

Internet-Draft        Renumbering still needs work          October 2008


              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061,
              September 2007.

   [RFC5072]  S.Varada, Haskin, 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.

   [dnsbook]  Albitz, P. and C. Liu, "DNS and BIND (5th edition)", 2006.

   [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>.


Appendix A.  Embedded IP addresses

   This Appendix lists common places where IP addresses may be embedded.

   [[ Can be found in [I-D.chown-v6ops-renumber-thinkabout] ]]


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
   3306 East NC Highway 54, Suite 100
   Research Triangle Park,   NC 27709
   USA

   Email: rja@extremenetworks.com




Carpenter & Atkinson     Expires April 25, 2009                [Page 17]

Internet-Draft        Renumbering still needs work          October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Carpenter & Atkinson     Expires April 25, 2009                [Page 18]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/