Subject: RE: Proposal for site-local clean-up

From: "Brian Zill" <[email-masked]>
Date: Mon, 18 Nov 2002 22:37:05 -0800

Erik Nordmark writes:
> I don't think stable addresses per se is the key
> thing - it is the robustness of the communication
> that is important.

I agree with this.  However, the minimal degree of robustness is working
at all - something which requires some address of some sort.  There
needs to be a way to get an address when you don't have a provider.
This means either scoped addresses as we have defined them already (and
in multi-link locations, this means either site-local or multi-link
subnet routers and link-local), or some sort of provider-independent
address (note there are various types of these as well, depending upon
whether we believe they should be explicity non-routable, or privately
routable between multiple non-connected 'sites').

> This robustness has at least two factors that are
> relevant in this discussion: the stability of the
> addresses, and the leakage of non-global scope
> addresses. I think the question is how to 
> weigh those together.

Regarding leakage of non-global scope addresses, I don't see this as a
major problem given the way our current scoped addresses are defined.
Having an explicit prefix makes it straight-forward for border routers
to filter them.  The scope-id in the sockaddr field makes it easy for
applications to know on which interfaces an address is usable and to
whom it is legit to pass (something that isn't true for the 169.254.x.x
"link-local" addresses in v4 today).  I'd be more worried about leakage
of provider-independent addresses which don't share an explicitly
non-routable prefix.

> In any case, for a home user I suspect that the 
> value/importance of local communication would
> typically be less than the value/importance of
> global communication.

As I mentioned in my last message on this topic, I believe a lot of the
argument around site-locals is really about expected usage models.
Personally, I would expect the opposite of what you say above.  Home
users watching a movie on their IPv6-enabled television screen in the
living room (which is streaming in from the media server in their
basement) won't be happy if their movie quits because their kid just
dialed into the Internet and the  resulting global address advertisment
required all site-local communication to stop.

More generally, I don't want IPv6 to be just for the Internet.  If we've
done it right, IPv6 will be used for all sorts of communication between
lots of devices which typically don't have network connectivity today.
I'm worried that this working group too often sees things in terms of
only traditional computers as the hosts, and the routers all belonging
to organizations which have administrators to run them.  We shouldn't
try to dumb down IPv6 so that it only works well in the environment IPv4
was conceived in.

> Finally, an enemy to robustness is complexity.
> Site-locals add complexity in many places;
> applications, two-faced DNS configuration, etc.

Yes, needless complexity is bad.  But site-locals don't add any
significant complexity to applications (which I think I've demonstated
enough in too many emails already).  Many existing IPv4-only sites run
two-faced DNS today, so there clearly are people out there who think it
is worth it for reasons that have nothing to do with IPv6.  If we think
that's not optimal, we should be thinking about figuring out why they
run their IPv4 networks that way today and come up with a better
solution for them using IPv6.

> So let's not loose sight of the fact that the
> goal is a robust network.

Sure.  And scoped addresses have the potential to make the network more
robust (I'd say that link-locals have already proved their worth in this
regard).

--Brian

--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2002 15:28:16 +0100 (CET)

> routable between multiple non-connected 'sites').

For the disconnected site I think the site-locals work just fine, and
I haven't seen any strong arguments against using site-locals for
a disconnected site.
As many others have pointed out the complexity is not associated
with the case of the disconnected site.

> to filter them. 

True for IP packets which is not my concern; the leakage is likely to
happen in higher-level protocols. We don't want the router to filter or
modify those.

> The scope-id in the sockaddr field makes it easy for

The scope-id makes it possible, which is very good, but it doesn't make it
easy IMHO.
As an example of what every application needs to do you can talk
to the folks that did the work for SCTP (not that SCTP is an
application, but it does pass IP addresses around when establishing
connections to be able to use alternate paths). My understand is that
understanding what needs to be done with limited scope IPv6 addresses
was a major complicating factor in this work.

We can get such things to be done well for work done in the IETF
even if it is extra work. But for applications developped all over the planet
I'm far from convinced that they will provide robust solutions when there
is a combination of site-local and global addresses.

> required all site-local communication to stop.

Nor will they be happy is the download of the move in the afternoon didn't
happen because the L2 link dropped and got restablished with different IPv6
addresses.
If the ISP provide the disservice of unstable IP addresses I think we have
a large class of problems. The fact that site-local addresses might ameliorate
some of those problems doesn't magically make such ISP disservice useful.

> try to dumb down IPv6 so that it only works well in the environment IPv4

I think it is fine to use IP technology outside the global Internet.
It might even be fine to subset the IP technology to do this.
But what doesn't make sense in my mind is to have the desire to
use IP technology outside of the global Internet cause significant
additional complexity in the technology.

> enough in too many emails already). 

Time to agree that we disagree on this point. (Unless you are talking
about site-locals being restricted to the disconnected site case.)

> Many existing IPv4-only sites run

I think, but I'm not certain, that most of the large sites that do this
have completely different DNS content in the two-faces i.e. it is more
like two separate DNS services than two-faces of the same DNS database.
That is, the DNS outside the firewall contain a subset of the RRs and 
names, and there isn't necessarily a dynamic update path between the
two DNSes.

Do you have examples of folks that have small setups of two-faced DNS
where e.g. dynamic DNS update works while still keeping site-locals
on the inside and global addresses visible through both faces?

> robust (I'd say that link-locals have already proved their worth in this

I must have missed the proof. Do you have a pointer to something which
captures normal users, dynamic DNS update, application development 
handling multiple concurrent scopes, etc?

  Erik

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Nov 2002 11:26:00 -0500

> enough in too many emails already). 

this is only true if globals are always available to any node that
potentially participates in an application that communicates off-site - 
which essentially means any node in any network which has an external
connection.  

in other words, it's not that the problems with SLs can't be minimized
by imposing a discipline on their use - it's that too many people want 
to use SLs in too many different ways to allow that to happen in practice. 

Keith

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 20 Nov 2002 16:56:46 +0100

> with the case of the disconnected site.

Agreed, however my problem with this is that there is no way to enforce 
this and people will run away and connect anyway. I think that we also 
need to address this in whatever solution we decide on...

- kurtis -