Subject: RE: Draft Minutes for IPng Interim Meeting

From: "Christian Huitema" <[email-masked]>
Date: Tue, 12 Jun 2001 08:56:29 -0700

> > 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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Wed, 13 Jun 2001 00:02:18 +0700

Date:        Tue, 12 Jun 2001 08:56:29 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | But first, let's agree on the scenarios. Do we believe that they are
  | realistic?

They look reasonable to me.

  | Can we qualify them with a "frequency indicator," e.g. once
  | in a life-time, once a year, once a month, once a day?

Given that #5 needs to be N times a day (twice as stated), if we can
handle that one, then we should be able to handle all the others up to
at least once a day frequency, even if they're not likely to occur
nearly that often.

  | Is there a big scenario that we are missing,

I'm sure there are other rationales for renumbering that can be invented,
but (other than as noted below) they all turn into add a prefix and/or
delete a prefix, and those seem to be covered...

  | such as maybe provider mandated renumbering,

Aside from having less other (unrelated to addressing) configuration
changes to manage (no new leased lines, or changed phone numbers, etc)
this is no different from changing providers.  So it is covered.

But ...

  | or the merging of independent sites?

This one is the noticeably different case.  That's where the internal
numbering of a site may need to be radically altered (there isn't one
change that applies everywhere).   So, this one can be noticeably harder,
at the very least, a new addressing plan needs to be created.   That's
not needed for any kind of external prefix change (another of the benefits
of having fixed sized address block allocations from all providers).

Fortunately though, this one generally is a rare event, is usually known
and can be planned for well in advance, and the disruptions that occur
are usually occurring in all kinds of other fields as well, not just the
network, so people tend to be a little more forgiving (eg: people are more
likely to curse when the merged payroll division doesn't manage to get
anyone's salary paid on time, than when the net is flaky for half a day
due to the numbering changes not having propagated properly).

Lots of other internal renumbering events follow much the same pattern.
These ones are the ones least worth worrying about (not that making them
easier won't be a benefit, just they're not the highest priority).

kre

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 12 Jun 2001 14:13:04 -0400

> at least once a day frequency, even if they're not likely to occur

One additional concern I've heard raised is the interaction between
renumbering, AAAA, and dnssec -- specifically, the cost of re-signing
a zone with new addresses.  The careful sysadmin would do this after
the new prefix was known, but before the new prefix started to be
used.  

How much compute power does this take?  A fair amount, for large
zones.

As an unscientific test, during the dnsext meeting in minneapolis I
took the mit.edu zone (with about 82000 hosts), synthesized AAAA
records for all hosts, and signed it using the tools included with a
recent bind 9 release.

The effort required to re-sign scales linearly with the number of RR's
changed.  Fortunately, this task is paralleizeable; however, the
processors doing the work must be trusted with the zone's private key.
Folks with appropriate levels of paranoia likely won't want to do much
else with this hardware besides maintain the zone(s).

In the absence of DNAME, a roughly similar re-signing effort is
required for PTR zones.

My recollection was that signing the synthesized zone took roughly 90
minutes on my laptop -- a 333mhz celeron.  so, for a rough
order-of-magnitude guesstimate, 1000 signatures per minute on this
system.

Since you need two signatures per address (one on AAAA, one on PTR),
figure on being able to re-sign 1500 addresses per minute per GHz of
cpu.  Renumbering a million-address network would take a bit over 11
GHz-hours of cpu time just for the dnssec signatures alone.

Note that resigning needs to be complete before the RR's can be
replaced -- i.e., the time for renumbering to be complete is the
resigning time plus the TTL...

				- Bill

---

From: [email-masked]
Date: Wed, 13 Jun 2001 09:07:58 +0900

>GHz-hours of cpu time just for the dnssec signatures alone.

	the signing cost consideration really depends on two parameters:
	- how often do we want to renumber
	- how large is the network to get renumbered
	both must carefully be considered to diagnose if A6 gives you more
	benefits or more costs.

	because of other constraints like below, i don't think i (of any admin)
	ever want try to renumber a site with million nodes.  renumber is
	a major task which needs a lot of planning.
	- if you have hardcoded address in any of your router/host configs,
	  you will be in trouble (example: IBGP peer settings, /etc/named.conf
	  for zone transfer, packet filtering, anything that is written by
	  numeric IPv6 address).
	- to avoid canopener-in-can situation for records pointed to by NS
	  records, nameservers basically has to have "A6 0" records.
	  so for these records we don't have benefit from fragmented A6 records.

itojun

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 13 Jun 2001 09:35:59 -0500

> 	- how often do we want to renumber

No, not the frequency, the latency.  That is, how quickly from the
word "go" do you want to have a change in the set of prefixes be
implemented?

> 	ever want try to renumber a site with million nodes.

The *node* count had just better not matter, because we should expect
the number of nodes per {person, house, site, corporation, network}
to increase amazingly during the intended lifetime of IPv6, even if
we can't describe just what all those new nodes will do.

>       renumber is a major task which needs a lot of planning.

But do we commit ourselves to *making* it impossible forever, or do
we do what we can toward easing it?

> 	  for zone transfer, packet filtering, anything that is written by

I agree that if we have hardcoded addresses in *hosts*, the game is
over.  Eliminating them is an interesting problem, and eliminating
them from routers is even more so.

> 	  so for these records we don't have benefit from fragmented A6 records.

You could do the same thing that's suggested for glue in section 5.1.2.

---

From: Bill Manning <[email-masked]>
Date: Wed, 13 Jun 2001 08:01:25 -0700 (PDT)

% > 	- if you have hardcoded address in any of your router/host configs,
% > 	  you will be in trouble (example: IBGP peer settings, /etc/named.conf
% > 	  for zone transfer, packet filtering, anything that is written by
% > 	  numeric IPv6 address).
% 
% I agree that if we have hardcoded addresses in *hosts*, the game is
% over.  Eliminating them is an interesting problem, and eliminating
% them from routers is even more so.

	dont forget your friendly neighborhood SNMP.
	(most of this was discussed in the long dead PIER wg)

-- 
--bill