Subject: "unique enough" generation

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Nov 2002 22:32:04 +0200 (EET)

Hello,

I'm assuming that for the intents and purposes of replacing 
"local" site-locals, "nearly unique" site-locals would be enough.

(Actually, the change would be quite nice if implemented under fec0::/10 
-- not many changes at all.)

I'd like to focus a bit on how to generate these "nearly unique" site
identifiers.

Different dimensions here, which I could quickly think of, are:

1) randomly generated, or
2) "semi-provably" generated

And for more detailed analysis:

1) is easy -- just use random generation, has of (MAC + timestamp), 
whatever.

2) would be based on some semi-stable identifier.  If you'd like the 
property to be able to re-generate the site identifier later and get the 
same result, this is what you'd like.  This may have some benefits, like 
automatic configuration is used without co-ordination in more than one 
location (e.g. using a company name as a key for hashing).  This would 
also be desirable if you don't want to store the resulting site-id in some 
stable storage (really, should not be a problem).

It seems likely that just randomly generated site-id's should be enough 
for everyone unless there are some synchronization requirements I'm not 
aware of.

Did I miss something crucial?

It appears to me that we have a very obvious and clear solution here, not 
even requiring any IANA/IESG action to get kickstarted.

-- 
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

--------------------------------------------------------------------
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: Dan Lanciani <[email-masked]>
Date: Thu, 21 Nov 2002 19:11:26 -0500 (EST)

Markku Savela <[email-masked]> wrote:

|> Fine by me.  It's just that dealing with scopes seems to be the problem that
|> most people are complaining about rather than the existence of the addresses
|> themselves.
|
|I cannot understand those people complaining about scopes.

They are complaining because a routing complexity issue has been pushed onto
applications.  I have trouble working up a lot of sympathy for the complaints,
though.  If they had put this much effort into complaining about the address
architecture in the first place we could have solved the routing problem at
the routing layer.

| - you don't get addresses from your ISP, everyone/every site is
|   automaticly entitled to unique global address range. When one makes
|   a contract with ISP about route, the ISP will make it packets with
|   these addresses flow correctly.

Yes, that's how things worked in the good old days.

| - of course, any random address generation won't scale.

That isn't clear.  Central routing table size scales linearly with the
number of addresses.  Linear isn't as bad as some people make it out to
be.  The aggregation hack was a bad tradeoff because while it reduced the
table problem from linear to log it changed the address usage from linear
in users to exponential in provider chain height.  It's very hard to win
against an exponential.

Fortunately, it is very easy to distribute the routing process and reduce
the problem to a constant.  So even if linear worries you there is an
alternative.  I outlined a simple way to distribute the routing in a previous
message.  It's not as neat as building it into the routing layer, but it
works without changing the infrastructure.

|But, the
|   proposals for generating unique addresses from geographical
|   position coordinates might be one way, and might scale.
|
|So, let's scrap the current address allocation and just define rules
|how to generate address from location (and maybe need a floor number,
|or height for buildings.. :-)

That would certainly be one approach.  Anything that leaves sites with some
way to control address space will ultimately support a tunneling solution
independent of whether the ISPs allow the addresses to be routed.

				Dan Lanciani
				ddl@danlan.*com