Keith Moore wrote: > ... > > Even > > when it is available, that does not automatically create a > reason to > > restrict the use of SL. It will always be easier to filter > a short /10 > > than to maintain a long list of access controls at the > border. THIS IS > > A MAJOR OPERATIONAL REASON TO USE SL. > > NO IT IS NOT. First, you're not comparing the same cases > here - you're > assuming in one case that a filter will block off an entire > network, and in > another case you're assuming that the site will need and use > a long list of access controls. What you seem to be arguing > is that sites don't need the flexibility to block or permit > external traffic to individual hosts, > nor do they need the flexibility to block or permit traffic > within their internal networks. I don't buy it.
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. > > > It is appropriate that we have a document describing the impact on > > multi-party apps using literal referrals, and another on > guidance on > > DNS configurations. We have discussed the first many times, and the > > second is nothing more than formalizing what people have > been already > > doing in the face of 1918 space. > > Formalizing that practice is exactly the wrong thing to do - > it degrades > the value of DNS for use by applications. You are trying to legislate against current practice, rather than documenting it so that app developers can understand the real environment. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
