Subject: RE: Limiting the Use of Site-Local

From: Margaret Wasserman <[email-masked]>
Date: Wed, 30 Oct 2002 16:53:35 -0500

>
>Actually, a router can forward link-locals between interfaces on the
>same link. In particular, a router can forward a packet with link-local
>dest and/or source back out the interface from which it arrived (and
>presumably generate a Redirect too).

Good point.

>If you are implementing link-locals properly, it's really very little
>additional code to support site-locals. At least that's my experience.

I agree that, in terms of _stack_ complexity, site-locals don't
add much.  The additional complexity comes at other layers -- routing
protocols, DNS, applications, transport protocols, management apps,
etc.

Some of these complexities don't apply to link-local addresses, because
no one expects to put them in the DNS, exchange them in routing protocols,
or use them in upper layer protocols, except as a last resort (when the
single link _is_ the entire network).  I am essentially suggesting that
we treat site-locals the same way -- use them only as a last resort
when the site _is_ the entire network.

Link locals already cause problems for management protocols.  For example,
it won't be possible, using the IP address of a BGP peer from the MIB
(which will be link-local), for a management station on another link
to find that host and communicate with it...  So, it probably would
have been better to use global addresses for routing protocols and
limit their hop count to 1.  Oh, well.

Margaret

--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 31 Oct 2002 09:20:54 +1100

> no one expects to put them in the DNS,

	This is tunnel vision.  The only reason that no one expects
	them in the DNS is that we havn't added support for them
	in the DNS.

	I think LL (and SL) should be in the DNS.  Doing this actually
	simplifies things.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [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: Wed, 30 Oct 2002 17:54:39 -0500

well, that and the minor consideration that current DNS architecture 
assumes that names are global and that queries return consistent results 
everywhere.

Keith

---

From: Rob Austein <[email-masked]>
Date: Wed, 30 Oct 2002 18:27:55 -0500

> 	I think LL (and SL) should be in the DNS.  Doing this actually

Only if you then revise all the application programs to let you
specify the scope ID that provides the context for the name, whether
the scope ID is represented as a DNS name or not.

Please think about this for a minute.  It's bad enough for
applications that are driven by a human who can type or click or
whatever from a list of possible scopes, but what do you do for
programs like MTAs?  If you're longing for a return to the days of
fee!fie%foe@fum email addresess (or even [email-masked].#Chaos),
you're on the right road.
--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 31 Oct 2002 10:30:05 +1100

> assumes that names are global and that queries return consistent results 

	So.  I've shown how to add them and return consistent results
	everywhere.  The only reason we don't do it now is that we
	havn't added support to do it.

	Did you bother to actually read what I have posted in the
	last couple of days?  Your responses to this and previous
	mail make me think that you are not actually paying attention
	to what is being sent.  Rather you are locked in a crusade
	to kill SL and are ignoring anything which will actually
	address the problems you raise.

	Mark

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 15:59:51 -0800

Mark.Andrews wrote in response to Keith:
> ... Your responses to this and previous

That summarizes it well.

Tony

---

From: [email-masked]
Date: Thu, 31 Oct 2002 10:59:45 +1100

> you're on the right road.

	No Rob.

	I'm talking about 1 name with multiple addresses being
	returned in multiple scopes.  I'm taking about having
	getaddrinfo() then filter out the inappropriate addresses
	using local knowledge and setting sin6_scope_id.
	This deals with 99.9% of address lookup.

	It allows you to have your printer in the DNS with SL and
	LL address and look it up by name (getaddrinfo()) without
	having to implement two faced DNS.  It also allows you to
	lookup a remote print spooler with a only the GA's returned
	again by getaddrinfo().

	If you want to see all the address which are outside your
	local scope you would do raw lookups or we could come up
	with an API that returned all the addresses with the
	scope information.  sin6_scope_id is local to the machine
	so getaddrinfo() is not appropriate for this case.

	See Message-Id: <[email-masked]>
	for details.

	Mark

---

From: Rob Austein <[email-masked]>
Date: Wed, 30 Oct 2002 19:30:41 -0500

> 	using local knowledge and setting sin6_scope_id.

Via this mapping table thingie, which I suppose we could configure
easily enough using DHCPv6.  So what happens when the mapping table
isn't configured, is misconfigured, or somebody passes a raw scoped IP
address into some other scope?

> 	See Message-Id: <[email-masked]>

I read it.  I even replied to it.  I think it's a fine solution to one
aspect of a more fundamental problem, and I remain unconvinced that
the more fundamental problem is worth solving.
--------------------------------------------------------------------
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: Wed, 30 Oct 2002 20:01:32 -0500

>         havn't added support to do it.

adding support to applications to deal with address scopes is an
extremely nontrivial task.  but feel free to start on it.  when you're
done, let the rest of us know.  forgive us if those of us who don't
believe that all of this complexity is justified don't help out.

>         address the problems you raise.

no, I'm in a crusade to make IPv6 suitable for applications. and 
I'm ignoring handwaving about the ease of making sweeping changes
to accomodate needless complexity. 

If we can justify SLs on non-isolated networks at all then I'm happy 
to consider ways of putting them in DNS - anything is better than 
putting them in ordinary IN AAAA records.  But putting SLs in the 
DNS doesn't solve the problems they cause.

Keith

---

From: [email-masked]
Date: Thu, 31 Oct 2002 12:04:03 +1100

> address into some other scope?

	If it isn't configured you get globals only.

	Misconfigurations are undefined.

	A raw scoped address without scope is meaningless unless
	the host is single homed (LL) or single site (SL).  Hopefully
	the kernel will reject messages sent to ambigous address
	(sin6_scope_id == 0). The kernel is in the position to
	determine whether the node is single homed or single sited.

> the more fundamental problem is worth solving.

	Fare enough.

	Mark

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 20:11:47 -0500

> That summarizes it well.

and it appears to me that you are trying to attack me personally
rather than actually make credible arguments in favor of using SL.
--------------------------------------------------------------------
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: Wed, 30 Oct 2002 20:18:47 -0500

No, Mark, it doesn't, because the party that calls getaddrinfo
isn't necessarily the same as the party (and doesn't share the same
scopes as the party) that uses the addressees.

there are numerous good reasons that many apps do NOT do a DNS lookup 
each time they want to contact another host.

Keith

---

From: [email-masked]
Date: Thu, 31 Oct 2002 13:27:32 +1100

> scopes as the party) that uses the addressees.

	List the number of application thay just lookup a address
	then connect.

	Now list the number of applications that lookup a address
	for a third party.

	My bet is that the result will be over 1000 to 1.

	Also if you read the mail I admitted that there was a class
	of applictation where getaddrinfo() is not enough.  That
	those applications would need a different API to look up
	the addresses (or call the DNS directly).

	However that class of application could still determine
	approriate remote SL to use by matching against the scope name
	in the SA6 record and returning the address along with the
	scope name.
 
