Subject: RE: globally unique site local addresses

From: "Michel Py" <[email-masked]>
Date: Thu, 21 Nov 2002 09:35:25 -0800

Christian,

> Christian Huitema wrote:
> we want to remove ambiguity, which is the root cause
> of many problems occuring when scoped addresses leak.

If we want these addresses to be used, there are two things we need to
do:

1. Make these addresses globally unique, which is effectively removing
ambiguity. As of today, I don't see how we could achieve this without a
uniqueness database. It probably means some kind of a registration and
possibly a fee. We absolutely need to make the registration easy and the
fee low if there is one.

I invite people to have a look at:
http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt
and its (temporary) results:
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt
This scheme would use 1/64th of the FEC0::/10 space (replace 2346::/16
with FEFE::/16)

2. Make these addresses not globally routable, not only by decree but by
requiring them being blocked by default and also BGP routes for this
range being rejected by default. Ambiguity is somehow a guarantee that
these addresses are not publicly routable. If we remove ambiguity, we
need to provide something instead to address this.

Bob Hinden and I have contributed some interesting suggestions about
this earlier, but they were lost in the email volume. If my memory is
correct, Bill Manning was the only one to pick it; Bill, I would like
more of your comments.

> we may or may not want to prevent routing of these
> addresses between sites. I guess we should certainly
> prevent routing between non-consenting sites.

See above.

> we definitely want the addresses to be provider
> independent, so they can survive renumbering or
> intermittent connectivity.
 
Definitely.

> indeed, it would be desirable that the addresses
> be usable in sites that are not connected.

Yes.

>and we would definitely want the addresses to be free.

I think we have to accept the compromise of a low fee, as the uniqueness
database would likely be handled by the RIRs and we don't want to
bankrupt them.
 
> I guess that the consensus is, "just like site local
> addresses." We don't want to prevent usage in connected
> sites, but we expect that in these sites the hosts will
> also have provider based addresses, and that traffic
> routed out of the site will use the provider addresses.

Agreed.

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: Steven Blake <[email-masked]>
Date: Thu, 21 Nov 2002 13:06:31 -0500

> need to provide something instead to address this.

This is a business issue between customers and ISPs and is none of the
IETF's business IMHO.

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: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 20:26:59 +0200 (EET)

On Thu, 21 Nov 2002, Michel Py wrote:
> uniqueness database. [...]

One idea IMO is that we don't even want to be aim for total, provable, 
complete uniqueness.

Looking at some requirements, I believe "unique enough" is good enough.

Especially if we focus on the -real- case, non-globally routable 
addresses.

FEC0::/10 has about 38 usable bits there.  That's enough for "unique
enough".  No need for even that.  Let's assume /16 - /40 -- 24 bits would
be enough too.  By birthday paradox, even in that case, collisions should
only be probable if you communicate thousands of different sites
simultaneously and there are referrals and third party interconnections.

Take your name, address, phonenumber or whatever (it must be long enough,
though), apply a hash function and BAM -- there you have "unique enough"
site-id identifier.  No need for any registrations etc.

As long as the site-id identifier is created with a clear conscience, 
based on enough material (what you use is really irrelevant, but several 
options could be listed) so the hash function provides values random 
enough to be useful, you're done.

If you want globally routable addresses, this is of course a non-starter.  
There, a geographical addressing, based on e.g. GPS readings like Tony has 
suggested, is probably the easiest.

But I don't think we should be providing _globally routable_ addresses in 
the first place.  They answer some other problems than the one that's an 
argument in the site-local discussion.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Arien Vijn <[email-masked]>
Date: Thu, 21 Nov 2002 13:56:31 -0500

What is the use of eliminating ambiguity *and* make sure these addresses are
not globally routable? I can only see one usage, namely: site-to-site
connections. On which there was consensus that this was not the way to go.
But perhaps there are more reasons?

In theory you are absolutely right. But it practice this won't work. The
charm of RFC1918 and site locals is that one not have to go to any registry.
Which is a barrier no matter what.

