Subject: RE: globally unique site local addresses

From: "Michel Py" <[email-masked]>
Date: Mon, 25 Nov 2002 10:19:55 -0800

Charlie,

> Charles E. Perkins
> Agreed on all points.  I take your point about
> discussion time to mean that we should not get
> into a situation where a simple solution would
> be blocked while a solution with more features
> is devised. The feature set should be simple
> enough to be proposed and agreed upon right
> away.

Your proposal makes a lot of sense to me and I will support it. I will
try to sneak mine in as a complement to yours. If it takes too much time
or does not reach consensus I'll withdraw it. I would suggest to reserve
a handful of /16s out of FEC0::/10 for future use in any case.

Let me emphasize again that none of this stuff goes anywhere is there is
no default enforcement of non-routability along the lines that Bob
Hinden, Christian Huitema and myself have contributed, and I have not
heard many comments about that part.

I guess I'll try to convince on this geo GUPI thing until we have
consensus on non-routability.

About my proposal of using geography to allocate globally unique
site-locals instead of Charlie's sequential, it does not bring anything
to the table sort-term, but it could in the longer term.

It all boils down to someone wanting to undertake allocating them
according to:
http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt

I personally think that RIRs should be involved in this, but are there
any other takers?

Michel.

--------------------------------------------------------------------
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: Tim Chown <[email-masked]>
Date: Mon, 25 Nov 2002 23:52:46 +0000

> heard many comments about that part.

Indeed.  I'm a little confused that GUPI = site-local, nothing really new
only we're (in PekkaS's method) just "randomising" which site-local is used,
so all the bad things of site-locals remain (which I'm sure Keith *could* 
remind us of :)
 
Tim

---

From: Mark Smith <[email-masked]>
Date: 26 Nov 2002 11:24:25 +1100

> > heard many comments about that part.

I would suggest everybody generally understands and agrees with the
default enforcement of GUPI non-routability contributed by Bob,
Christian and Michel. Silence is probably agreement.

> so all the bad things of site-locals remain (which I'm sure Keith *could* 

Not all the bad things remain - the key bad thing that has been
eliminated by the new GUPI models is muli-site site-local addressing
ambiguity.

Merging networks (which includes creating VPNs) was a hard problem with
traditional site-locals, with the new GUPI models it is no problem or at
least a very rare problem.

By the fact that Keith has sent one or two emails on this topic, but not
anymore than that, tends to suggest that most if not all his objections
to traditional site-local addressing have also been addressed to an
extent by the new GUPI models - or maybe it's just that his keyboard
broke :-)

Mark.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 20:04:11 -0500

> extent by the new GUPI models

I've been saying for months (at least) that we needed site-specific 
globally unique addresses, so I'm not likely to object to them now.  :)
--------------------------------------------------------------------
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: Andrew White <[email-masked]>
Date: Tue, 26 Nov 2002 17:41:19 +1100

Some thoughts:

As a method of doing globally unique site local addressing:

Assuming aggregability is not an issue within a 'site' sized network,
consider generating site local subnet identifiers at the router, based on
IEEE EUI-48 identifiers (such as MAC addresses).

For example, generate as fec0::/12:

12 bits: fef
48 bits: MAC
 4 bits: 0 or subnets

or, if we don't want them in fec0::/10

10 bits: fe0
48 bits: MAC
 6 bits: 0 or subnets

The '0 or subnets' is to allow for the possibility of choosing one EUI-48 on
a router and using that to allocate all appropriate subnets.

By piggybacking on the existing registration scheme, we generate "unique"
site-local subnet ids at the router without needing external registration or
administration.

Despite the zero-config nature of this, administration on the router is
still necessary, both to enable this mode (probably don't want site-local
behaviour enabled by default) and to determine whether a router is
authoritative for the link.  An administrator may wish to configure a
multi-router link with the subnet prefix of only one router.

An internet-draft describing this in more detail is written and will be
submitted in the next day or so.  Comments welcome.

