Subject: RE: Limiting the Use of Site-Local

From: "Richard Draves" <[email-masked]>
Date: Mon, 28 Oct 2002 23:00:03 -0800

Gee whiz, I really can not keep up with this thread.

Why did I call it "craziness"?

First, because it's not productive to revisit old design decisions.
Scoped addresses and the notion that nodes would have multiple addresses
of different scopes are design decisions from many years ago.

Second, scoped addresses are an important part of the IPv6 architecture
because they reflect today's internet architecture. The internet is no
longer a fully-connected network of nodes with static addresses. (I get
the impression that some participants in this thread would like to turn
the clock back 20 years!) The world is more complicated now. Sites have
strong boundaries; firewalls and two-faced DNS are commonplace for
enterprise networks. Addresses occasionally change.

The idea of restricting site-locals to completely disconnected networks
doesn't make much sense to me. It's like saying you can have them but
not really. How would we handle intermittently connected sites, or
partially connected sites? What would happen when a network that is
using site-locals gains global connectivity? This seems like a recipe
for encouraging v6 NAT, which is not something we want.

In my opinion, IPv6's explicit architectural support for multiple
addresses and scoped addresses are two of its advantages over IPv4.
Because they're baked in from the start, applications can do the right
thing with scoped addresses. And one way or another they will be there
eventually (look at how scoped addresses have crept into IPv4), so it's
better if applications that need to know about them are coded that way
from the start.

In addition to the main architectural point above, there are some
specific advantages of site-local addresses that others have mentioned,
but let me put my own spin on them:

1. Site renumbering. Preserving long-lived connections across
renumbering is not so compelling - I think most renumbering events can
be planned for a large enough time-scale. More interesting is that
various random static configurations that use site-locals do not have to
be tracked down and updated.

2. Auto firewall. The site boundary is automatically a firewall for the
site-local prefix. This is a simple model, easy for administrators to
understand and easy for applications to recognize and cope with. Yes you
can also put up filters for global prefixes, but that's more
error-prone. (Let me throw out an idea that just occurred to me - some
simple defaults in router configuration could help prevent errors in
site boundary configuration. For example if the router is configured to
run BGP, then by default it could assume its interfaces are in separate
sites.)

There's the question of how much burden do scoped addresses create for
applications. For most applications, even on multi-sited hosts, there's
no burden at all if they are coded using sockaddrs. Distributed
applications that send around addresses do have to cognizant of scoped
addresses. However this is not hard to deal with. For example I checked
on how one such distributed application that is being built at MS
handles this issue. The application looks at the scope of the
correspondent and sends its addresses of matching scope. In other words,
when talking to a global address you send your global addresses and when
talking to a site-local address you send your site-local addresses.

There's the question of implementation effort for the network stack to
support scoped addresses. This is hard to quantify but I would say it
was small. (And necessary regardless of site-locals, unless link-locals
are next up for revisionist architecture.) The additional code in source
& destination address selection was about 10 lines each. The additional
code in route lookup and destination cache management was worse, maybe
100 lines. A scope-id needs to be passed around as an argument to
various functions so there was a very small impact in many other places.

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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 29 Oct 2002 16:37:54 +0900

>talking to a site-local address you send your site-local addresses.

	application on multi-sited host is difficult, as
	- not every protocols are friendly with scoped addresses (scope
	  identifier get stripped off during transit)
	- even if you successfully pass around scoped addresses with scope
	  identifiers, scope identifiers (view of scope) differ by node.

>various functions so there was a very small impact in many other places.

	i would comment that it is very hard to get multi-sited router
	implementation right (specifically routing protocols).
	see descriptions by NEC guys a couple of months ago - it is a big mess.

	so my take is as follows:
	- we should at least forbid nodes from joining multiple sites.
	  it will simplify things a lot.
	- we should document behavior of site-border routers,
	  every gory details.
	this is the bottom line.

	i'm still a bit concerned about the use of scoped address in general, 
	as it will cause confusion when scoped address leaks out of site
	in application payload (like email foo@bar@baz notation or whatever).
	but i feel it too late to kill it.

itojun

---

From: Keith Moore <[email-masked]>
Date: Tue, 29 Oct 2002 09:58:35 -0500

> of different scopes are design decisions from many years ago.

yes, they're perfect examples of second-system effect.   to the
extent that we can deprecate them we're doing everyone a favor
and making IPv6 much more usable.  IPv6 is a good design with a 
few warts which we'd be better off without.  A6 was one wart.  
SLs are another.   fortunately we can eliminate the warts without
doing harm to IPv6. 

> because they reflect today's internet architecture. 

when you have a train wreck, you don't call the resulting jumble of
cars and debris 'architecture'.

> The internet is no
> enterprise networks. 

yes, but people have had to resort to poor solutions because of a shortage
of address space in v4.  that and some really bad ideas have been tried
which are now being found wanting.

nobody is suggesting that sites abandon firewalls, or that sites be forced
to advertise all of their hosts' addresses using DNS.  what is being
argued rather forcefully is that having site-local addresses (and having
apps be expected to use them) adds a lot of complexity without providing 
a significant benefit in return.

> not really. 

no it's like saying that SLs are a bad idea except perhaps for
a few corner cases where they don't do much harm - and rather 
than burdening everyone  with having to deal with SLs we should
discourage their use except in those corner cases.  in other words,
we're just recognizing reality.

>How would we handle intermittently connected sites, or
> partially connected sites? 

give them globals, of course.

> What would happen when a network that is
> using site-locals gains global connectivity? 

same as when a network changes providers.  they have to renumber,
and there's a transition period during which both kinds of addrs
are used.

> This seems like a recipe

no more than any other kind of renumbering.  we need to work out a
complete and convincing renumbering  solution but SLs aren't a part of 
that.

> thing with scoped addresses. 

no, it doesn't follow.  first because nobody has been able to define
what the "right thing" is - or to be more accurate, it looks like the 
"right thing" is "avoid SLs at all costs".  second because this essentially
expects apps to perform routing in the absence of any routing information,
and anyway that's the network's job.  in other words,  just because
SLs have been in the address architecture for a long time doesn't mean
that their effects, or how to use them, were understood.  when apps
people start looking at these things the emerging understanding is that
they're a bad idea except for some corner cases where apps don't have
to deal with them anyway.

one way to put it is that SLs should be discouraged to the extent
that a default set of addr selection rules (_not_ the ones currently
in effect) will work just fine.
 
> And one way or another they will be there

about the only benefit to having them be visible to apps is so that
apps can avoid using them - and this only works if sites are discouraged 
from using them.  expecting apps to make reasonable decisions about which 
addrs to use in which contexts is extremely naive because apps simply 
don't have access to the necessary information to inform those decisions
and because they don't want to absorb that complexity even if they did
have access to that information.

> be tracked down and updated.

I agree that this is an interesting idea.  

> site-local prefix. 

actually it seems about as easy for routers to implement a 
similar function for globals.  what SLs give you is the ability
to mix and match routable and non-routable addrs and you can
control whether a host or app has external acces depending on
which address you tell that host or app to use. but this isn't
a very secure way of doing access control.

> Distributed

it doesn't work. then you can't do referrals between sites.

Keith