Subject: Why would I use a site-local address?

From: Andrew White <[email-masked]>
Date: Fri, 01 Nov 2002 17:56:24 +1100

Let me weigh in late to offer an answer to the core question: Where would I
use a site-local address?

In a network with a statically allocated global IPv6 address, site-locals
are indeed redundant.  But:

- IPv6 is built on the assumption that networks may renumber

- Leaf networks currently are, and in future may well be, constructed with
transient prefixes.

- These leaf networks may not always have global connectivity.

Consider a network using a dialup IPv4 connection to the router.  While this
connection is up, the network has a valid 2002:....:..../48 prefix.  If the
network goes down, or changes IPv4 address (and yes, this does happen),
suddenly all our prefixes change.

Prefix renumbering isn't too bad, since our IPv6 apps are supposed to be
able to handle this.  But while there is no prefix, there's no addresses. 
Connectivity over the site is lost pending availability of a new global
prefix.

Enter site locals.

A solution is to allocate a site local prefix for the leaf network, as well
as any global prefix/es that happen to exist.  All these prefixes are given
to the routers and hosts within the site.  The border routers don't route
site local addresses outside the site, and should also drop any packets with
a site local source address.

Sensible host source address selection rules are required.  eg: prefer the
source address that matches most closely with the destination address, and
prefer globally scoped to site-local addresses (unless perhaps the target is
also site local).

Naming also can be site scoped.  See:
  draft-williams-dnsext-private-namespace-01.txt
for a site-scoped naming proposal.

Under this model, there really is no need for multiple site-local scopes. 
The bits between /16 and /48 can be used to subdivide the site local space
for manually partitioning, or else the full fec0::/48 space can be used and
include whatever it can reach.

As to router defaults, I'm inclined to suggest that backbone routers should
perform site-local filtering unless explicitly configured to allow it
between particular interfaces.  Routers used within a site should freely
route, but it's probably safer to require site-local forwarding to be off by
default.  People wanting more sophisticated configurations (with multiple
different interfaces in multiple different sites) can manually configure how
packets are to be routed.

Site scoping boundaries can be bypassed through either tunnels or
encapsulating addresses in higher level protocols.  However, in this case
things will simply fail to work, which is acceptable.  With some effort,
spoofing attacks are possible, but it is well known that hosts should not
trust simple address based authentication for serious security.

-- 
Andrew White                [email-masked]
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Fri, 01 Nov 2002 07:11:25 -0500

networks with intermittent connectivity might be a valid case for use
of site-locals, though giving such networks a non-routable global prefix
would cause fewer problems for applications.

also, you're correct that when using 6to4 with dialup v4 providers
the prefix is likely change each time the network is connected
(unless special arrangements have been made with the ISP), however 
this does not necessarily hold for native v6 connectivity.  with v6 
there is not as much need to reuse addresses for dialup lines.  IMHO 
the decision to recommend address reuse on dialup lines should be
reexamined for v6.

it's not reasonable to assume that v6 applications will cope with rapid 
prefix changes.

the problem with the idea that site-locals should be favored over
globals is that this is exactly the wrong rule for some applications
and on some networks.  as far as I can tell, address selection rules
need to be derived from a combination of application requirements 
and local network policy.

Keith

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 2 Nov 2002 15:13:32 +0100

To add to this.....

6to4 is a transition mechanism. One of the major ideas behind IPv6 is 
to address the address shortage - which has lead to among other things, 
dynamic allocation of IP addresses for dial-up.  I do understand that 
there is a transition problem here, but I hope we are not arguing for 
site-locals as a permanent solution for dial-up networks.

- kurtis -

---

From: Andrew White <[email-masked]>
Date: Mon, 04 Nov 2002 13:51:18 +1100

> would cause fewer problems for applications.

[...]

> and local network policy.

Agreed.  But for the purpose of address selection, a non-routable global is
functionally equivalent to a site local - it's an address whose scope is not
the "global IPv6 internet".  And as soon as we introduce addresses whose
scopes are not all functionally equivalent, we have an address selection
problem when multiple scopes are valid.

We also need to consider whether our "site" prefixes are to be
administratively or automatically configured.  If administratively
configured, I lease both prefix and connectivity from an ISP, install this
into my top-level router / prefix distributor, and go from there.  The
prefix is valid regardless of whether I have connectivity or not.

But what if:

- I don't want (currently) to connect to an ISP?

The site-local prefix provides a good default.  Now, as soon as I get a real
prefix I deprecate the current site local and initiate renumbering with the
new prefix.  But if it's illegal for the two to co-exist, I must kill ALL
active internal connections at the point I make the switch.  It would be
nice to at least have a deprecated period on the SL.

- I have a small, roving network (PAN, car, plane, ...), with the gateway
latching to hotspots?

My external address could change every 10-15 minutes.  Internal nodes
wanting external connectivity should be prepared to re-establish their
connections frequently (ie long running tcp session on roving PAN is
probably a bad idea).  However, I don't really want every external switch to
clobber my internal connectivity.

A last thought:

- Non-routable global prefixes cause more problems than they solve.  The
/advantage/ of fec0 is that it can be used in the total absence of external
configuration information, and work.  A NRGP requires all the configuration
effort (both interfacing with an allocating authority and installation into
the network) of a global with all the scoping issues of a site local.  Why
not just get a true global?