Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses

From: "Christian Huitema" <[email-masked]>
Date: Fri, 9 May 2003 15:12:41 -0700

Bob,

I believe your draft is a step in the right direction, but I regret that
it does not support the "informal networking" scenario, in which unique
numbers are assigned to network segments without intervention of an
assignment authority. That scenario requires "self allocation". The
obvious constraint in any self-allocation scheme is that it must either
use a random number, or an reuse an already available identifier.

We have been through this a couple of times, and we know that the random
number route is fraught with perils. The birthday paradox dictates that
the number of bits in the random number be at least twice the base 2 log
of the number of objects in the system. If we aim for 10 billion
networks, we would need at least 66 bits, and that does not sound very
practical. 

This leaves us with the obvious alternative, i.e. to reuse an existing
identifier. Two of those come to mind: IPv4 addresses, and IEEE 802
identifiers. Sites who have an IPv4 address could use it to build a 6to4
prefix, so we can leave that aside. But we could combine a unique IPv6
prefix (e.g. FEC0::/16) and a 48 bit IEEE 802 number to build a unique
64 bit link prefix. 

Such 64 bit prefixes would have many of the advantages of your global
site identifiers, except they would identify links, not sites. Most
important, they would not require an assignment authority.

-- 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: Zefram <[email-masked]>
Date: Sat, 10 May 2003 14:51:21 +0100

Christian Huitema wrote:
>                                    But we could combine a unique IPv6

This is a neat idea.  It would be good to have this option available in
addition to registered allocation and random self-allocation: these three
allocation methods all have different trade-offs of uniqueness, immediacy,
privacy, portability, and other factors, and we should leave it to the
individual network administrator to decide what the right balance is
for their own network.  Mechanism, not policy.  (In the same vein of
diversity, consider also Tony Hain's draft on geographically-derived
addresses.)

A suggestion: it would be convenient, in some cases, to have a few bits
available for a subnet ID.  Scanarios in which there isn't a unique
interface (with a unique EUI-48) for each subnet are obscure, but it's
easier to imagine cases where there's only one EUI-48 that's *conveninent*
to use.  Also, note that the EUI-48 includes the scope and multicast bits,
which will always be zero in this use, so we can compress the EUI-48 to a
46 bit field.  I suggest having a 10-bit prefix, 46-bit compressed EUI-48
field, then 8 bits of subnet ID.  The prefix can't be fec0::/10, because
that has site-local scope semantics; it could perhaps be fe40::/10.

-zefram

---

From: Geoff Huston <[email-masked]>
Date: Sun, 11 May 2003 14:21:59 +1000

I've checked with one of the WG chairs, and I'd like to give the
working group a headsup to the draft
http://www.ietf.org/internet-drafts/draft-huston-ipv6-documentation-prefix-00.txt

In publishing this as an individual submission the authors were not explicitly
intending that this document be adopted by the WG as a WG document, but
any review and comment by WG members would be most helpful, of course.

The draft documents an action taken within the APNIC community in late 2002,
where the IPv6 prefix 2001:0DB8::/32 has been set aside for use in 
documentation
examples, and in the IANA Considerations section the draft describes an 
IANA action
to include this prefix in the IPv6 address registry as a reserved use 
prefix for
documentation purposes.

The draft has been in the Internet Drafts repository since Feb 16 and has 
elicited no
editorial comments to date.

(An earlier draft  proposing the reservation of an IPv6 documentation was 
prepared
by Mark Blanchett some years back in the context of the IPv6 working group, 
as I
understand, but the draft has expired and no further action was  taken with 
it and
no address space reservation was made at the time.)

regards,

   Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 May 2003 13:04:58 +0200

We need site prefixes, not link prefixes, even for SOHO networks.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 May 2003 13:19:52 +0200

Since you ask: I read this when it came out and thought "good."
Ship it, imho.

   Brian

---

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 11 May 2003 14:48:10 +0200

> > working group a headsup to the draft
http://www.ietf.org/internet-drafts/draft-huston-ipv6-documentation-pref
ix-00.txt

<SNIP>