Another comment on uniqueness:

Under IPv6, even an ambiguous prefix is likely to not resolve to an address
because of the MAC generated machine id, so the likelihood of collision is
lower than might be expected from the prefix.

Final thought:

Whatever the outcome of the site local discussions, renumbering will remain
a serious problem under IPv6, that needs to be considered.  Making
renumbering easier is a hard problem, but a good solution will help reduce a
variety of other problems.

-- 
Andrew White                [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Nov 2002 10:42:50 +0100

In a word: no. We mustn't generate prefixes longer than /48, since
everybody will be designing 16 bit subnet addressing plans. It isn't
acceptable to have different subnet addressing plans with site local
and global prefixes.

  Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 11:13:19 -0500

For the sake of completeness:

Another idea I heard last week (sorry, I forget who suggested it)
is to use the number of seconds since some epoch (say 2002.01.01 0000 UTC)
when the network was established, as the probably-unique prefix.  

Though I do wonder whether we might see multiple networks automatically
"turned on" at the same "round number" time, causing collisions.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Nov 2002 08:56:53 +0100

I can't imagine operating two different subnet addressing plans
within a given organisation, just because I have two different
prefixes. Operationally and administratively, that would be a
nightmare.

And I can't imagine, in a 128 bit address space, being
limited to less than 16 bits to design my subnet addressing plan,
in a large organisation with hundreds of physical sites.

So I am unconditionally against any scheme that generates prefixes
longer than /48.

   Brian

Aidan Williams wrote:
> Brian E Carpenter wrote:
> > everybody will be designing 16 bit subnet addressing plans.
> 
> My understanding is that the /48 is intended to facilitate
> renumbering by notionally swapping the old prefix with the
> new one.
> 
> I don't see that this directly applies to site local because
> the notion of swapping out site local prefixes for a global
> prefix doesn't make sense to me.
> 
> Once, people may have thought IPv6 would be deployed first
> with site-locals and then people would lay their globals over
> their site-local addressing plan.  Is that realistic today?
> I have just gone straight for globals using 6to4 and I want
> site-locals because my 6to4 addresses are not as stable as
> I would like.
> 
>  > It isn't
> Why not?  The address format proposed below doesn't need an
> addressing plan and will work in parallel with an aggregetable
> unicast addressing plan.
> 
> - aidan
> 
> >   Brian
> >
> > Andrew White wrote:
> >
> >>Some thoughts:
> >>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Nov 2002 09:02:52 +0100

> "turned on" at the same "round number" time, causing collisions.

Well, it's a one-off function ("get me a prefix now!") that never needs
to be repeated, and doing it automatically at a set time would indeed be
a MUST NOT. But apart from that I like the idea - if we did it in a 38 bit
field under FEC0::/10 it takes a few thousand years to wrap, it doesn't
need a seed like a random number generator, and it's free.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
--------------------------------------------------------------------
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: Andrew White <[email-masked]>
Date: Thu, 28 Nov 2002 15:37:40 +1100

> So I am unconditionally against any scheme that generates prefixes

Maybe I'm missing the point, but isn't the assumption of a /48 addressing
scheme that you'll proceed to apply a second scheme to extend those /48
prefixes to /64 prefixes per link?  Ergo 64 bit subnet prefixes?

I'm just bypassing the middleman and saying 'within our site, let's just
allocate subnets using a flat 50+ bit addressing scheme, based on router
EUI-48s'.

So, the SUBNET prefix has three parts (using fef::/12 as example):

12 bits: 'fef' - common identifier
52 bits: subnet id

Of the 52 bits of subnet ID, the first 48 come from an EUI-48 on the router,
and the remaining 4 are there in case the router doesn't want to use one
EUI-48 per interface.

This is the subnet prefix that is advertised in the routing tables and to
hosts on the link.

> in a large organisation with hundreds of physical sites.

I'm proposing to give you 54 bits of subnet addressing plan, but I'll do the
allocation for you and guarantee its globally unique to boot.

> prefixes. Operationally and administratively, that would be a

Well, IF you want to use this in parallel with another scheme then you will
have to configure things like DNS with two sets of information - one for the
automatically allocated subnets and one for the manual ones.  But you'll
have to do this anyway, even if the two addressing plans are identical at
the low end.

Cons:

- Largely unaggregable - must have individual route for at least each
router.  (Should be able to aggregate links common to a router).

- Flat subnet scheme using large amount of address space.  Can't use scheme
for global addressing (for example).

[Actually, we could use this for global addressing, except for the
aggregability issue.]

- Some tweaking required when swapping out one router and in another, if you
want addresses to not change.

Pros:

- Globally unique subnet addresses.

- Factory configurable.  No further registration or allocation needed.

- Can work easily in parallel with fully administered addressing schemes.

- Fixed and deterministic.  Unless you move or manually reconfigure
something, the addresses won't change.  Ever.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Nov 2002 00:03:57 -0500

I'm pretty much opposed to prefixes other than /48 also.  It's really
much more difficult to renumber a site if the old and new prefix lengths
are different.
--------------------------------------------------------------------
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: Aidan Williams <[email-masked]>
Date: Thu, 28 Nov 2002 16:36:09 +1100

> much more difficult to renumber a site if the old and new prefix lengths

Assuming we can make the site-local prefixes globally unique,
why would we ever need to renumber them?

I want provider independent globally unique site-locals
precisely so I can set my local network up to be independent
of renumbering events.

Further, using an EUI-48 for a prefix (which extends beyond /48)
allows the site-local addressing to be automatically generated.

If you have working unicast site-local addressing, one can then
imagine building protocols on top that automatically allocate
16 bit SLA numbers from global prefixes (a la zerouter).

I can also imagine bootstrapping router renumbering from working
automatically configured site-local addressing.

- aidan

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Nov 2002 00:39:48 -0500

> why would we ever need to renumber them?

when you get external connectivity and a global prefix and 
realize that you're better off not having to support both the
global and the GUSL prefixes.   so you want to renumber from
GUSL to global.

(e.g. your apps run more reliably, administration is simpler, etc.)

Keith

---

From: Aidan Williams <[email-masked]>
Date: Thu, 28 Nov 2002 16:56:26 +1100

> global and the GUSL prefixes.   so you want to renumber from

No actually, I don't want to renumber from GUSL to global --
I want both.

My external connectivity is 6to4, and the prefix changes.
The lack of global PI address space exposes me to renumbering
pain.

> (e.g. your apps run more reliably, administration is simpler, etc.)

Ironically, that is exactly why I will keep site-locals running
in parallel with my globals.

- aidan

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Nov 2002 07:05:34 -0500

> No actually, I don't want to renumber from GUSL to global --

you want both.  others will want to renumber.
 
> in parallel with my globals.

having SLs (even globally unique ones) in addition to globals 
causes its own pain.  

I am not arguing that you shouldn't be able to choose to have
your network that way, just that the architecture should make
it easy to move from one kind of prefix to another.  What would
bother me is an architecture that imposed more pain for a site
that had started out with a GUSL and needed to transition to
globals.
--------------------------------------------------------------------
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: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Nov 2002 05:31:44 -0500

Hi Andrew,

4 or 6 subnet bits are not sufficient for most uses.  It is expected
that these addresses will be used for internal numbering within an
enterprise, so we should, at minimum, leave room for a 16-bit subnet
ID.  This would allow the same subnet numbers to be used for global
and local subnets.

So, it doesn't seem likely that we can auto-generate globally
unique addresses within the FECO::/10 space, unless we can determine
a mechanism for routers to obtain globally unique identifiers that
are no longer than 38-bits.

One or more people have made proposals on the list for mechanisms to
generate mostly-unique addresses in the FECO::/10 range, based on
hashes of the EUI-64, among other things...  Hopefully one of those
people will fully document such a proposal in an I-D, so that we can
discuss it in detail.

Margaret