Subject: RE: (ngtrans) draft-ietf-ngtrans-6to4-04.txt

From: Richard Draves <[email-masked]>
Date: Tue, 2 May 2000 17:00:17 -0700

> > I think of site-local addresses as being pretty similar to RFC 1918
> > addresses - would you disagree?
> 
> they look similar to me.  perhaps site-local addresses should 
> be deprecated?

Not by me - I think site-local addresses have great potential. First, for
disconnected sites. But more interestingly, to make site renumbering easier.
A connected site can use site-local and global addresses simultaneously,
using site-local addresses for internal communication & configuration. I
think this will make renumbering the site's global prefix much easier,
because there will be many fewer configuration files & databases that know
about global addresses.

Rich

---

From: Keith Moore <[email-masked]>
Date: Tue, 02 May 2000 20:08:06 -0400

site-local addresses might be fine for configuration purposes.
but if you're an application writer you want to be wary about using them.
in general, you want to avoid them unless you can be sure that they will 
not be used in any context other than your own site.
and you don't want a host to ever bind an application socket
to a site-local address by default.

Keith

---

From: Jim Bound <[email-masked]>
Date: Tue, 02 May 2000 22:49:31 -0400

>to a site-local address by default.

ACK to this.  Also DNS, DHCP, SLP, et al and many distributed banking
and manufacturing networking server applications should never use them.

/jim

---

From: Alain Durand <[email-masked]>
Date: Tue, 02 May 2000 20:19:09 -0700

Richard Draves wrote:>

> because there will be many fewer configuration files & databases that know

I partly disagree. If your topology does not change and you change ISP,
site local addresses may ease renumbering (although deprecating the old prefix
and
advertising the new one may be enough).

But another typical case is when 2 compagnies are merging and you want
to merge their 2 networks, there is a pretty good chance that both networks
were using the same SLA IDs, (say 0x0001, 0x0002,...) so you wil have conflicts

in site local /64 prefixes, and you will be forced to renumber...
If you were not using site local adresses but global adresses on both sites,
in that particular case, you would not have to renumber because the global
/64 prefixes would be differents.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 May 2000 09:27:59 -0500

> /64 prefixes would be differents.

Right. I see no reason to deprecate site-local, but we should start to consider
how to give globally unique prefixes to disconnected networks. All our experience
tells us that such networks *will* ultimately connect, and we still haven't
made renumbering painless.

Yes, I *know* what somebody is going to say about aggregation but if only very,
very large networks get their own prefixes this shouldn't be too big a concern.
And those are exactly the ones that renumbering hurts most, and are the most
likely to be seriously multi-homed.

   Brian

---

From: Greg Maxwell <[email-masked]>
Date: Wed, 3 May 2000 10:56:59 -0400 (EDT)

> made renumbering painless.

It should be emphisised that they need not connect to the Internet for any
form of private addressing to be a BIG problem. Just consider the simple
case of plugging into someone else.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 03 May 2000 10:02:10 -0700

Brian,

>likely to be seriously multi-homed.

I tend to agree.  Were you thinking about a mechanisms where any site could 
get a global prefix (perhaps use a TLA like 6to4) but that these prefix 
would never be routed on the Internet?  Similar rules to the site-local 
prefix, but everyone can get their own.  When the site does connect they 
get a new prefix and we make sure that the address selection rules pick a 
routable prefix when both types exist.

Or were you thinking about routable prefixes independent of an ISP allocation?

Bob

---

From: Thomas Narten <[email-masked]>
Date: Wed, 03 May 2000 13:20:54 -0400

> I tend to agree.  Were you thinking about a mechanisms where any
> site could get a global prefix (perhaps use a TLA like 6to4) but
> that these prefix would never be routed on the Internet?  Similar
> rules to the site-local prefix, but everyone can get their own.
> When the site does connect they get a new prefix and we make sure
> that the address selection rules pick a routable prefix when both
> types exist.

This scheme will only benefit those folks with the foresight to get
such addresses and then in addition not to use site-local
addresses. Would it be better to dust off the previous idea of putting
in some almost-random value in the left most bits of the site-local
prefix that would identify a particular organization? Those bits
should not overlap into the SLA bits and probably allow a couple more
bytes for post-merger routing heirarchy. If we needed even more
assurance that such addresses were likely unique, have a registry from
which folks could be assigned a specific site ID value that they would
use to put in their bits. Allocations are made first-come first-serve,
from a flat identifier space.

We could then have recommendations along the lines of:

1) leave the middle to left bits of site-local addresses zeros as they
   are now.

2) or pick a random value (and provide suggestsions on how to pick
   good values) for those who are worried

