Subject: (ngtrans) 6BONE AUP

From: Bob Fink <[email-masked]>
Date: Tue, 16 Feb 1999 17:51:57 -0800

Perry, Jim, Craig, Tony et al,

This will be a bit long winded, but hopefully worth it! 

(For the benefit of the 6bone and ngtrans list folk not on the
[email-masked] list, my "research and development AUP" comments about
the 6bone have been questioned.)

First, a brief bit of background on the 6bone. The 6bone was created by a
volunteer group of folk "to foster the development testing, and deployment
of IPv6". As some of the participants offerred to host end-site tunnels
and/or carry backbone traffic for those not in their normal user community,
I was sensitive about violating anyone's AUP.

Note that any mention of a research and development AUP was my choice (to
the best of my memory), not that of the early 6bone group (i.e., the ad hoc
meetings held at the IETF) or the current ngtrans group (which now includes
the 6bone activity). I have scanned all the minutes of 6bone meetings held
to date to refresh my memory (I may have passed over something, but doubt it). 

I've also included below the 6bone portion (which I wrote) of the ngtrans
charter:

"4. Coordinate deployment of an IPv6 testbed (known as the 6bone) to assist
in the following: 

- Creation of "practice and experience" informational documents that
capture the experiences of those who have deployed, and are deploying,
various IPv6 technologies. 

- Feedback to various IETF IPv6-related activities, such as the IPng WG,
based on testbed experience, where appropriate. 

- Feedback to various IPv6 product developers, based on testbed experience,
where appropriate. 

- Development of mechanisms and procedures to aid in the transition to
native IPv6, where appropriate. 

- Development of mechanisms and procedures for sharing operational
information to aid in transition and operation of global IPv6 routing."

There is no mention of either a production or non-production disposition,
nor of any specific AUP. It is a testbed that, as the first 6bone meeting's
goal statement said, is "to foster the development testing, and deployment
of IPv6".

I would also note that I have never had anyone (that I can remember) tell
me that my "research and development Acceptable Use Policy (AUP)" mattered
to them. I have had several say that as long as the traffic was low enough
that their own AUPs could accomodate production usage.

Now let's look at RFC 2471, the IPv6 Testing Address Allocation:

1.0 Introduction 

This document describes an allocation plan for IPv6 addresses to be used in
testing IPv6 prototype software. These addresses are temporary and will be
reclaimed in the future. Any IPv6 system using these addresses will have to
renumber at some time in the future. These addresses will not to be
routable in the Internet other than for IPv6 testing.
...

2.0 Address Format

TLA = 0x1FFE = Top-Level Aggregation Identifier 

This is a TLA ID assigned by the IANA for 6bone testing under the auspices
of the IETF IPng Transition Working Group 6bone testbed activity. It is to
be administered by the chair of the 6bone activity (currently Bob Fink
<[email-masked]>). The use of this TLA ID is temporary. All users of these
addresses in this TLA ID will be required to renumber at some time in the
future.

Again, no mention is made of any type of AUP. The biggest worry I see here
is that eventually we may have to renumber, and somehow I doubt that this
will be a real problem as long as the 6bone is serving a purpose.

So I conclude that I'm being overly conservative in how I speak of this in
print. IMO, if a 6bone pTLA or pNLA transit is concerned with the nature of
IPv6 6bone traffic they carry, they will take appropriate steps of their
own, and certainly not ones dictated by me.

The conclusion of this is that I will simply remove the mention of a
research and development AUP. In fact it is gone as you read this!

I would also encourage everyone to review any and all of the 6bone pages
and recommend better wording, restructuring etc. We are all in this
together and there are limits to whay one person can do.

Thanks,

Bob

---

From: "Perry E. Metzger" <[email-masked]>
Date: 16 Feb 1999 21:03:03 -0500

> research and development AUP. In fact it is gone as you read this!

<insert sound of applause here!>

> will be a real problem as long as the 6bone is serving a purpose.

I think renumbering will not actually be an issue so long as it
happens with warning and slowly enough. My guess is it will happen
"naturally" anyway -- as providers start giving customers "real"
numbers from their provider based CIDR blocks, people will leave the
v6-over-v4 universe and "number out" on their own. If it takes five
years to get past this stage, so be it, the numbers will eventually
go, and if we are down to a handful of stragglers we can just cut them 
off at some point someday.

Perry

---

From: Jim Bound <[email-masked]>
Date: Wed, 17 Feb 1999 11:05:57 -0500