I try to use it as much as possible already.
Though still IMHO it would have been a bit 'nicer' if it
where 2001:d0c::/32, but this one works too.

One thing that could be consider is how to document
examples between 2 TLA's. Ofcourse one can use something
in the lines of:
"We will setup a BGP peering between ISPA who is allocated 2001:db8::/35
and ISPB who is allocated 2001:dba::/35."
There will always be a case I think where one needs multiple
prefixes for explainations and examples like these.

Like Brian says: ship it.
Delays are only irritating, like with the ip6.int->ip6.arpa transfer of
6bone :(

BTW, is TLA still the good 'wording' for the prefixes allocated by the
RIRs?

Greets,
 Jeroen

---

From: Geoff Huston <[email-masked]>
Date: Sun, 11 May 2003 23:43:32 +1000

>where 2001:d0c::/32, but this one works too.

I had thought of 2001:D0C0/32 , but I was too late with this
suggestion as well!

>examples between 2 TLA's.

Its a good point, but of course where you can think of a
documentation example involving 2, you can think of an example
involving 3 and so on.

>Ofcourse one can use something
>in the lines of:

As you suggest, rewriting the example of multiple entities with slightly
longer prefixes is a reasonable compromise in this case. Explicitly
documenting  this approach is a useful addition to the document
and I will put it to my coauthors for consideration in a revision of the
draft. Thank you for the suggestion.

>Like Brian says: ship it.

thanks!

>BTW, is TLA still the good 'wording' for the prefixes allocated by the

My understanding is 'yes', but if not, then would someone closer to
the currently correct terminology lexicon  please correct me.

regards,

   Geoff

---

From: Zefram <[email-masked]>
Date: Sun, 11 May 2003 16:34:21 +0100

>where the IPv6 prefix 2001:0DB8::/32 has been set aside for use in 

It's good to have such a prefix, but I wonder about the best place to
put it.  How permanent are the sub-TLA assignments under 2001::/16?
It would be unfortunate to end punching a hole in an address block that
might later be reassigned.  Would assignment of a /16, perhaps 2d0c::/16,
be too wasteful?

-zefram
-- 
Andrew Main (Zefram) <[email-masked]>

---

From: Andrew White <[email-masked]>
Date: Mon, 12 May 2003 11:03:43 +1000

> We need site prefixes, not link prefixes, even for SOHO networks.

I disagree.  You need a 'site prefix' if you intend to centrally number each
link in the 'site', presumably with a number that can be used interchangably
with a local /48 or a global /48.

The other alternative is to let each link number itself, as described in
  draft-hinden-ipv6-global-site-local-00.txt
  draft-white-auto-subnet-00.txt
    (two variants of the same idea)

By bootstrapping off the theoretically unique EUI48 we can give each link an
unique prefix without any centralised intervention.  The resulting addresses
are not aggregable and thus not suitable for global routing, but are fine
for a network of up to a few hundred links.

A certain amount of cooperation is required between the DNS and hosts to set
DNS up, but this is not necessarily an insurmountable problem.

-- 
Andrew White

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 May 2003 08:37:41 +0200

In response to both you and Christian, I think the arguments why
we need /48s, and can afford to give them, are in RFC 3177.

That doesn't exclude /64 in some cases, but as a general solution,
we should assume the need for subnets and not assume automatic subnet
numbering.

  Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 May 2003 08:03:25 +0100

Could both schemes (auto /64 and site /48) not progress as alternatives
for deployment?   What is on the table for site prefix allocation as that
alternative to the white/hinden /64 proposals?

I recall that older Solaris versions used to allocate interface MAC addresses
per host rather than per interface (maybe they were looked up from some
system storage rather than the interface itself), so we would need to be
confident of not repeating such problems (where the clashes are in the
routing device).   How prevalent is this?    (Of course, old Solaris versions
have no IPv6 but the question is which OS's may do likewise in the future
where that OS may be used as a routing platform, as Solaris often is, e.g.
for firewalls)

Tim

---

From: Bob Hinden <[email-masked]>
Date: Mon, 12 May 2003 15:55:07 -0700

It looks OK to me as well.

>prefixes for explainations and examples like these.

At some point, one needs the whole address space for documentation and it 
should be clear we can't do that.  Consequently I think a single /32 should 
be fine for most purposes.  Hopefully people setting up BGP peering can 
deal with something like:

"We will setup a BGP peering between ISPA who is allocated  XXXX:XXXX::/32
and ISPB who is allocated YYYY:YYYY::/32."

I would also hope that the documentation made it clear that the prefix 
length might be something other than a /32.

Bob

---

From: Steven Blake <[email-masked]>
Date: Mon, 26 May 2003 04:13:47 -0400

> important, they would not require an assignment authority.

Out of those 10 billion networks, fewer than 0.4% will need more than
8 bits of internal subnetting (see [1]).  So they can operate happily
with a 56-bit globally unique local address prefix (and they can
treat their /48 provider assignment as a /56 by appending eight zeros).

The 56-bit prefix can be formed by appending an IEEE 802 address to a 
/8 format prefix (someone already proposed something similar to this).
Networks needing more than 8 bits of internal subnetting will be able
and willing to pay a registry.

[1] A population of 10 billion can support at most ~40 million organizations
    with at least 256 members (assuming no overlap).  8 bits of internal 
    subnetting would allow a subnet per individual.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913
--------------------------------------------------------------------
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: Mon, 26 May 2003 17:06:07 +0700

Date:        Mon, 26 May 2003 04:13:47 -0400
    From:        Steven Blake <[email-masked]>
    Message-ID:  <[email-masked]>

  | Out of those 10 billion networks, fewer than 0.4% will need more than
  | 8 bits of internal subnetting (see [1]).

I don't believe this for a second, but even assuming it were true:

  | So they can operate happily
  | with a 56-bit globally unique local address prefix (and they can
  | treat their /48 provider assignment as a /56 by appending eight zeros).

This means you're constraining the way they number their internal subnets,
and (effectively) meaning that instead of the /48 that everyone is promised
(to allow movement from one topology dependent address prefix to another
without needing to produce an entire new internal address plan) what
will be available is just /56's.

  | The 56-bit prefix can be formed by appending an IEEE 802 address to a 
  | /8 format prefix (someone already proposed something similar to this).

Yes, it is not a good idea.   First, it assumes that an IEEE MAC-48
(or EUI-48 - which are you intending be used?) is a stable identifier
which each organisation owns for eternity - which it isn't, it is a transient
thing which lasts as long as one owns the equipment to which that address
was assigned.   Otherwise, when someone else takes over the equipment
(perhaps "rescues" it from a dumpster) they have the same 48 bit address
as your organisation used for its numbering, which they may also choose to
use as well.

Attempting to take a number designed for one purpose and bend it into use
in ways its design was never intended to meet is almost always a bad idea.

Further, why would anyone assume that for the lifetime of IPv6, MAC addresses
will necessarily continue to be in use?   Network technologies change.
Right now (for compatibility) everyone wants 48 bit addresses from the
same space - but eventually someone will decide that the benefit isn't
worth the cost, and simply abandon that - after which others will follow.
The IEEE has already created its EUI-64's - one must certainly allow for the
possibility that some future technology might use them.

  | Networks needing more than 8 bits of internal subnetting will be able

Most likely, yes.

  | and willing to pay a registry.

But why would anyone assume that?    What is to be assigned here is
a number.   I can make one up easily.   My number isn't visible to any of
you, it is for my use alone (or for those with whom I make private
arrangements).   Why would anyone want to bother dealing with some
bureaucracy for that?   Some might, for the warm fuzzies it gives, others
will see that there's nothing at all the registries can do to prevent
anyone from using any number they want - hence the fuzzies aren't really
all that warm.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 May 2003 13:24:16 +0200

below...

> anyone from using any number they want - hence the fuzzies aren't really

I agree with kre completely up to this last point. It's more than
warm fuzzies. It is correct that if I pay 10 Euros for a copy of
the number "181:8008:7134", there is nothing to stop someone else using 
it. But in fact, if I get my copy of "181:8008:7134" from a registry that 
promises never to give anyone else a copy of it, then it's easy to decide 
who wins if I ever encounter a clash with another copy of "181:8008:7134".

I wouldn't have a problem with a variant of Bob's proposal in which
(for example) FC00::/8 is followed by a 40 bit ID allocated as Bob
suggests, and FD00::/8 is followed by a user-assigned 40 bit ID. 
Then FC00::/7 would be the prefix for all limited-scope addresses.

(The arguments why we should only cater for /48s are given in
RFC 3177, and are a done deal as far as I'm concerned.)

   Brian

---

From: Steven Blake <[email-masked]>
Date: Mon, 26 May 2003 08:42:50 -0400

> >   | treat their /48 provider assignment as a /56 by appending eight zeros).

I should have said "the rest can ..." (note to Steve: don't send future
e-mails at 4am as a cure for insomnia).

> > will be available is just /56's.

This doesn't follow.  Do you think that if you numbered your SOHO network
out of bits 48-55 instead of 56-63, that it would somehow stop your provider
from only allocating you a /56, if they could get away with it?

> > as your organisation used for its numbering, which they may also choose to

Please.  10/100 NICs are less that 10 euros now (I got one for free with
my cable modem).  I would just as happily copy the MAC address from one
and grind it into dust with my heel as pay some registry.

> > possibility that some future technology might use them.

This assumes that IPv6 will outlive Ethernet.  Big assumption ...
A contemporary solution utilizing a contemporary, pre-established registry,
doesn't preclude future solutions.

> > anyone from using any number they want - hence the fuzzies aren't really

Because these addresses are certain to wind up in the DNS.

> RFC 3177, and are a done deal as far as I'm concerned.)

The perfect is the enemy of the good (enough).

Regards,

---

From: Robert Elz <[email-masked]>
Date: Mon, 26 May 2003 20:49:40 +0700

Date:        Mon, 26 May 2003 08:42:50 -0400
    From:        Steven Blake <[email-masked]>
    Message-ID:  <[email-masked]>

  | I should have said "the rest can ..." (note to Steve: don't send future
  | e-mails at 4am as a cure for insomnia).

That was kind of obvious, certainly it was how I read your first message.

  | This doesn't follow.  Do you think that if you numbered your SOHO network
  | out of bits 48-55 instead of 56-63, that it would somehow stop your provider
  | from only allocating you a /56, if they could get away with it?

No.   The question is whether we allow them to get away with it.   If we
have a numbering standard that (essentially) forces most sites (all but 
0.4%...) to use what is effectively a /56, that's what people will start
allocating, for all uses.   Not a good idea.

  | Please.  10/100 NICs are less that 10 euros now (I got one for free with
  | my cable modem).  I would just as happily copy the MAC address from one
  | and grind it into dust with my heel as pay some registry.

Yes, so would I.   But, in practice, I don't grind the things into dust,
instead they get shoved in a drawer, and eventually someone says "I see
you have 30 unused cards in that drawer, can I have one (or two)" and
the one they pull out just happens to be the one that matters...

  | This assumes that IPv6 will outlive Ethernet.  Big assumption ...

No, it assumes that something else may exist during the lifetime of
IPv6 - ethernet may still exist as well (probably will).   The question
is whether you can assume that everyone will necessarily have a MAC
address (or be willing to go and buy one).

  | A contemporary solution utilizing a contemporary, pre-established registry,
  | doesn't preclude future solutions.

It doesn't, unless it consumes the address space.

  | Because these addresses are certain to wind up in the DNS.

Of course, but that's irrelevant.   1918 addresses end up in the DNS now.
Yet (somehow) the net manages to keep on working.   Those addresses don't
work (for most people) - nor will any kind of unroutable IPv6 address we
invent, when it gets found in the DNS, unique, or not.   The only thing
that unique prefixes achieve, is to prevent a packet ending up at the
wrong node (someone else's version of the address).   Given EUI-64's in
the low 64 bits of most addresses, the chances of that are essentially 0
regardless of how ambiguous the prefix is.  It simply isn't worth
inventing lots of mechanism which pretends to fix this, it isn't a big
enough problem to worry about (if a fix were very likely to work, and
very cheap - in all senses - to implement, then sure, but for all suggestions
seen here, neither is true).

kre