RE: A use for site local addresses?

["Jeroen Massar" <jeroen@xxxxxxxxx>]

Mike Saywell wrote:

> On Wed, Mar 26, 2003 at 05:19:31PM +0100, Jeroen Massar wrote:
> > Mike Saywell wrote:
> > 
> > > I think everybody is in agreement that in your typical IPv6
commercial
> > > or home deployment site-locals should not be used, the point 
> > > is that there are other environments where site-locals have a
legitimate 
> > > use and which (imho) there has been no reasonable proposed
alternative
> > > as of yet.
> > 
> > Name those environments then.
> 
> Well off the top of my head...
> 
> #1
> An initially isolated ad-hoc network which is larger than a single
> subnet.  The ad-hoc network may become attached to the global internet
> periodically, each time via a different ISP.  One example of 
> this could be on a boat which only gets global connectivty whilst in
port.

That's a good example.

The boat could use a /48, at least I think most cruisers need something
similar like that size, from their office allocation.
Eg "The Boat Company" requests 2 /48's from their office upstream and
use one of them for their boat. If they have more than 200 boats they
could even go for a TLA, though I doubt you can convince a RIR
that a boat is a client and that they really need that much space.

Btw: Geographical based multihoming won't work, unless there is Sea-Geo
;)

> #2 (related)
> For an ad-hoc network to auto-config it needs an address range to use.
> It's extremely limiting to confine them to a single subnet.
> 
> #3 (to be found at the root of this thread)
> A provider independant (i.e. no upstream ISP) network which aims to
> provide transit between 2 or more networks (which may or may not be
> public).

Effectively all these three boil down to one thing:
 - globally unique addresses
 - not connected to the internet

A place to register globally unique, but non-internet-connected
address space would be the best place IMHO.
This will take quite some effort but it is quite probably the
best way to avoid problems like mergers.

> I'm sure there are many others...

If we can't identify them, we can't have a solution for them.

Greets,
 Jeroen


--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------