Once we get the router renumbering spec from Matt implemented just as a
note renumbering a site with IPv6 will be a no brainer.  I hope we see
UNH Labs doing router renumbering Interoperability testing for router
renumbering and DHCPv6 by this summer.  So as we come up with transition
TLA thingees to run IPv6 on top of the Internet when folks have to
renumber their IPv6 space it will automatic.

The one piece missing is the downstream ISP to Subscriber prefix
update/assignment is not specified in a protocol but will have to be
either started by the edge routers after the new prefix is entered or
via a DHCPv6 server at the ISP where we can provide an ISP to
subscriber start renumbering DHCPv6 Extension.

So I too am not concerned about changing IPv6 prefixes and such and we
should probably force such testing soon.

/jim

---

From: "Louis A. Mamakos" <[email-masked]>
Date: Thu, 18 Feb 1999 09:01:04 -0500

If you really want to demonstrate a compelling reason for ISPs and users
to begin to deploy IPv6, then I think the 6bone should renumber all the
sites on a regular basis.  It should be "automatic" (modulo DNS
issues to some extent).  Do this, say, once per month to make sure
this capability *really* *really* works well.

louie

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Feb 1999 06:53:05 -0800 (PST)

> this capability *really* *really* works well.

thank you.

randy

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 18 Feb 1999 10:07:20 -0600

Louie sez ...
> sites on a regular basis.

I used to say this when the 6bone was first forming.  It may be just
about time to say it again, eh?

One part of renumbering which hasn't been tackled, though, is
updating filter lists (aka access lists) on routers.  There are
probably some 6bone BGP filters in place here and there which would
take small but non-zero effort to update with each renumbering.
Ideas, anyone?
					Matt

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Feb 1999 17:45:29 +0100

>take small but non-zero effort to update with each renumbering.

They are other places where IP addresses are burried deep.
For example, we use some expensive software controled
by a license server. The server needs a key to operate,
and this key is derived by the software vendor
from... the license server IP address!!!
So each time the server change it's IP address, we have
to go to this specific software vendor to get a new key.

I suggest we try to make a list of some "well known" places
where IP addresses are buried.

On routers:
- Access list (firewall)
- BGP filters

On servers:
- DNS (many places)
- keys for license servers
- ntp configuration file
- /etc/networks ???

On client hosts:
- DNS server address (if not using DHCP)

There is probably more to this.

	- Alain.

---

From: [email-masked]
Date: Thu, 18 Feb 1999 08:48:27 -0800 (PST)

Most of these places are documented in old PIER drafts.

-- 
--bill

---

From: "Perry E. Metzger" <[email-masked]>
Date: 18 Feb 1999 12:15:57 -0500

> take small but non-zero effort to update with each renumbering.

The trick is always another layer of indirection. The DNS has provided 
good names for hosts. What we need is a way to name CIDRized blocks of 
addresses cleanly, so that the configurations can use names which
today point at the old addresses and tomorrow point at the new...

Perry

---

From: Jim Bound <[email-masked]>
Date: Thu, 18 Feb 1999 12:25:11 -0500

bill,

might be good to point us to those drafts I can't find them?

sounds like this should be one topic for our deployment meeting at
Minneapolis?

I think if we can folks to implement the router renumbering draft
quickly we can start testing this as louie suggested.  We would need for
now the root servers to dynamically update the DNS for ip6.int and AAAA
top zone records before it begins and each IPv6 Host on the network
would have to support dynamic updates to DNS in their addrconf code on
the LANS once the new RAs giveout the new prefix.  This means we want a
a means to make sure deprcated state exists during the renumbering
operation. 

One of the problems for the 6bone will be all are connected by tunnels?

So one of the triggers will have to be a RR packet over the tunnels to
the routers at the 6bone points of entries.

The 6REN will be a better and more realistic test because hopefully we
will have real IPv6 nodes behind that native IPv6 network.

This will also test the heart of the addrconf mechanism in a big way
too in addition to what UNH IOL test suite does.

But we need commit from router and host/router folks to commit to doing
the RR spec?

thanks
/jim

---

From: "Louis A. Mamakos" <[email-masked]>
Date: Thu, 18 Feb 1999 12:12:06 -0500

I think that the notion of the 8+8 addressing scheme proposed awhile ago
addresses some of these issues.  There is a "local", invarient part of
the address that silly things like license manages should/could use,
and other bits that are oriented to transporting the traffic to you.