3) or get a properly assigned value, for those who really really
   worry.

Thomas

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 May 2000 13:45:01 -0400

> routable prefix when both types exist.

I started to suggest much the same thing...also making the mechanism
accessible via a web page, for free.  but I'm not sure how much it helps.  

It does get rid of the potential for address collisions when two 
sites using site-local addresses connect to one another.   (actually
if MAC addresses are used for the address suffix, the real problem is
more likely to be collisions in different uses of the "routing" bits 
of the site-local addresses than in the entirety of the addresses)

however when a site connects to the global Internet for the first time,
it doesn't matter whether it was using site-local addresses or 
globally-unique private addresses - it still essentially has to renumber.
so renumbering had better work well.

also, regarding address selection during renumbering - you can't count
on address-selection rules to choose the right prefix.  the host has
to know which address prefixes are in the process of being deprecated 
(and therefore must be maintained for existing connections) vs. which 
ones are available for use in new connections.  I think the same would
be true when "renumbering" from globally-unique private addresses to
public addresses (or vice versa, in case a site decided to disconnect...).
that is, address selection between globally-unique private addresses
and public addresses should not be based on the prefix alone but should
use the renumbering mechanism, and it should be explicit (dictated by the
network administrators) rather than implicit (based purely on the host's
knowledge of which prefixes are available).

There is a problem during the transition from disconnected to connected  
(or vice versa): since the same set of address prefixes might not become
visible to all hosts in the conversation at once, and since the 
globally-unique private address of a host might not be usable by all 
of the other hosts in that conversation, it is entirely possible that 
a host that is participating in a distributed conversation will choose 
an address for its connection endpoint which is not usable by all other 
hosts in that conversation.  When again argues for the transition to be
explicitly managed. 

Keith

p.s. I was tempted to suggest that ISPs could advertise routes for
globally-unique private addresses prefixes during a brief transition 
phase between initial connection to the Internet and the site's 
renumbering to use aggregatable addresses.  and of course ISPs can
do this if they want to.  but even if such routes were only advertised
for a few days, this could be really taxing of the network during 
periods where there are large numbers of new v6 nets being added.

problem is, folks who connect to the global IPv6 internet are going to
want it to start working right away.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 3 May 2000 16:39:12 -0700 (PDT)

> were using the same SLA IDs, (say 0x0001, 0x0002,...) so you wil have

Alain,

To be more exact the issue is when two sites are merging.
Thus it all depends on at what granulatity the two companies
define their sites. If each of them have been a single site before the merge
and they wish to be a single site after the merge there would be an
issue.

But if they have followed the loose recommendations on a site (a building or 
a campus) renumbering should only be needed if IP devices are actually moving
between buildings/campuses.

Of course, if the companies have chosen to have "one site for each Internet
connection" or "one site for the whole company even though it has
multiple internet connections" they there might be a collision space
for the site-local addresses.

However, in certain cases there can be similar "collision" issues with the SLA
field for global addresses.
If the companies have X/48 and Y/48 before the merge getting service from
two different ISPs, and they decide as part of the merge to only retain
one of the ISPs they have to fit all addresses under X/48.
If both companies used SLA 0, 1, etc they would need to renumber.

In any case, router renumbering can help with the task of any
renumbering needed to resolve conflicts as long as this is done
before the two networks are glued together.

   Erik

---

From: Alain Durand <[email-masked]>
Date: Wed, 03 May 2000 16:55:24 -0700

> If both companies used SLA 0, 1, etc they would need to renumber.

Agree, but in that case,  if they do not use Site Local addresses, they would
also have the option to keep both prefixes and do not renumber at all.
It is then a trade-off between carrying two prefixes or renumbering.

    - Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 3 May 2000 18:09:53 -0700 (PDT)

> > However, in certain cases there can be similar "collision" issues with the
SLA > > field for global addresses.
> also have the option to keep both prefixes and do not renumber at all. It is
> then a trade-off between carrying two prefixes or renumbering.

If the merged company terminates the relationship with the ISP that gave
them the Y/48 prefix I think the company might not be able to continue to use
that prefix. Or it might no longer be routed.

Of course, they can ask the ISP that gave them X/48 for an
additional prefix (W/48) and then renumber Y/48 into W/48.
Their success in doing so of course depend on the allocation policies
set by the registries and might be a function of how "densly" they are 
using the SLA field in the X/48 prefix.

The above details ois all speculation. But the point is that merging two
sites into a single site can cause conflicts both for the subnet field 
in site-local addresses and in some cases the SLA field in the global
address(es).

   Erik