Provided that this is the way to go. We need to come up with a way to
automate/self-assign "likely to be globally unique site local addresses".
The *only* use for this is to inter-connect globally disconnected sites.

For globally connected sites we either have to stick with the PA space
architecture or come up with something new to ensure address stability.

Arien

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 20:56:03 +0200 (EET)

On Thu, 21 Nov 2002, Jari Arkko wrote:
> We still need to avoid user input for self-configuring home networks etc.
> How about a hash of the IEEE MAC address of the node that created the
> site?

Sure -- and take some other things in consideration.

(I don't know whether MAC address in itself will provide enough material 
for a reliable hash, but I could see  a possibility of it working.)

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Nov 2002 18:54:24 +0200

Jari

---

From: Arien Vijn <[email-masked]>
Date: Thu, 21 Nov 2002 14:11:43 -0500

Missed your mail, Pekka otherwise I wouldn't try make the same point.

> for a reliable hash, but I could see  a possibility of it working.)

48 bits MAC is not globally unique (found that out the hard way). But
hashing several MACs on the links of a disconnected sites toghere with a
timestamp will do I guess.

Arien

---

From: Richard Nelson <[email-masked]>
Date: Fri, 22 Nov 2002 05:31:09 +0000

> need to provide something instead to address this.

It would be really nice if the "not globally routable" property was by
some mechanism stronger than blocked by decree.  AFter all we no that
RFC1918 addresses do get routed sometimes by mistake, but you can't
route back to them because of the ambiguity.  This may be too difficult
but it could be worth thinking about for a little bit.  One idea I had
(with lots of problems) would be to allocate them with prefixes too
large to be handled by EGPs.  

> correct, Bill Manning was the only one to pick it; Bill, I would like
Yes they got lost in the volume.  Please repeat them on this thread.

Richard.

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Nov 2002 20:45:29 -0500

>simultaneously and there are referrals and third party interconnections.

I don't think that you can, or should put the new globally-unique,
provider independent address space inside the FECO::/10 allocation.
As far as I know, we still plan to allow the FECO::/10 prefix to be
used for disconnected sites, and perhaps other "moderate" usage.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Nov 2002 20:46:46 -0500

>timestamp will do I guess.

It is actually my (weak) understanding that taking more inputs
does not actually result in more "uniqueness", at least for
random number generation.

Does anyone know how that works for hashing?

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Nov 2002 11:40:07 +0200 (EET)

> used for disconnected sites, and perhaps other "moderate" usage.

Oh?

I am not sure about goals what we're actually trying to solve.

IMO, putting some randomness in the fec0::/10 solves nearly all, or all, 
the problems with current _site-local_ addresses. (I'm not sure because 
the requirements list doesn't exist yet :-).

Naturally, people will want to have truly globally unique, routable, 
provider-independent, etc. addresses.

But there is no free lunch.  Have we been through this road yet?  Yes, I 
believe so, with no apparent success.

Let's define our scope better than that and leave the latter for e.g.  
multi6 to consider (e.g. geographically automatically allocated PI space).

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 24 Nov 2002 20:45:35 +0200

Margaret,

> Does anyone know how that works for hashing?

AFAIK, the bigest problem with random number generation is
non-random seed data.  Adding more sources of randomness
helps in that.  In this case, relying in just one MAC address
as a seed for a hash function is probably not good enough, but
e.g. taking the MAC address *and* the machine's current idea
of date & time in millisecond precision probably is.

As another issue, just picking a cryptographically strong
hash function and using it as a random number generator is
typically *not* good enough for many uses of random numbers,
but IMHO it is OK for generating these kinds of identifiers.

Thus, if we want a method for automatically generating
prefixes for globally unique enough site local addresses,
a decent method might be

   sha1( current date and time in ms | interface MAC )

where the date & time would be a 64 bit integer and the
MAC address either 48 or 64 bit MAC, the 48 bit version
enlarged to 64 bits.  Note that there is no need for time
synchronization.  If there are more implementations of MD5
than SHA-1, MD5 would be good here, too.

In the case of a collision, the algorithm can be simply
rerun.  The new result will be completely different.

--Pekka Nikander