> From: Alain Durand <[email-masked]>
> Date: Thu, 18 Feb 1999 17:45:29 +0100
> To: IPv6 Deployment List <[email-masked]>,
> To: 6BONE List <[email-masked]>,
> To: [email-masked]
> Subject: Re: (ngtrans) Re: 6BONE AUP 
>

Louis A. Mamakos                                  [email-masked]
Director, Global Strategic Technology
UUNET, an MCI WorldCom Company                    Voice: +1 703 206 5823
3060 Williams Drive                               Fax:   +1 703 206 5601
Fairfax, VA    22031-4648

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Feb 1999 10:08:18 -0800 (PST)

> today point at the old addresses and tomorrow point at the new...

so, to make my router route, i need to look things up in the dns, which
requires routers to be working.  clearly i am misunderstanding you.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Feb 1999 08:33:05 -0800 (PST)

> take small but non-zero effort to update with each renumbering.

we update all changed acls nightly.  the process is automatic from our
internal routing database and the irr.  there is a manual approval check,
of course (in fact, as we are a bit of a distributed company, it involves
complex email certs to multiple regions).

the problem here would be micro-timing.  but there seem to be a bunch of
micro-managers looking for jobs these days. :-)

randy

---

From: "Michael P. Burton" <[email-masked]>
Date: Thu, 18 Feb 1999 14:28:47 -0800 (PST)

I'm awefully new to the IPv^ ballgame, but isn't there leeway for
dual-homing on the same interface to ease transition from one
prefix to another?

On 18 Feb 1999, Perry E. Metzger wrote:

|
|"Matt Crawford" <[email-masked]> writes:
|> One part of renumbering which hasn't been tackled, though, is
|> updating filter lists (aka access lists) on routers.  There are
|> probably some 6bone BGP filters in place here and there which would
|> take small but non-zero effort to update with each renumbering.
|> Ideas, anyone?
|
|The trick is always another layer of indirection. The DNS has provided 
|good names for hosts. What we need is a way to name CIDRized blocks of 
|addresses cleanly, so that the configurations can use names which
|today point at the old addresses and tomorrow point at the new...
|
|Perry
|

_____________________________________________________________________
Michael P. Burton                                         Member:DNRC

---

From: "Perry E. Metzger" <[email-masked]>
Date: 18 Feb 1999 17:40:27 -0500

> dual-homing on the same interface to ease transition from one

1) If I add a new prefix in, do I want my filter rules to not apply to 
it, or for it to be blocked by accident?
2) If I add a new prefix in, do I want to burn personel time dealing
with the event?

Perry

---

From: "Michael P. Burton" <[email-masked]>
Date: Thu, 18 Feb 1999 14:55:07 -0800 (PST)

|"Michael P. Burton" <[email-masked]> writes:
|> I'm awefully new to the IPv^ ballgame, but isn't there leeway for
|> dual-homing on the same interface to ease transition from one
|> prefix to another?
|
|1) If I add a new prefix in, do I want my filter rules to not apply to 
|it, or for it to be blocked by accident?
|2) If I add a new prefix in, do I want to burn personel time dealing
|with the event?
|
|Perry

Well, if it were plug-n-play, then we would all be out of a job, 
wouldn't we? (laugh) Seriously though - I guess it would be the
network admin's job to keep very specific notes on the usage of
access-lists (and other ip number dependent resources) and be
able to make the needed changes in a matter of hours. Another solution
might be a way to "push" new access-list information out to all
routers from an authorative-router. Of course, that would have to rely
on the AH and ESP headers to guarentee no wrong-doing was done...

---

From: "Perry E. Metzger" <[email-masked]>
Date: 18 Feb 1999 18:21:02 -0500

"Michael P. Burton" <[email-masked]> writes:
> able to make the needed changes in a matter of hours.

No. That's really unacceptable. It is fine to automate something like
this and say "the solution is automation" (AFTER you demonstrate said
automation), but it is *not* fine to say "the solution is burning
human cycles". If that is the solution, then we'll never be able to
renumber. There are companies with tens of thousands of machines and
huge numbers of clueless managers. If they spend six hours every week
renumbering, they'll kill us all. More importantly, they'll block the
moves to renumber, which will destroy the whole flexibility the system
is supposed to have.

Perry

---

From: "Michael P. Burton" <[email-masked]>
Date: Thu, 18 Feb 1999 15:33:00 -0800 (PST)

