> One opinion. You keep saying that, but it is not requiring that the app > work using SL across the border. In fact the reason the network manager > likes SL is the apps will explicitly not work in that case.
Actually that's a delusion. In today's networks the apps are still expected to "work" in that case; it's just that they require more complexity to do so, and they don't work as efficiently or as reliably. > Are we really talking about legislating against border filtering? No, we're talking about making border filtering useful. > > second, it's not secure without filtering. > > Who said anything about security, and the point of SL is that there is a > well understood filter that gets applied between the public and private > network. And if the purpose of this filter is not security (or the illusion thereof) then what is it? > > third, address selection is not a policy mechanism, it is a default > > behavior, that applications are free to ignore - and there are many > > cases where it's highly desirable that they do so. > > If an app chooses to assert a policy that is different from the network > manager's filtering rules, it will fail. Yes, though that doesn't mean that the network manager's policy was realistic. But a minute ago you were asserting that address selection prevented the need for such filters, now you're saying that the filters will exist anyway. Which is it? > Having a well defined address > space that is known to have filtering applied allows apps to have a hint > about potential scope restrictions. That hint may or may not be helpful, > but lack of it leaves the app in complete trial & error mode. No, it's just the opposite, at least if use of SLs is widespread. Apps will still be expected to operate across site boundaries, and the fact that an SL address is used forces the app to use trial and error to figure out which addresses work best for referrals. > > fourth, the idea that address selection for internal > > communications does not affect external communications is naive. > > I can't parse this. The decision about internal / external > communications is a filtering decision. You were claiming that it's okay to use SLs for internal communications and globals for external communications. I'm saying that forcing apps to use SLs for internal communications can prevent them from working externally even if some of those nodes have globals. The source address you use to talk to one node may get reused in a referral. This is standard practice today for many apps - it's one way to get around some of the problems imposed by NATs. Don't expect those protocols' paylods to change just to use IPv6. > > > You are trying to legislate against current practice, rather than > > > documenting it so that app developers can understand the real > > > environment. > > > > You are trying to force a practice that is known to be=20 > > broken, and the burden of trying to make apps work in the face of that > > broken practice, on everyone. There is no way that this can > > be justified. > > I am not forcing anything. I am arguing that we maintain an > architectural principle, that allows current practice to be extended > away from the need for header mangling. You are arguing that we maintain a principle that we now know to be misguided, that gets us away from header mangling but imposes most of the same constraints on apps that header mangling does, and that prevents IPv6 from solving the problems that were imposed by NATs. This is not a step forward. > You can't seem to see that the > option of having an address with limited scope does not require an app > to use it, It does if globals are not available, or if the app is using an address in a referral that was obtained from another app within the same site. > while also insisting that apps that might want to run in a > limited scope are invalid. Purely-local apps do exist, but that's a relatively small category of apps. Most app designers and users want apps to be able to work (policy permitting) between any set of nodes. And denying apps access to global addresses is a lousy way to implement this policy. > No one is requiring the apps you write to use > SL addresses. Nobody except misguided network admins, and you. 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] --------------------------------------------------------------------
