> >>> 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.
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. > > 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. "most people" don't write distributed applications (though they probably do use them without being aware of it) > >> 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. 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. > >>> 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=20 > >> anything about the network topology, they only need > >> to know what kind of addresses they are using. > >=20 > >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=20 > >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. 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 > 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). 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. > > >> 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=20 > >> addresses around in the data stream. > >=20 > >yes, > > Glad to see we agree on something :-) > > >but since the addresses are global the party that is=20 > >*using* the addresses has at least some chance of knowing=20 > >whether it has access to them. > > 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. > 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. no it doesn't. why don't you actually try making this work in real distributed apps before making such ridiculous claims? Keith -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