|"Michael P. Burton" <[email-masked]> writes:
|> |2) If I add a new prefix in, do I want to burn personel time dealing
|> |with the event?
|> 
|> Well, if it were plug-n-play, then we would all be out of a job, 
|> wouldn't we? (laugh) Seriously though - I guess it would be the
|> network admin's job to keep very specific notes on the usage of
|> access-lists (and other ip number dependent resources) and be
|> able to make the needed changes in a matter of hours.
|
|No. That's really unacceptable. It is fine to automate something like
|this and say "the solution is automation" (AFTER you demonstrate said
|automation), but it is *not* fine to say "the solution is burning
|human cycles". If that is the solution, then we'll never be able to
|renumber. There are companies with tens of thousands of machines and
|huge numbers of clueless managers. If they spend six hours every week
|renumbering, they'll kill us all. More importantly, they'll block the
|moves to renumber, which will destroy the whole flexibility the system
|is supposed to have.
|
|Perry

If they have to spend six hours a week renumbering, then there is probably
another major issue to be looked at that they are willing to kill us over.
The whole access-list issue is a difficult one because from my
understanding, IPv6 dosn't deal with it; it is propitary tech. I'm sure
Cisco could come up with a solution for their routers, but if you are
dealing with different kinds of routers, you are going to be pretty hosed.
But admins are going to need to be able to change their addresses on an
"as-needed"  basis, hopefully less than once a year. Do you have a
proposed solution to this issue?

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Feb 1999 15:52:00 -0800 (PST)

Michael P Burton <[email-masked]>
> I'm sure Cisco could come up with a solution for their routers, but if you
> are dealing with different kinds of routers, you are going to be pretty
> hosed.

at least three of the five largest isps in the states use both ciscos and
junipers.  at least two of us, and likely all large isps, load acls nightly.
those of us in the multi-vendor world know how to deal with it.

as i said earlier, the hard part with me the sync in time. i.e. load when
renumber.  flag minutes do not sound like fun.

if deployment is such that ipv6 does not renumber VERY easily, ipv6 is gonna
have a marketing problem to dwarf today's "ipvwhat?"

randy

---

From: Pedro Marques <[email-masked]>
Date: Fri, 19 Feb 1999 00:22:49 -0800 (PST)

>>>>> "Perry" == Perry E Metzger <[email-masked]> writes:

    Perry> No. That's really unacceptable. It is fine to automate
    Perry> something like this and say "the solution is automation"
    Perry> (AFTER you demonstrate said automation), but it is *not*
    Perry> fine to say "the solution is burning human cycles". If that
    Perry> is the solution, then we'll never be able to
    Perry> renumber.

I've to confess i've always found the discussions about renumbering
"interesting"... specially since people often refuse to quantify what
should be renumbered. Since the costs of such operation depend on the
position on the topology of what you are trying to renumber that has
always sounded to me that ipv6 will do renumbering at all costs.  From
an engineering point of view, which is basically the "art" of making
tradeoffs, that sounds odd. As if we had taken "renumbering" as a
buzzword without looking at the implications.

But let's not discuss if renumbering is, or rather when it is, a good
idea.

The major implication of renumbering is that you can't consider
addresses as identifiers of the objects but instead you must have
another handle for those objects.

Thus, you must have a way to resolve objects into addresses. Which is
fine for most purposes but becomes a real problem when you think about
the infrastructure that is involved in that resolution. A router, for
instance, is typically involved in such process. As such, it's
configuration has to be already "resolved". For instance you fall into
trouble really fast if you try to resolve a router's policy in terms
of objects (dns names or what-have-you).

Assuming we agree that a router's policy should be "resolved" and specified
in terms of addresses (which i believe we do from the router
renumbering efforts i'm aware off) there are basically two ways to go
about solving the resolution problem.

1) Notify all the dependents of an object->address mapping of any
changes in such mapping.

2) Express the router's policy in terms of objects off-line and
periodicly resolve the mappings and feed the resolved policies to the
router.

My humble opinion is that 1 is basically an untractable problem (and
curriously the aproach that has been given more consideration so
far). Number 2 is basically the aproach used by a reasonably large
network this days... but it is an aproach that is fairly limitative if
carried all the way and that requires quite a shift in paradigm.

regards,
  Pedro.

btw: just in case you need to be reminded, the opinions expressed
above reflect my own personal opinions only and not those of my
current employer.

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 19 Feb 1999 09:38:28 -0600

