Subject: [renum] Simplified Automatic IPv6 Renumbering within ISATAP Sites (non-draft)

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Apr 2011 13:44:28 -0700

The following is not a draft, but rather just a set
of ideas. Any comments or suggestions?

Thanks - Fred
[email-masked]

--- cut here ---

Introduction
************
Countless end user sites in the Internet today still have
predominantly IPv4 infrastructures. These sites range in
size from small home/office networks to large corporate
enterprise networks, but share the commonality that IPv4
continues to provide satisfactory internal routing and
addressing services. As more and more IPv6-only services
are deployed in the Internet, however, hosts within the
site will increasingly require IPv6 functionality for
external access.

Such IPv4 sites can use ISATAP [RFC5214] to provide IPv6
services to hosts within the site. Advertising ISATAP
routers distribute IPv6 prefixes obtained from an ISP
to hosts within the site via DHCPv6 or SLAAC for address
autoconfiguration purposes. If the site subsequently
reconnects to a different ISP, however, the site must
renumber to use addresses derived from the new IPv6
prefixes [RFC1900][RFC4192][RFC5887]. This non-draft
provides operational guidance for accommodating
simplified automatic renumbering within ISATAP sites.

Characteristics of Existing IPv4 Sites
**************************************
Existing end user sites use IPv4 routing and addressing
internally for normal IT operations such as filesharing,
network printing, e-mail, conferencing and numerous other
critical site-internal networking services. Such sites
typically have an abundance of public or private IPv4
addresses for internal networking, and are separated from
the public Internet by firewalls, packet filtering gateways,
proxies, address translators and other site border securing
devices. To date, such sites have had little incentive to
enable IPv6 services internally [RFC1687].

With the emergence of IPv6-only services within the public
Internet, however, existing IPv4 sites will increasingly
require a means for enabling IPv6 services so that hosts
within the site can communicate with IPv6 correspondents
in the Internet. Such services must be deployable with
minimal configuration and in a fashion that will not cause
disruptions to existing IPv4 services within the site. The
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
[RFC5214] provides a simple-to-use service that sites can
deploy in the near term to meet these reqirements.

Enabling Client-Side IPv6 Services with ISATAP
**********************************************
Small sites typically arrange to obtain public IPv6 prefixes
from an Internet Service Provider (ISP) in the same fashion
as for home network users. When the ISP does not yet provide
native IPv6 services, it can instead offer a transitional
service with native-equivalent capabilities using 6RD
[RFC5569][RFC5969]. Large sites typically obtain provider
independent IPv6 prefixes from an Internet registry and
advertise the prefixes into the IPv6 routing system on their
own behalf, i.e., they act as an ISP unto themselves. (Such
large sites need never incur a site-wide IPv6 renumbering.)

After obtaining IPv6 prefixes, the site can automatically
enable ISATAP based IPv6 services by configuring one or more
site border routers as advertising ISATAP routers. Each such
ISATAP router is added to the Potential Router List (PRL) for
the site so that hosts can discover them for default route
and address auto-configuration purposes.

ISATAP hosts will automatically discover ISATAP site border
routers and configure ISATAP addresses using either Stateless
Address AutoConfiguration (SLAAC) or the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6). In order to provide
a simple service that does not interact poorly with existing
site topological arrangements, the site should limit IPv6
operation for external access only so that hosts only use
the ISATAP service for communicating with IPv6 correspondents
on the public Internet, while continuing to use IPv4 services
for intra-site communications.

In order to maintain an external-only service, the site
should not publish any IPv6 addresses provided by ISATAP
within the site name service. The site should further not
write down any IPv6 literal addresses within configuration
files, documentation, packet filter rules, etc. An exception
to this rule is that literal addresses may be used within
packet filtering rules as long as they can be automatically
rewritten during a site renumbering event. In this way,
intra-site communications will continue to use existing
IPv4 networking services instead of ISATAP served IPv6
services.

Simplified Automatic Renumbering within ISATAP Sites
****************************************************
When the site is configured in the manner described above,
site renumbering in the event of a change in an ISP-served
IPv6 prefix entails only the renumbering of IPv6 addresses
and/or prefixes that are assigned to the ISATAP interfaces
of hosts within the site. In some cases, filtering rules
(e.g., within site border firewall filtering tables) may
also require renumbering, but this operation can be automated
and limited to only one or a few "touch points" at the site
border.

In order to renumber the ISATAP interfaces of hosts within
the site, however, the ISATAP routers need only schedule
the services offered by the old ISP for deprecation while
beginning to advertise the IPv6 prefixes provided by the
new ISP. ISATAP host interface address lifetimes will
eventually expire, and the host will renumber its interfaces
with addresses derived from the new prefixes.

If the site has published the IPv6 addresses of any site-
internal nodes within the public Internet DNS system, then
the corresponding resource records will need to be updated
during the renumbering operation. This can be accomplished
via secure dynamic updates to the DNS.