Subject: RE: Limiting the Use of Site-Local

From: "Brian Zill" <[email-masked]>
Date: Wed, 30 Oct 2002 18:21:58 -0800

> Keith Moore writes:
>
>>>> Brian Zill writes:
>>>> One advantage of having scoped addresses defined
>>>> in the IPv6 architecture from the start is that
>>>> applications can know not to pass them outside
>>>> of their scope.
>>> 
>>> NO.
>>> 
>>> 1. applications don't know where their scope ends.
>> 
>> They don't need to.  If they are communicating with
>> another entity via a site-local address, then that
>> entity is by definition within scope.
> 
> that doesn't mean that the entity that will end up
> using the address is within scope.

If the entity in question wants to pass the address on, it needs to
follow the same rule.  This keeps scoped addresses contained within the
scope where they are valid.

> where do you get the idea that all referrals are
> one hop?

I didn't say they were, and I thought most people would easily figure
out the point I made above.
 
> furthermore it's wrong (or at least incomplete) because a 
> host can have access to multiple scopes.

Of course.  But the scope boundary is exposed to the application via the
scope-id in the sockaddrs it is using.  If it receives a site-local
address via one channel (say where the site-local sockaddr has scope-id
X) then it can't pass it on to another entity via a different channel if
that channel is using a site-local sockaddr with scope-id != X.

>> Therefore they can legitimately pass a site-local
>> address in the data stream to that entity.  Otherwise,
>> they can't.  Very simple and straight-forward.
> 
>it's simple, straight-forward -- and incorrect.

On the contrary, I've shown where it is correct.  You have failed to
justify your accusation.

>>> 2. expecting applications to know about network
>>>    topology drastically increases their complexity
>>>    without any recognizable benefits.
>> 
>> As noted above, the applications don't need to know 
>> anything about the network topology, they only need
>> to know what kind of addresses they are using.
> 
>False.  there's no way that a referrer can know what
>scopes the party to which the addresses are being
>referred has access to.  the best the referrer can do
>is refer all available addresses.  even then, without
>global scope IDs we don't have a way for the party 
>using those referrals to know which addresses are valid
>in the scopes to which it has access.

No, as I've clearly shown above, an application can easily ensure that
it only refers addresses which are meaningful to referee.  Therefore,
the receiving party will always get valid referrals.  But this can only
work if we have site-local addresses.  If we force people to use random
global address space as non-routable, then apps will have no choice but
to blindly pass them around in the data stream (as I pointed out in my
previous mail).

>> If, however, random global address which happened
>> not to be globally routable (due to firewalls/filters)
>> were used, the app couldn't determine this, and could
>> end up blindly passing these non-routable 
>> addresses around in the data stream.
> 
>yes,

Glad to see we agree on something :-)

>but since the addresses are global the party that is 
>*using* the addresses has at least some chance of knowing 
>whether it has access to them.

As I've shown above, proper use of site-locals solves this problem.  If
the party gets a site-local, it can use it.  If we were to retreat to a
world with only non-routable globals, it would have no such guarantee.
Site-locals give the app much better than "some chance".

>(for instance, does it have a route to that net?)

And here I thought you were against apps needing to know about network
topology?  Most end-hosts have a default route to their first-hop
router, that's it.  They don't know anything more about what prefixes
are reachable.  Non-routable globals aren't the answer.  Again, the
solution I've outlined is simple, practical, and works today.

--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: Wed, 30 Oct 2002 22:30:42 -0500

> scope where they are valid.

yes, but it is too narrow a constraint - it doesn't allow referrals
between hosts that share a scope to pass through an intermediary
that does not share that scope.

> out the point I made above.

"most people" don't write distributed applications
(though they probably do use them without being aware of it)

> On the contrary, I've shown where it is correct.  You have failed to

I've justified it on multiple occasions, you just don't want to listen -
either that or you think that communications paths within an 
application should be organized into a hierarchy with all
intermediations between nodes in the same scope being done
by an intermediary that shares tha scope.  It won't fly.

> >> As noted above, the applications don't need to know=20
> >=20
> >global scope IDs we don't have a way for the party=20
> it only refers addresses which are meaningful to referee.  

and as I've clearly shown above, this prevents referrals from working
in cases where the nodes should be able to communicate.
 
> But this can only

Which is *exactly* what they should be doing - first because it's not
the app's job to know about network topology, second because it's not the
app's job to define its own address space (so that it can make referrals
work) or to route messages through the network, third because trying to
adapt apps to keep up with scopes - even in the simplistic way that you
suggest - is not only insufficient, it's a non-starter.

> >> end up blindly passing these non-routable=20
> >=20
> >but since the addresses are global the party that is=20
> >*using* the addresses has at least some chance of knowing=20
> As I've shown above, proper use of site-locals solves this problem.  

no, you've just picked a corner case where your "solution" happens to work.

the reality is that such apps will need to forward SLs around just in
case there aren't any globals, or the globals don't work.  and they'll
have to implement their own naming systems because the addresses are
ambiguous, and they'll have to verify each peer's identity because
using an SL address might cause it to reach a different host than intended.

> solution I've outlined is simple, practical, and works today.

no it doesn't.  why don't you actually try making this work in real
distributed apps before making such ridiculous claims?  

Keith