Please, let us restrict this discussion to fewer lists.  I dropped
6bone from this reply.

> proposed solution to this issue?

He (Perry) already suggested one: a standardized naming scheme for
prefixes.  This would help each vendor implement a workable scheme
without getting lynched by their mixed-vendor customers.

				Matt

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Feb 1999 17:28:35 +1100

Date:        Thu, 18 Feb 1999 15:33:00 -0800 (PST)
    From:        "Michael P. Burton" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The whole access-list issue is a difficult one because from my
  | understanding, IPv6 dosn't deal with it; it is propitary tech. I'm sure
  | Cisco could come up with a solution for their routers, but if you are
  | dealing with different kinds of routers, you are going to be pretty hosed.

We don't need to define a scheme that works for cisco (or anyone else's)
routers, but to provide the mechanisms that the router vendors can use to
incorporate into their products.   Right now (as Perry pointed out) there's
no good way to say "SMTP from a uunet dialup address is disallowed",
other than to discover (somehow) the IP address ranges concerned and block
them explicitly.   Because of that, access lists are almost exclusively
written using IP addresses (or IP addresses and masks).   If we can provide
the mechanism to allow such things to be named, we can then lean upon the
vendors to support building access lists from names instead of numbers
(and if we & they do it right, the translations will contain TTLs and
the access lists will be automatically updated as the addresses alter).

  | But admins are going to need to be able to change their addresses on an
  | "as-needed"  basis, hopefully less than once a year. Do you have a
  | proposed solution to this issue?

Note the problem with access lists (and the reason I assume Matt raised it)
is that it isn't my address changes that are of immediate concern.   It is
that other guy's address changes that matter - if uunet decide (or are forced)
to reassign addresses to their dialup customers, then I have a bunch of access
lists I need to update.   This is not a new problem for IPv6, it is just likely
to become more importantthere, as renumbering is likely to happen much more
often (and yes, quite possibly much more often than once a year).

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Feb 1999 22:01:03 +1100

Date:        Fri, 19 Feb 1999 00:22:49 -0800 (PST)
    From:        Pedro Marques <[email-masked]>
    Message-ID:  <[email-masked]>

  | 2) Express the router's policy in terms of objects off-line and
  | periodicly resolve the mappings and feed the resolved policies to the
  | router.

This is way too much over specified into implementation detail.

Eg: consider a "routing system", consisting of a traditional router, and
a general purpose host in a box connected to the router over one of its
local net internaces (or any other way).

Let the host be the thing that does the resolving of the mappings, and
the feeding to the router.   That seems like it would fit your model, it
might even be yourintent, and certainly seems like it is a way
that could work.

Now let us notice that the particular router in question is in a big box,
and has a big power supply, and that we don't really need quite a lot of
the associated peripherals for the host for this particular purpose, so
let's move the host processor, and net interface inside the router's big
box.   This is just a matter of packaging, so this can't make a difference
to the model.

Now let's avoid the unnecessary net interface by connecting the host that
is in the box anyway to the router's backplane - a bunch of hardware glue
is needed there, but the model doesn't change.

Now let's notice that we have this fairly general purpose host sharing
backplane access with the router, so let's decide we can also use that
as the the "user interface" into the router - sinking telnet connections,
handling SNMP queries, ... getting the info it needs into and out of the
router as it needs over the backplane.   As I see it, the model still
hasn't changed.

Now let's decide that miniaturisation is the way to go, and build the router
and the host onto a single motherboard, and mount it all in a much
smaller box.  The model surely hasn't changed - but now by any common
perception we have the router doing its own resolving of names into
addresses/masks - and nothing that looks at all off-line involved at all.

Which of these mechanisms any particular router vendor decides to implement
is, of course, entirely up to it - we ought not be attempting to
specify the mechanisms by which it is done.  All that is important is
that it actually be done, somehow, by someone, so users are not left
configuring using IP addresses (and for access lists, filter specs, or
whatever, this is almost as important for v4 as for v6).

kre

---

From: Steve Deering <[email-masked]>
Date: Fri, 19 Feb 1999 23:33:28 -0800

Here is a message I just sent to a different bunch of people who are
discussing the policies for IPv6 address allocation, but it is also
relevant to some of the topics currently being discussed here.

-------

Let's get something straight:

    The designers of IPv6 *never* promised to make renumbering painless
    and *never* claimed to have succeeded in making renumbering painless!

