Subject: RE: Draft Minutes for IPng Interim Meeting

From: Alain Durand <[email-masked]>
Date: Mon, 11 Jun 2001 19:58:16 -0700

At 06:47 PM 6/11/2001 -0700, Christian Huitema wrote:
>I for one believe that we should assume rapid renumbering as a feature
>of IPv6. The argument for that is the classic "fire escape" analogy. If
>you don't practice frequent exercises, you find one the day of the
>actual fire that a clutter of boxes blocks the escape. If we want to be
>able to renumber when needed, then we should assume that we will
>renumber frequently.

It all depend on the definition of "rapid".
If rapid means every "hours" or every "day", I find it very unlikely.
Previous experiences in renumbering even small sites have shown me
that the overall process can takes weeks, and that there are unavoidable
non-technical dependencies and administrative steps that must take place
and they consume most of the time.

It does not mean that we should stop working on renumbering, however it means
that we should have realistic goals, and renumbering every hours or even 
every day
seems to me unrealistic for now.Yes, IPv6, with stateless autoconf and 
Router Renumbering,
has features that help renumbering, but this does not make the event 
painless nor rapid.

         - Alain.

--------------------------------------------------------------------
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: Tue, 12 Jun 2001 14:28:32 +0700

Date:        Mon, 11 Jun 2001 19:58:16 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <5.1.0.14.0.20010611193607.02281c38@jurassic>

  | It all depend on the definition of "rapid".
  | If rapid means every "hours" or every "day", I find it very unlikely.

