Keith Moore wrote: > > I don't know how you can get from needing a simple filter to not > > needing a filter... A simple example would be; as per spec, SL is > > blocked at the border, globals are allowed without restriction, and > > hosts that are allowed out have a policy that allows them > to configure > > a global prefix along with the SL one, while those that are not > > allowed out have a policy that only allows configuring an > SL prefix. > > Address selection says use the smallest scope, so internal > > communications use SL and are forced to stay internal by the hard > > filter at the border. This puts the burden of policy application at > > the address assignment time (very infrequent) rather than parsing > > every packet for access control. > > this is not workable for several reasons. > > first, it expects apps to work across site boundaries betwen > hosts that > use SLs. that's simply unacceptable.
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. Are we really talking about legislating against border filtering? > > 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. Between private networks is a matter of local negotiation, but that would be true in any case. > > 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. 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. > > 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. The address allocation / selection mechanism for a well defined space makes that process manageable, and reduces the burden on the filter process. > > > 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 > 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 can't seem to see that the option of having an address with limited scope does not require an app to use it, while also insisting that apps that might want to run in a limited scope are invalid. No one is requiring the apps you write to use SL addresses. Tony > > 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] --------------------------------------------------------------------