What we did promise to do, and what we have done, is *reduce* the pain of
renumbering.  In particular, the Neighbor Discovery protocol enables
automatic renumbering of the IP layer in hosts; the Router Renumbering
protocol enables the automatic renumbering of the IP layer in a site's
internal routers; and the proposal for A6 records in the DNS enables the
automatic renumbering of a site's DNS entries.

Automating the renumbering of the IP layer and DNS entries for a site's
nodes does *not* "solve the renumbering problem".  There are many other
places where IP addresses and/or prefixes are held, such as in transport
protocols like TCP, applications built on top of UDP, tunnel configuration
files, application software licence servers, firewall filters, URLs, and
on and on (see archives of the pier working group for more examples).
In many of those cases, the use of IP addresses is completely justified
and cannot be eliminated by simply saying "use DNS names instead"; for
example, firewall filters cannot simply use DNS names, because DNS
names are not present in every packet that a firewall must filter.
Furthermore, some of the places in which a site's IP addresses or prefixes
may be stored are not under the control of (or even known to) that site,
for example a site's prefix may well be present in any number of other
sites' firewall filters, and a site may well have tunnel endpoints whose
addresses are in configuration files within other sites or ISPs.

Yes, there are various ideas and proposals for how to eliminate *some* of
those uses of IP addresses, but they are mostly still at the hand-waving
stage, and the bedeviling details are far from being worked out.  And
the fact is: we do not know, and cannot know, all the places where IP
addresses are currently being used for mission-critical purposes outside
the IP layer of hosts and routers.  After all, the existence of globally
unique, relatively stable addresses is a fundamental property of the
original IP architecture, and nobody knows how many applications and other
upper-layer protocols depend upon that property being true.

(Aside: I believe that the existence of globally unique, relatively stable
addresses is an essential part of what makes -- or, rather, made -- IP
simple, robust, and manageable, just like globally unique, relatively
stable phone numbers are essential to a workable phone system, and
globally unique, relatively stable street addresses are essential to a
workable postal system.  Removing the stability property [or the global
uniqueness property] of IP addresses is bound to lead to a system that
is more complex, more fragile, and less manageable, and those costs need
to be weighed against the benefits of the change, and against the costs
of retaining the property.  The old computer science aphorism that "any
problem can be solved by adding a level indirection" is false; all that
another layer of indirection does is convert one problem into one or more
different problems, which may or may not be more palatable than the
original problem.)

The fact that IPv6 has not completely "solved" the renumbering problem
is not evidence of "false advertising" on the part of IPv6 advocates,
since we never claimed otherwise.  That accusation seems to spring more
from folks who thought (hoped?) automatic renumbering would just be "a
small matter of protocol design", but who never showed up at IPv6 working
groups meetings or mailing list discussions to explain to us idiots
exactly how to do it.  (The one exception is Mike O'Dell, whose 8+8
proposal was a serious effort to find a solution, and for which the
working group convened a special two-day workshop to study it in depth.
At the end of the workshop, Mike himself concluded that the ramifications
of his proposal were worse than he had hoped, and we had to settle for
adopting only some of the good ideas in 8+8, and not whole thing -- in particular, not the part that would make renumbering invisible to hosts.)

I believe:

	(1) renumbering will always be painful,
	    for at least some customers in some circumstances

	(2) renumbering will always be necessary,
	    for at least some customers in some circumstances

(1) implies we should look for ways to *reduce* the number of circumstances
    in which -- and the number of customers for which -- renumbering is
    required.

    (One example would be to give more serious consideration to metro-based
    or other exchange-based addressing, which could make many common cases
    of changing service providers *not* require changing address prefixes).