You're actually talking about the frequency of renumbering there, rather
than how quickly a renumbering can be accomplished.  Clearly the frequency
can't be more than once per renumbering event duration, but it can be much
less (if I could renumber in an hour, that doesn't mean I will renumber
every hour - but it certainly means I can't renumber faster than that).

  | Previous experiences in renumbering even small sites have shown me
  | that the overall process can takes weeks, and that there are unavoidable
  | non-technical dependencies and administrative steps that must take place
  | and they consume most of the time.

This is the "we don't need good brakes on cars, we know cars don't do
faster than people's walking speed, because there has to be someone walking
in front of each one waving a red flag" argument ...

What we have to work towards, and assume that we will achieve is the ideal
target, until it is clear that cannot be reached - rather than assuming that
because we haven't achieved it yet, we never will.

It used to be that configuring an IP node took considerable time and
expertise - then bootp was invented, which made it easier (then that
turned into dhcp) - but that (either) still required someone with experience
to configure the server.  IPv6 has autoconf which makes it easier still.

We can do the same with renumbering - that it has been difficult in the
past doesn't mean that it must remain so.

I want to have it so that once I know a new prefix is available to me, I
can have it in use on all my nodes (say 20K of them) in 5 minutes.  And
simultaneously deprecate an old prefix, if that is appropriate.  And then
when an old prefix is done with, delete it from all nodes in the same
kind of timespan.

Note that for the DNS, each of those two is a renumbering event (though if
the second (delete) is known when the first (new prefix) is arranged, they
might be collapsed into one).   From the outside the whole thing may take
a month, and be considered to be one long renumbering process (from new prefix
appearing to old one vanishing) - to the DNS however there are two
separate events that each need to happen rapidly...

kre

---

From: [email-masked]
Date: Tue, 12 Jun 2001 19:19:24 +0900

>and they consume most of the time.

	there are a couple of analysis on IPv6 network renumbering available:
	- Fred Baker's draft (where?)
	- Jinmei's presentation at IETF49?
	- I have covered some essentials in draft-ietf-dnsext-aaaa-a6-00.
	we really need to resurrect Fred's draft.
	the bottom line is that you cannot renumber more frequently than
	(DNS TTL * 2), so if you set DNS TTL to 1 day, you can only renumber
	every other day.  every hardcoded address parmeteres in every router/
	host will bite you.  renumbering is not an easy task.

itojun

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 12 Jun 2001 09:05:49 -0500

> 	every other day.

And this is true no matter what sort of records you are storing your
addresses in.

However, consider a large site using two-level A6 records, one for
a prefix and one for, say, SLA+IID.  For renumbering the site, it's
only the TTL of the prefix record that limits the speed of
renumbering.  If a communicating site talks to many nodes in the
potentially-renumbering site, there's only one short-lifetime RR it
needs to keep fetching.

And recall that ipngwg and the registries have accepted the idea that
a person may carry a whole site.  The person may be moving at a
couple of hundred km/h and while continuous renumbering may not be
the preferred mode of maintaining ongoing communication, renumbering
at the departure and arrival points is quite plausible.
--------------------------------------------------------------------
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: [email-masked]
Date: Wed, 13 Jun 2001 09:27:50 +0900

>every hour - but it certainly means I can't renumber faster than that).

	i don't understand what is the point in this sentence...  yeah,
	the following invariant is true:
		frequency of renumbering >= the time needed for renumbering 
	but what's the point?  for the purpose of analysis of A6,
	are you suggesting which parameter is more important than which?
	could you clarify if possible? (or, if it is not the point please
	forget about this note)

itojun

---

From: Robert Elz <[email-masked]>
Date: Wed, 13 Jun 2001 15:13:24 +0700

Date:        Wed, 13 Jun 2001 09:27:50 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	i don't understand what is the point in this sentence...  yeah,

Sorry about that, it is a common complaint about my writing, I shall
try to do better.

  | 	for the purpose of analysis of A6,
  | 	are you suggesting which parameter is more important than which?
  | 	could you clarify if possible? (or, if it is not the point please
  | 	forget about this note)

What I was trying to say was that people often look at renumbering and
say "I am never going to want to renumber every day, if I do it once a
year it will be too frequent" which may well turn out to be true.

However, it isn't the frequency of renumbering that matters really here,
what counts is how rapidly I can renumber when I need to - how much work
do I have to do to complete the renumbering sequence, and how long is that
going to take me?    If I can get the renumbering down to the state where
I can complete the whole thing in under a day, then I could renumber every
day if I had to, but this doesn't mean that is what I will ever do.

On the other hand, saying "no-one will need to renumber more frequently than
once a month, as we'll always be able to let people keep their old addresses
that long during a transition" doesn't mean that the renumbering event can be
allowed take a month to be completed (a transition is usually going to be two
renumbering events, neither of which should take anything like a half month
even).

In your reply to Bill Sommerfeld you pointed out two other issues ...

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

This is absolutely true, and a reason we must strive to avoid all such
numerically encoded configurations.   Even if it just means writing the
relevant config files using names, and then pre-processing them with a
script that does DNS lookups and converts the names to numbers, and while
doing so, remembers the minimum TTL it encountered, and re-schedules itself
to be run after that many seconds - and then any time the resulting
numerically encoded files change, causing them to be reloaded into the
appropriate router/process.    This is something of a crude and inefficient
way to avoid configuring static addresses anywhere, but it is better than
the alternatives.

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

Yes, the NS records are (at the very least in the medium term, and perhaps
forever) going to have to be associated with names where the benefits of
A6 are unlikely to be achieved.   For some truly huge organisations there
may be 30 or 40 systems running as published nameservers (nameservers
running not listed in any NS records don't count of course).   Each of those
may have half a dozen A6 0 records associated with them perhaps (just guessing
at averages).  So, there could be 200-300 records in addition to a few
"prefix" A6 records to be updated when a prefix changes.   This still seems
manageable to me, and still a big win over having to update tens of thousands
of AAAA records.

kre

---

From: [email-masked]
Date: Wed, 13 Jun 2001 18:14:14 +0900

>renumbering events, neither of which should take anything like a half month

	sorry if any of my past draft/presentations/postings/whatever sounded
	like that.  i was trying to analyze the minimal possible frequency
	for renumber, so that we can understand what is the true requirement
	to IPv6 DNS records.  i should make it clearer next time.

	the fact i've learned is that, once we advertise a DNS record
	(with old /48 prefix we are trying to get rid of), we cannot remove
	them till TTL for these record expires (since the record may be
	cached somewhere in the world).  the "frequency of renumber" analysis
	is the extreme case for this.
	if we are going to use fragmented A6 records, we really need to
	diagnose relationship between the following items:
	- minimal possible frequency for renumber event
	- timing parameter for DNS, including record TTL, (accumulated) query
	  delays for each fragments, and such.
	the delay analysis is highly critical, IMHO (there were clarification
	from Rob, but it still does worry me and i plan to do more diagonsis).

>manageable to me, and still a big win over having to update tens of thousands

	to help signing zone file with mixture of "A6 0" and "A6 x" (x != 0)
	we at least need a better signing tool... with the current BIND9 tool
	we can only sign the whole zone.

	and again, zone signing cost analysis has to take a lot of things
	into account, like timing constraints, deployment issues and
	reality in needs of renumber...

itojun

---

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

Date:        Wed, 13 Jun 2001 18:14:14 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	sorry if any of my past draft/presentations/postings/whatever sounded
  | 	like that.  i was trying to analyze the minimal possible frequency
  | 	for renumber, so that we can understand what is the true requirement
  | 	to IPv6 DNS records.  i should make it clearer next time.

It isn't so much your writings as a general attitude that I seem to
be detecting sometimes - that in practice renumbering isn't going to
be needed as frequently as some feared in the early IPng discussions,
and that consequently, renumbering isn't so important, and stuff which
is there to support it really isn't needed after all.

Incidentally, while I doubt anyone has any difficulty understanding what
you mean, you really mean the minimum period (or duration) of renumbering,
or the maximum frequency, discovering the minimum frequency wouldn't be
an interesting thing to look for ...

  | 	the fact i've learned is that, once we advertise a DNS record
  | 	(with old /48 prefix we are trying to get rid of), we cannot remove
  | 	them till TTL for these record expires (since the record may be
  | 	cached somewhere in the world).

We can't remove the prefix until the TTL on any record that includes the
prefix has expired (TTL + zone refresh time to be even more accurate),
that's for sure.   Though, of course we can, and people do that kind of
thing every day - it just breaks things for a while in mysterious ways
that just "fix themselves" eventually - but it is not good at all.

In general we're probably going to want to leave prefixes listed and
deprecated for even longer than required by DNS TTLs, so open connections
using the things can keep on working - but there's certainly a relationship
between the value of the TTL, and how quickly an address can (safely) go
away completely.

  | 	to help signing zone file with mixture of "A6 0" and "A6 x" (x != 0)
  | 	we at least need a better signing tool...

I have no doubt but that we need a whole bunch of all kinds of better
tools.   This doesn't surprise me in the least.   I would be the last to
claim that we're anywhere near being able to do quick renumbering today.
I just don't want to erect barriers that will prevent us from getting
there someday.  Software can be written and distributed to those who
need it (you have plenty of experience with that...)   But people's
operational habits are extremely hard to alter, as is getting someone
else to support something new because it will be easier for me (or you).

  | 	and again, zone signing cost analysis has to take a lot of things
  | 	into account,

Yes, but it isn't only signing costs that are relevant here (though they
are certainly one factor).  There's also how effective the DNS caches
are to be allowed to be.   That is, when you are planning to renumber
a common way is to reduce the TTLs on all the old records first, so that
when the change hits things won't be so affected by the "wait for old
records to expire" factor you referred to.  So, what is usually a one day
TTL might become a 30 minute TTL for the records to be changed.   (That
is going to require re-signing as well...)   Then when the change happens
the old addresses don't need to be kept around as long.

But of course, now all the DNS caches all over are fetching data from
the servers much more frequently than they used to - that's what we wanted
of course when the TTL was decreased, but it is an extra load on the net,
and longer delays for name lookups.   With just a few records with short
TTLs (the ones that contain the prefix, rather than all of those that refer
to the prefix) that problem ought to be able to be reduced, while still
reaping the benefits.

With IPv6's ability to have multiple addresses (with the effects of that
properly defined, etc) this probably isn't as big an issue as it could
have been - as it is OK if others keep using deprecated addresses to reach
us, so there should tend to be less "old address works until time N, after
that new address works" that usually happens with IPv4 renumberings.

kre

---

From: [email-masked]
Date: Thu, 14 Jun 2001 00:50:52 +1000

> So, what is usually a one day
> is going to require re-signing as well...)

	Actually you don't need to resign so long as the TTL stays within
	the original ttl value when the record was signed.  This property
	is required for caches and there is no reason why authoritative
	servers can't take advantage of it.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
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: "Matt Crawford" <[email-masked]>
Date: Wed, 13 Jun 2001 09:59:40 -0500

> , you really mean the minimum period (or duration) of renumbering,

Oh, but it would be!  What is the minimum frequency of renumbering
that would be required to keep routing functional with current BGP
technology and aggregation techniques?

Unfortunately, I don't think we have a good handle on the information
needed to answer this question.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------