> > I for one believe that we should assume rapid renumbering as a
feature
> > of IPv6.
>
> great! how does it work? not broad desires, but the devilish details
> please.
This is a perfectly reasonable request. I believe that the correct
answer is "draft the scenarios, plan the technology, demonstrate and
drill." So, lets first agree on a set of scenarios. I propose the
following five:
Scenario 1, first connection:
A site is currently isolated. The internal subnets have been numbered
using "site local" addresses. The site joins the IPv6 Internet. The site
managers use "Router Renumbering for IPv6" (RFC 2894) to automatically
inform the internal routers that they should start advertising the new
prefix. The hosts receive a router advertisement and automatically
create a global address as specified in "IPv6 Stateless Address
Autoconfiguration" (RFC 2462).
Scenario 2, disconnection:
A site is currently connected to the Internet. The site managers plan to
disconnect. This occurs in two phases, first deprecating the old prefix,
then removing it. Both phases are implemented using "Router Renumbering
for IPv6" (RFC 2894) and "IPv6 Stateless Address Autoconfiguration" (RFC
2462).
Scenario 3, multi-homing:
A site is connected to the Internet through a single provider. The site
managers set a contract with another provider, and obtain a new prefix.
The site managers use "Router Renumbering for IPv6" (RFC 2894) to
automatically inform the internal routers that they should start
advertising the new prefix. The hosts receive a router advertisement and
automatically create a second global address as specified in "IPv6
Stateless Address Autoconfiguration" (RFC 2462).
Scenario 4, removing a provider:
A site is connected to the Internet through two providers. The site
managers want to terminate the contract with one of these providers.
This occurs in two phases, first deprecating the old prefix, then
removing it. Both phases are implemented using "Router Renumbering for
IPv6" (RFC 2894) and "IPv6 Stateless Address Autoconfiguration" (RFC
2462).
Scenario 5, time-of-day preference:
A site is connected to the Internet through two providers. These
providers use different tariffs. The site managers desire that one of
the providers be preferred during working hours, say from 9:00 am to
5:00 pm, and another be preferred during the rest of the day. They use
"Router Renumbering for IPv6" (RFC 2894) at critical times (9:00 am,
6:00 pm) to deprecate one of the global prefixes and promote the other.
The hosts receive router advertisements and heed them as specified in
"IPv6 Stateless Address Autoconfiguration" (RFC 2462).
You will indeed notice that these scenarios are broadly sketched. The
purpose of the scenarios is indeed to discover whatever is missing in
our toolbox. For example, we say nothing of "static address filters"
used for QoS and security purposes; we may guess that these could be
updated as a side effect of router renumbering, but we would be better
offwith a real specification. More to the point, we say nothing about
DNS interaction. We know the requirement, as Itojun pointed it:
addresses should remain valid for as long as the TTL of the DNS record;
this is addressed in the scenarios 2 and 4 through a two phase approach,
first deprecate a prefix, then at the end of the TTL remove it. When it
comes to creating new addresses, or deprecating them, we really have two
choices. One possibility is to let the hosts use dynamic DNS updates to
create or update AAAA or A6 records on the fly; another possibility is
to have the site managers update the AAAA or A6 records in a reference
file. We have to analyse the benefit/cost of AAAA/A6 in this context.
But first, let's agree on the scenarios. Do we believe that they are
realistic? Can we qualify them with a "frequency indicator," e.g. once
in a life-time, once a year, once a month, once a day? Is there a big
scenario that we are missing, such as maybe provider mandated
renumbering, or the merging of independent sites?
-- Christian Huitema
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
