> 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 PROTECTED] --------------------------------------------------------------------