(2) implies we should continue to work on mechanisms and procedures that
    reduce the pain of renumbering.

    (So, no, it is not the case that work on renumbering support in the DNS
    is "wasted" if we don't impose frequent renumbering on IPv6 customers.)

Arguments that we should do frequent, gratuitous renumbering in the
operational IPv6 Internet just "to make sure it works" are specious,
because (a) we *know* it will impose not-easily-remedied hardship on some
customers, and (b) it is much more than is needed to test the renumbering-
support protocols -- there will be plenty of customers who will have to
renumber for their own reasons (like changing providers), so we will get
plenty of "tests" of the renumbering mechanisms without having to subject
*all* customers to those tests.

Though I believe it is very important to try to avoid forcing customers to
renumber, I do agree that we have to be very clear that a customer does
not "own" the IPv6 address space delegated to them (nor do the ISPs, nor
do the registries, for that matter).  We have to be able to reclaim and
reallocate abandoned address space, and to replace an existing delegation
with a different delegation if a serious technical need to do so arises.
Perhaps the notion of "leases" is the right way to accomplish that, but
it seems to me that the phone system has managed to avoid this problem
without introducing the notion of leases, at least as far as the end
customer is concerned -- I have never been under the illusion that I own
my phone number, but I don't think of myself as "leasing" it either.
I know that I can't take it with me when I move to a different city, and
that my phone company can force me to renumber (which it recently did
when it moved me into a new area code), and that I can lose it if I stop
paying my phone bills.  But I also expect the phone company to make an
effort *not* to make me change my phone number without a damn good reason
and a lot of advance warning, because I incur a lot of hassle and expense
whenever it changes.  And the phone companies know that the more stable and
more portable they can make phone numbers, the happier their customers will
be (and the less likely to take their business elsewhere, now that there
are starting to be alternatives).

(Don't bother telling me that IP addresses are different from phone
numbers because we don't put our IP addresses on our business cards and
stationary and in other people's Palm Pilots and so on.  I know that.
The specific costs of changing phone numbers are different than those of
changing IP addresses, but in both cases there may be significant costs.)

As someone else pointed out, as far as the end IPv6 customer is concerned,
paying their monthly ISP bill ought to be sufficient to "renew their lease"
on the prefix obtained from that ISP (or from the exchange in which the
ISP is participating).  Requiring the ISPs to send an annual or bi-annual
reconfirmation to the registries reporting that they are still using their
delegated space sounds reasonable to me.  Perhaps the registries should be
required to send similar reports to IANA as well, so we can garbage-collect
space allocated to defunct registries some day.

So let's do whatever is minimally necessary to make sure that all entities
understand/acknowledge that they do not own any IP address space that is
delegated to them, and that engineering requirements *may* require them
to swap those delegations for other delegations at some point.  But we
should also recognize that renumbering will continue to have non-negligible
and sometimes very significant costs for at least some customers for a
long time to come, and therefore the registries and ISPs are responsible
for *avoiding* unnecessary renumbering whenever possible, and for giving
plenty of advance warning and overlap time between old and new delegations,
in those cases where renumbering is unavoidable.

(And to address a specific point in the registries' draft allocation policy
document: keeping the backbone routing table size under 8K routes instead
of 16K routes is emphatically *not* sufficient reason to force the huge
number of customer renumberings that would be required if an ISP were
required to give up its subTLA when it grew big enough to warrant a
full TLA, given that a 16K routing table is well within current technical
capabilities.)

Steve

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 22 Feb 1999 12:19:51 +0100

At 17:28 19.02.99 +1100, Robert Elz wrote:
  If we can provide
>the access lists will be automatically updated as the addresses alter).

Doesn't the A6 record have about the right format to do the job?

              Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Feb 1999 22:38:23 +1100

Date:        Mon, 22 Feb 1999 12:19:51 +0100
    From:        Harald Tveit Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

  | Doesn't the A6 record have about the right format to do the job?

As an RR, yes, it could serve probably (I have not thought about that
a lot - an RR to convey the information is about the least of the issues
to work out).

What's more important to figure out is just what information needs to be
conveyed, to whom, and when.

Pedro Marques and I engaged in a short exchange about all of this over
the weekend - the result was a message which could conceivably be turned
into an I-D in one of ngtrans, ipngwg, or even pier if it still exists.
I am waiting to hear from the chairs of those groups whether there is
any interest.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 23 Feb 1999 00:16:11 -0800 (PST)

Randy,

> renumber.  flag minutes do not sound like fun.

Depends how much time you have.
For instance in managed renumbering you want to have enough overlap between
adding the new prefixes and retiring the old so that 1) existing tcp
connections finish up, 2) reduce likelyhood of the old addresses still being
cached in applications or DNS resolvers that don't honor ttl.

If the time span ends up being 1 week of overlap you can sequentially do:
1. Add new prefix to access lists.
2. Propagate the new prefix to site/routers using RR.
3. Wait N days
4. Time out the old prefix using RR.
5. Remove old prefix from access lists.

Thus the question becomes: how often will the renumbering events occur in
less than approx 24 hours with the expectation of no disruption in service?

  Erik