Subject: RE: A use for site local addresses?

From: "Michel Py" <[email-masked]>
Date: Wed, 26 Mar 2003 14:19:00 -0800

> Pekka Savola wrote:
> The point you're missing is that RFC3056 requires/recommends
> the 6to4 pseudo-interface implementations to discard packets
> received-from/would-be-sent-to 2002:FOO, where FOO is private.
> This is not a problem *unless* some node in your network is
> configured with a 6to4 pseudo-interface -- and I believe many
> of them are (e.g. Windows boxes, etc.).

That's precisely my point: this is a feature, not a bug. A host MUST NOT
use a private address to talk to the outside of its site. Very close to
the top of the list of what needs to be done to insure this is to remove
all 6to4 pseudo-interfaces.  Therefore, using 2002::<RFC1918> as a real
6to4 site and not with individual hosts using their own IPv4 address as
the 6to4 address does actually enforce the removal of 6to4
pseudo-interfaces because if they exist it won't work at all (if the
implementation enforces RFC3056).

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: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Mar 2003 00:01:44 +0100

> implementation enforces RFC3056).

That's correct as long as the RFC3056 code is only enabled in the site
border router. If it's enabled in any internal routers, the packets will
get black holed internally.

Also if you have any hosts that support 6to4, which is not the model
described in RFC3056 but is shipped in at least one o/s, strange things
may happen.

  Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 27 Mar 2003 01:11:46 +0000

> described in RFC3056 but is shipped in at least one o/s, strange things

Indeed.   But my (perhaps not well written) comment was based on Mike's
requirement to have a multi-site community network, e.g. a number of
DSL or dialup homes (who should by current RIR guidelines receive site 
/48's from their upstream providers) who also participate in a routed mesh 
WLAN network across a city (i.e. homes with 802.11b).  

The WLAN infrastructure needs its own address space, but site locals are 
desirable for the home networks connected via WLAN in the event that any 
home is disconnected.  Also, transmission across the WLAN is likely to 
give better performance than routing out and back in through the DSL or 
dialup.   If such homes get /48's, then the community mesh network needs 
more than a /48, which discounts 6to4 as a "site" solution, esp. if the 
infrastructure were v6-only (which to be fair is not yet a likely reality).

In such a case there is no single upstream provider (the homes may subscribe
to any service provider).   Of course some community networks may only have 
one (fatter) upstream.  But the more interesting ones allow you to select 
from multiple providers (e.g. open.net in Sweden) where you use site-locals 
to access community content until you authenticate to an external provider,
at which point you receive global address(es).

The current answer seems to be:
 a) Pick someone else's global /32 and use that
 b) Pick some other random /32 prefix
 c) Pay $$$ to get LIR status to get a global /32
 d) Request as many GUSL-based /48's as are needed
 e) Use geo-addresses
 f) Use fec0 space anyway

Option c) is out as it costs real $$$.  Options d) and e) are not defined 
yet.   So we might as well accept that people will use fec0, but simply not 
give that prefix any special scope treatment.  Is it the scope rules that
cause the problems, or the definition of an available prefix?  As Michel
says, we've been here with IPv4 before.  At least with v6, market forces
should lead people away from NAT (if they want the nice new v6 apps).

I'm happy to see the back of site-locals, so long as current (and most
importantly) future network requirements can be met without them, and at
the same cost as site locals (free).

Tim