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 PROTECTED] -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
