Subject: Re: Misusing registries for uniqueness (was Re: Draft on Globally Unique IPv6 Local Unicast Addresses)

From: Greg Daley <[email-masked]>
Date: Mon, 02 Jun 2003 13:29:56 +1000

Hi Robert,

Robert Elz wrote:
>     Date:        Fri, 30 May 2003 16:01:15 +1000
>     From:        Greg Daley <[email-masked]>
>     Message-ID:  <[email-masked]>
> 
>   | It's not that dumb an idea, it reminds me of
>   | base-85 (RFC-1924) IPv6 addressing notation.
> 
> Which is a joke, not an idea (dumb or otherwise)...

I know :)
I live in the same city as you, word spreads.

>   | It certainly does solve the uniqueness issue
>   | for any given instant.  What happens if you
>   | 're-number' your telephone?
> 
> This has the same problem as MAC addresses - it isn't stable (someone
> else can quite validly end up with the number that used to be yours).

Indeed.  Similar issues exist with geographically generated
private addressing schemes: that land occupancy or ownership
is finite time (sometimes very short in terms of the Internet's life).

> But, if abusing number spaces to try and gain easier uniqueness is
> an aim, then a (less automatic but perhaps still reasonable) method
> would be to abuse the IEEE OUI space (instead of the MAC address space).
> 
> That is, any organisation with an OUI (22 real bits big) has 18 bits
> (256K) of numbers they can allocate however they see fit.   And of
> course, organisations that the IEEE allows can go get new numbers.
> (The IETF is one such organisation of course, so IANA would have
> numbers to allocate).
> 
> (This re-use of numbers would not conflict with other uses of the OUI,
> it would be in parallel, just as MAC48 and EUI-48 are - it would be
> xxx-40 of course, or -45 or something, depending upon prefix length).
> 
> Of course, IEEE would probably need to agree to their number space
> being abused this way before we could suggest it as a method.
> 
> Doing this still doesn't guarantee any kind of uniqueness, all it does
> is provide a ready made answer to the "one monopoly organisation"
> problem, while similtaneously making it effectively impossible for
> anyone to snarf any large fraction of the address space (no need to
> prescribe huge fees - like Eur 10).

Umm, except the IEEE, who I'm sure are good people...

I was thinking that the OUI space would be a bit of overkill
for most organizations (2^18 networks is a lot).
Then I looked on the IEEE website and noticed that they have
already considered allocation of blocks of 4096 addresses
to organizations as "Individual Address Blocks".

http://standards.ieee.org/regauth/oui/index.shtml

Essentially, they are 36 bit unique identifiers drawn from the
OUI space.   Organizations which really need a unique
identifier could make use of these 36 bits to prove ownership
of a MAC (only ~550USD).

I'm not sure if this is palatable to the IEEE considering
the somewhat stringent statement I found at:

http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html

"The IEEE-RAC solicits any information that poses a threat to the 
viability of the unique MAC-48/EUI-48/EUI-64 address space, whether an 
IEEE proposed standard or another standard or specification. Further, in 
carrying out this duty to preserve the longevity of these identifier 
capabilities, the RAC will act, via liaison or direct coordination, to 
prevent potentially abusive uses for the consumption of the OUI."

Given the title of the thread, this may be worth consideration.

Of course an organization may choose to purchase 2^(addrspaceprefixlen)
consecutive NICs from the same manufacturer... :)

Greg.

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Jun 2003 16:34:38 +0200

So, Benny is turning it upside down - instead of asking the registry
for a number, we tell the registry which number we'd like (and 
the registry will say no if the number is already registered).

It would work, but I don't see any particular advantage over having
the registry pick a number. It's an opaque, meaningless value either
way.

   Brian

Benny Amorsen wrote:
> 
> On fre, 2003-05-30 at 02:45, Hans Kruse wrote:
> > I actually see a lot of value in the /56 proposal;  I really like the
> > simplicity of creating the /56 from any MAC-48 in the network.  It
> > accomplishes the uniqueness property without requiring central
> > registration, and should serve organizations up to considerable size very
> > well.  And it readily discourages the notion of "make up a prefix" for
> > temporary or (temporarily) disconnected networks.
> 
> I have been lurking in this discussion by reading it as a newsgroup over
> at gmane.org. (I tried to post too, but even though gmane.org said it
> was posted, I do not think it reached the mailing list.)
> 
> It seems to me that things would be easier by letting people invent
> their own numbers by whatever method they prefer. Then, if they care
> whether the numbers are unique, they can register the numbers they
> picked in one or more registries. This way they can be assured that
> other well-behaved people will not use the same numbers, and at the same
> time it is clear to everyone that the numbers are not /guaranteed/ to be
> unique.
> 
> Later when two organisations need to connect to each other directly and
> the numbers conflict, I bet the organisation that registered its numbers
> has a good chance of being the one not having to renumber...
> 
> By the way, I am not very fond of the MAC-address method. If we are into
> misusing other registries, we could turn a phone number into hexadecimal
> (including the international prefix.) 12 digits can be stored in 40
> bit...
> 
> /Benny
> 

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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: Scott Bradner <[email-masked]>
Date: Tue, 3 Jun 2003 14:17:47 -0400 (EDT)

> the registry will say no if the number is already registered).

does wonders to the routing table

Scott