> each time they want to contact another host.

	Which is irrelevent as to whether a address is in the DNS or
	not.

	Mark

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 Oct 2002 22:34:06 -0500

>         My bet is that the result will be over 1000 to 1.

a. the # of applications is not a good indicator of the effect on
   the internet's utility

b. there are tens of thousands of apps that most of us have never heard
   of, that are vital for some purpose or another.  the value of the
   internet is not just in being able to support the apps that everyone
   has heard of, it's in its flexibility to support a wide variety
   of communications needs

>         in the SA6 record and returning the address along with the

yes, but that's still trying to teach a pig to sing.  
giving the pig sheet music might help, but not much.

>         Which is irrelevent as to whether a address is in the DNS or

it's just one reason why putting SLs in the DNS won't solve the problems
associated with SLs.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 22:14:44 -0800

Keith,

I am not trying to attack, to the contrary I think I have simply been
focused on defending a discussion settled so long ago that most of the
interested parties have assumed it is done and they don't need to stay
engaged. The only personal comment I am aware of was pointing out that
you were asking for people to state why SL was necessary, but every time
someone did you dismissed it out of hand because it didn't fit your
policy of how a network should be run. That was not intended as a
personal attack, so much as a wake up call to what was going on.

You have a valid argument about making developers of multi-party apps
aware that scope boundaries represent a new adventure that is not well
defined yet. That does not automatically translate into the condition
that all uses of SL are invalid (particularly 2 party ones). So instead
of trying to blanket ban or restrict use of SL, state where the known
pitfalls are, and let's move on.

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, October 30, 2002 5:12 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Limiting the Use of Site-Local 
> 
> 
> > That summarizes it well.
> 
> and it appears to me that you are trying to attack me 
> personally rather than actually make credible arguments in 
> favor of using SL.
>

---

From: Rob Austein <[email-masked]>
Date: Thu, 31 Oct 2002 05:02:10 -0500

At Wed, 30 Oct 2002 22:14:44 -0800, Tony Hain wrote:
> 
> ...I think I have simply been focused on defending a discussion
> settled so long ago that most of the interested parties have assumed
> it is done and they don't need to stay engaged.

Since a check of the mailing list archive shows that the bulk of the
traffic on site-local addresses over the years has come from people
who quite obviously are still here (a tribute to their stamina, if not
necessarily their good sense :), I'm curious about who these many
interested but disengaged parties might be.

I would also respectfully suggest that comments like:

At Wed, 30 Oct 2002 14:57:29 -0800, Tony Hain wrote:
>
> Please don't interpret the ranting of a few as representing anything
> close to consensus of a very large WG.

are inappropriate, and say more about how much attention you're paying
to the feedback we're getting from implementors than they do about
whomever you were trying to insult in that message.
--------------------------------------------------------------------
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: Thu, 31 Oct 2002 08:10:41 -0500

> engaged. 

I guess I disagree that the most interested parties - the developers
of applications - were ever in the loop.  This is IMHO IETF's biggest problem -
working groups narrowly focused on specific problems routinely create 
large difficulties for interests that aren't involved in the working group.  
Zeroconf is another good example - by imposing LL addresses on IPv4
it is creating many of the same problems for v4 apps that SLs cause
for v6 apps.  (actually a couple of additional ones - at least v6 SLs 
are stable)

> The only personal comment I am aware of was pointing out that
> policy of how a network should be run. 

Well first I have this bizarre idea that networks exist to support
a variety of applications - granted that this doesn't apply to _all_
networks, but I think it applies to most of them.  Second I have this
bizarre idea that if you want to impair operation of networks and
of applications in the name of security, you should actually get a
considerable security benefit from that impairment - and I don't think
that has been demonstrated.

> pitfalls are, and let's move on.

I think it makes far more sense to restrict or discourage use of SLs by 
networks than to restrict use of SLs by certain kinds of applications. 
I can't see any harm in doing the former, and doing the latter impairs 
the ability to run off-the-shelf multi-party apps anywhwere in the network.
In effect it drastcially limits the market and the deployability of 
multi-party apps.  

In theory NATs wouldn't cause problems if they were only deployed on 
networks where they were known to not interfere with the apps that
were running on those networks.  In practice people have expected to
run a variety of apps on NATted networks anyway, and no amount of 
complexity has produced a general-purpose solution to that problem.
We need to restrict use of SL so that IPv6 doesn't end up causing most
of the same problems for apps that NATs in IPv4 do.

Keith