Subject: Re: "unique enough" generation

From: Dan Lanciani <[email-masked]>
Date: Thu, 21 Nov 2002 17:16:30 -0500 (EST)

Pekka Savola <[email-masked]> wrote:

|> I'm all in favor of unique site locals,
|> but I don't see how they eliminate the need to deal with scopes.  
|
|I'm not sure why we'd have to be able to kill scopes.

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.

|> They are
|> extremely attractive in that they will allow us to interconnect sites with
|> dynamic tunnels, bypassing ISP restrictions on address count and stability.
|> By treating "native" aggregated addresses in effect as routes we can easily
|> build a distributed routing layer that scales indefinitely and hides all the
|> problems of unstable addresses from the applications.
|
|I don't see any significant problems which would prevent this, even though 
|we may still want to prevent the use of these site-locals to disconnected 
|or semi-disconnected sites.

Then I propose the same thing I (and others) have proposed in the past.  Pick
a prefix xxxxxx from the SL space at random and append the hex to some well
known string, e.g., "mysiteprefix" giving mysiteprefixxxxxxx.  Register
mysiteprefixxxxxxx.com as a domain name.  If it already exists, pick a new
random number and try again.  This provides the uniqueness without involving
a new registry service and the nominal fee will discourage people from over-
consuming.

To move to the next step (assuming you want outside connectivity), register an
ISP-provided global as the address for this domain (or a sub-domain; there are
some optimizations that can be made).  This is your tunnel destination.  When
another site wants to send packets to you, their router recognizes the prefix
as a site-local-unique address and, if the tunnel destination isn't already
cached, performs a DNS lookup of mysiteprefixyyyyy.com.  If (as some folks
claim) the dynamic DNS will be good enough to handle the instability of that
ISP-provided global for host name lookups then it will be good enough for
this as well.  If (as is more likely) the DNS won't be up to the task the
situation can be improved by having tunnel end points send hints to recent
partners when their addresses are renumbered.

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
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: Markku Savela <[email-masked]>
Date: Fri, 22 Nov 2002 00:34:44 +0200

> most people are complaining about rather than the existence of the addresses

I cannot understand those people complaining about scopes. We will
have

  (a) addresses that are global
  (b) addresses that are local, with limited reach (firewalled or
      whatever)

Now, if we have (b), isn't it a great advantage that an application
can at least see that this address may have reachability problems, by
looking it's scope level?

The proposals of allocating something slices from "global space" for
(b) addresses seem insane to me. After that, applications just have no
way of getting even a warning that using such address might be
problematic. Situation is even worse than with site locals available!

The "global space" might as well be the current site local
prefix. Interconected sites that agree to exhange routing information
about (b) addresses, on might even define a new prefix, with scope
between site local and global.
--------------------------------------------------------------------
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: Markku Savela <[email-masked]>
Date: Fri, 22 Nov 2002 00:57:52 +0200

>   (b) addresses that are local, with limited reach (firewalled or

Of course, having only (a) would be ideal. But, this would work only
if the whole address allocation is turned upside down:

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

 - of course, any random address generation won't scale. 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.. :-)
--------------------------------------------------------------------
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: Mark Smith <[email-masked]>
Date: 22 Nov 2002 10:31:41 +1100

>   (b) addresses that are local, with limited reach (firewalled or

I'd take a step back (up?) to a higher level and say there are only
really three fundamental scopes :

1) External
2) Internal
3) Link local

Reliable External communications requires globally unique addressing.

Reliable Internal communications does not require globally unique
addressing, but does require internally unique addressing.

The current site-local model seems to me to be a too restrictive
solution to the Internal communications requirement, as it creates
artificial boundaries on the definition of Internal communications.

Further, with the current site-local model, you have to assume that
there will be addressing collisions when merging even the smallest of
two "sites" - there is a fairly good chance that most people will use
fec0:0:0:1::/64 for their first subnet.

This duplicated address space, and almost guaranteed chance of address
space collision seems to me to be the cause of a lot of the recent
arguments about site-local addressing, including problems cross site
address referrals etc, and solutions such as multi-site routers etc that
just feel to be way to complex to me. 

Pekka's solution reverses that assumption. In the majority of cases, you
won't have a duplicated (on a global scale) Internal address space,
making merging "sites" a simple as bringing up the link between the
sites, and pushing a few routes between the networks.

On the rare occasions that there is a Internal address space collision
under Pekka's model, it will (or at least should) be discovered during
the preparation for the connection of the two "sites" together. In the
case of a collision, having to renumber one of the Internal address
spaces to make it unique again is unfortunate, but it is the price of
requiring an Internal address space that is independent of your provider
supplied global address space.

Regards,
Mark.