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

From: "Brian Zill" <[email-masked]>
Date: Thu, 14 Nov 2002 00:43:07 -0800

Keith Moore writes:
> In either example the problem is solved if B and C
> have global addresses, and all referrals filter
> SL addresses.

Yes, nodes communicating globally should have global addresses, and then
there is no problem.  (Although again, I think you're being overly
draconian with the second bit since referrals only have to filter
site-locals from leaving their site as opposed to filtering all
site-locals, but that's a nit).

It seems what we're arguing about here isn't technical at all.  These
arguments keep circling around our preconceptions about how we expect
IPv6 networks will be set up and used.  I believe that applications
expecting to communicate globally will have access to global addresses.
Without such access, I don't think it is reasonable for an application
to expect global connectivity.

> But that's not realistic given current address
> allocation policies.

I don't follow this.  Are you saying it is hard to get global IPv6
addresses?

> > I also don't mean that an app can get confused and
> > it will fail to connect to the correct proper
> > destination if it uses a scoped address at the
> > wrong time.  Yes this can happen, but it's still
> > part of the address selection problem, not a basic
> > problem with an app.
> 
> Address selection doesn't solve this problem.  Basically
> what the app has to do is implement its own addressing
> (so it can disambiguate hosts using the same address)
> and routing (so it can operate across site boundaries - 
> because this will be necessary for many apps).

Not really.  Since the scope-id is part of the sockaddr_in6, the full
address isn't ambiguous.  Apps don't have to "implement their own
addressing".  Or routing, for that matter.  Apps wanting to operate
across a site boundary will need to use global addresses (or an
application-level proxy on a node connected to both sites).
  
> > I don't see the same thing happening with site-local's,
> > everyone agrees that they aren't a v6 NAT replacement
> > so apps are not allowed to propagate site locals
> > outside of the site boundary.
> 
> No, everyone does not agree on that.  First because apps 
> aren't aware of topology so they don't know when they're 
> propagating an address outside of a site boundary.

Sure they do.  I've gone over this before.  If you're an app, don't
provide a site-local in a referral to anyone who isn't themselves
communicating with you via a site-local.  And also provide the global
(or even just the global, if the app doesn't care about being robust
against renumbering or global prefix loss).

> Second because expecting apps to be aware of topology
> imposes too much of a burden on those apps.

They don't need to.  See above.

> Third because if those apps don't have alternatives to
> using SLs they'll be forced to use them.

Please explain why they won't have global addresses if they have global
connectivity.  The only apps that don't have an alternative should be
those on disconnected networks, and people seem ok with letting them use
site-locals.  It's the opposite freedom I want to preserve, to let apps
have the alternative to use a site-local instead of a global should they
be inclined to do so for communication within their site.

> Fourth because if the apps reliably do have alternatives
> to SLs (for networks that aren't isolated) then there's
> not much reason to have SLs at all.

Intermittently connected networks.  I believe you agreed to this point
in another thread.

--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: Keith Moore <[email-masked]>
Date: Thu, 14 Nov 2002 08:38:44 -0500

> there is no problem.  

they don't need to be communicating globally, or to have connectivity to 
the public Internet.  all they need is to have *some* node in the app
that is communicating off-site.  if that is the case then the ambiguity
of SLs will still cause problems.  

> (Although again, I think you're being overly

apps aren't aware of site boundaries.

> IPv6 networks will be set up and used.  

indeed, that's part of the difference.

> I believe that applications

again, it's not communicating globally, it's communicating off-site.

and it's not sufficient to just give the nodes with direct off-site
connectivity global adddresses -  every node in the application,
regardless of whether it can directly communicate off-site, needs
a global address.

> to expect global connectivity.

I think the assumption that a site can get away with just assigning
globals to some nodes, and yet expecting other nodes to participate
in applications along with those nodes that have off-site connectivity
and use globals, is naive and effectively produces onerous requirements 
for those applications. 

> I don't follow this.  Are you saying it is hard to get global IPv6

yes, if you don't connect directly to the Internet.

> address isn't ambiguous.  

scope-ids are not globally scoped.  they're only meaningful to the
local host.  and the scope-id isn't part of the address.  so yes,
they are ambiguous.

> Apps don't have to "implement their own

and what is the purpose of the proxy if not to route messages?
and just what do you think the proxy is going to use for addresses
to enable it to refer to a nodes on other side of the proxy?
guess it's going to have to implement its own addressing and routing
after all.

> communicating with you via a site-local.  

and yes, we've been over this before - if the party doing the referrals
is off-site (and yes, I work with apps where this can easily happen)
then this filtering algorithm prevents the referral to site-local 
nodes if those nodes don't have globals.

> And also provide the global

the app has to deal with renumbering anyway.  why should it have to
implement different solutions for local-only nodes vs. other nodes?

> They don't need to.  See above.

false.  see above.

> connectivity.  

they will.  but global connectivity is not a necessary condition for needing
global addresses.  apps need global addresses if any node in the app 
(present or future, directly connected or not) is off-site.

> The only apps that don't have an alternative should be
> site-locals.  

I'd like to belive that, and that would surely simplify things.
But we've got someone arguing that it's okay to implement security by 
assigning globals only to some nodes on a site, and letting the others
deal with SLs.

> It's the opposite freedom I want to preserve, to let apps

I don't have a huge problem with that - as long as globals are reliably
available to any node that isn't on an isolated network, writers of
multi-party apps will surely realize that the simplest  way to solve
their problem is to avoid using SLs.  the other apps can use them if they
want to.  (I think it will still cause problems when they do so, but
these mostly affect the local network administration, and the local
network admin can always fix it by disabling SLs)

> Intermittently connected networks.  I believe you agreed to this point

intermittently connected networks that lack a stable address prefix,
and a couple of other corner cases.  but more things will work if 
those networks can somehow manage to use globals.

Keith