Subject: RE: Wade through the archives (was Re: another renumbering question)

From: "Richard Draves" <[email-masked]>
Date: Mon, 19 Feb 2001 20:30:52 -0800

> But speaking of existing implementations, what would happen 
> if an existing
> router advertised to an existing host that one of the host's prefixes
> contained a site ID (that is, a site-local with a non-zero 
> 38-bit number).
> Presumably the host would accept it?

I haven't tried this, but I believe the MS implementation would accept a
non-zero 38-bit number in a site-local prefix.

Rich
--------------------------------------------------------------------
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: "Richard Draves" <[email-masked]>
Date: Mon, 19 Feb 2001 20:30:52 -0800

Rich

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 19 Feb 2001 19:16:42 -0800

The discussions always ended up on the same kind of conclusion: in
theory it is a fine idea, but we would have to change existing
implementation, and besides it is not easy to allocate unique numbers.
There are basically four ways to allocate random numbers, and none of
them is particularly attractive:

1) Picking numbers at random is easy, but you need a good random
generator, and besides you hit the birthday paradox with 2^^19 entries,
i.e. less than a million. There are way more than 1 million potential
sites.

2) Deriving numbers from other pre-established registries is tempting,
but there are not very many suitable pre-existing registries. IEEE-802
numbers are too large too fit; IPv4 addresses have the right size but
not the right stability.

3) Starting a new registry looks simple on paper, but the practical
problem are not so small -- for example, decide who will be king; find
the right balance between automation and reliability; etc.

4) Combining random allocation with duplicate detection would go past
the birthday paradox, but is almost impossible to conduct at the scale
of the Internet...

Now, if you can change that...

-- Christian Huitema

> -----Original Message-----
> From: Paul Francis [mailto:[email-masked]] 
> Sent: Monday, February 19, 2001 2:36 PM
> To: [email-masked]
> Subject: Wade through the archives (was Re: another 
> renumbering question)
> 
> 
> 
> I took Steve up on his suggestion of looking through the 
> archives on this topic.
> 
> With some effort I found three threads, all initiated by 
> Christian, in May '97, Dec '97, and Nov '99.  I saved the 
> relevent messages...you can find them at 
> http://www.aciri.org/francis/IPv6> _site_id_threads.txt if you 
> are so inclined.  This is 
> probably not exhaustive, so if anyone can point me to other 
> threads that would be helpful.
> 
> I didn't see any major ideas in the previous threads that 
> weren't in the latest thread.
> 
> A problem I found when looking over the threads is that a 
> complete picture of what a site ID would be and how it would 
> work was never generated, with the end result that different 
> people were talking about different things and to some extent 
> talking past each other.
> 
> Having read the arguments, I still believe that there is 
> something to be said for the site-ID notion.  The site-ID 
> would be for sites that want to have their own number space 
> for internal communications, with reasonable assurance that 
> nobody else is using the same space.
> 
> The site-ID would not supplant the use of site-locals by 
> other sites who wanted to use them.  Site-locals would remain 
> as defined.
> 
> A site-ID would also not by itself identify what is and is 
> not in a given "site".  In other words, one couldn't take two 
> addresses with site-IDs and, in the absense of any other 
> information (DNS entries or routing tables) say definitively 
> whether they could or could not reach each other using the 
> site-ID addresses.
> 
> I'm inclined to write a draft specifying this so that we can 
> have a focused and consistent (and dare I say difinitive?) 
> discussion about it.  Is there anyone out there who in 
> principle likes the idea of site-IDs and would care to work 
> with me on this?
> 
> Thanks,
> 
> PF
> 
> 
>

---

From: Dan Lanciani <[email-masked]>
Date: Tue, 20 Feb 2001 15:41:17 -0500 (EST)

Nathan Lutchansky <[email-masked]> wrote:

|First, I can see a lot of advantages to having unique, non-routable site
|prefixes.  One big advantage I can see is that VPNs can be created between
|arbitrary sites without worry of renumbering either site.  If we can find
|a way to implement site IDs in a reasonable manner, it would be a big win
|for IPv6.

[...]

|Why not leverage the global DNS system to do this?  DNS can be used to
|assign ownership and do duplicate detection, and can also solve the
|two-faced DNS problem.  Here's how:

[...]

|VPNs between arbitrary companies could easily be created.

[...]

|The only possible unfortunate side effect that this may have is that, as
|Steve pointed out, some unscrupulous ISP may begin advertising site-local
|prefixes into the global routing tables.

Or, turning this into a positive, when the (supposed) routing problem is
solved and large routing tables can be accommodated, such advertising could
be allowed.  This would make for a smooth transition away from non-portable
address space at some later time.

|This system is probably the most flexible and low-overhead of all those
|proposed in the last week, and requires relatively few changes in existing
|code.  My apologies if this scheme has been proposed already, but I'm on a
|slow link and searching the archives is rather painful.  -Nathan

I don't know if your specific scheme has been proposed but, with a little
tweaking to support automatic VPNs, it becomes essentially equivalent to
my proposal for identity addresses (addresses that you can actually own
without depending on the ISP not to pull the rug out from under you).  I
think your proposal exposes a bit more of the implementation to the application
(or at least application-level resolver code), but I'd happily support it
anyway.  Either approach sidesteps the large-routing-table issues by pushing
the initial lookups onto the DNS (a system which must be able to handle the
load if IPv6 is to work at all) and distributing the rest of the routing
decisions.  I'm not sure that your approach would help with multi-homed sites
as much as mine would, but that's probably a small price to pay for keeping the
addresses in a form which could later simply be injected into the core routers
when/if that becomes supportable.

In the past there has been strong objection to allowing end users to own any
kind of global (provider-independent) unique address (or address-like object)
even if it is not directly routable.  Perhaps now that 6to4 has let the genie
out of the bottle it will be more palatable to allow users not fortunate enough
to own any IPv4 space to play as well...

				Dan Lanciani
				[email-masked]