Keith Moore wrote: > ... > > The compromise model of 'using 2 public prefixes per > segment' allows > > for a 2 entry static list at every border, which may or may not be > > considered reasonable to match by the border peer. > > there are other ways to do this than having separate > prefixes. you can use any bit after the initial /48.
The point is that the organization on the other side of the border may not consider a matching filter to be reasonable if it is more specific than the /48, or a well-known value. > > > It does not provide > > the printer manufacturer a preconfiguration option that > matches other > > customers, and even if it was done, as soon as Company X changes > > providers, they have to manually touch every printer for the new > > configuration. > > if printer vendors are being told that they can provide > security or their devices by using site-local addresses, we > need to publically shoot that idea immediately. it is > completely unreasonable to > assume that a site boundary is trusted or that hostile > traffic cannot leak in from offsite - even if site local > addresses are used. I did not say security, you did. I said that printers preconfigured for SL-only would comply with simplified filter policies. > > > It also consumes 2x the public prefix space, to support > > nodes that will never be accessible from the public network. > > no it does not. In the small you are correct. For an organization like Cisco with well over 50,000 registered subnets, doubling the number of public prefixes assigned to each segment will require a larger allocation from public space. > ... > > Another side-effect of choosing SL over global scope > prefixes is the > > simplification of diagnostic efforts for communications within the > > site. > > no, it makes diagnostics more difficult (for both the network and for > applications) because SL addresses are ambiguous. Not within the context of the routing domain, and filtering is explicitly intended to preclude crossing routing domains. > > > > no, it just results in those networks having to use slightly=20 > > > different security measures for IPv6 than they used for IPv4. > > > > The tone of that statement makes it a non-starter as far as the > > security teams are concerned. The point has to be that the security > > measures start from exactly the same point they are in IPv4, > > folks who believe that should stay with IPv4 and NAT. if you > deploy a v6 network only to impair that network in such a way > that v6 provides no benefit, what's the point? I listed several, but they seem to be falling on deaf ears. > > > but with > > simultaneous use of SL & global prefixes we have the opportunity to > > expand the functionality of the network by allowing some nodes to > > avoid the need for nat. > > SL can avoid the need for NAT but still impose the same > constraints on applications. what's the point, particulary > when you can avoid the need for NAT without using SL? As I said, force the network manager to choose between complex filtering or nat, and nat will win. Provide the option for multiple simultaneous use of scopes, and there is a path forward to allow apps to work where they should, and be broken where they shouldn't work. > > > The absolute requirement for filtering will trump any > complaints about > > broken applications, which means there will be site-scope address > > space. > > NO IT DOES NOT. Filtering is a given, but it does not imply > scoped address space. This has been explained over and over. Filtering == scoped address space, no matter where the bits come from. The point is that some addresses are only valid within the scope of the filter. > > SLs may have some marginal utility, but filtering is not part of that. >From the perspective of toy networks, there is little utility in simplified filtering. From the perspective of global enterprise networks, complexity is expensive, and prone to errors. > > > If we don't provide an opportunity to move beyond the current model > > where all nodes are required to live in the single scope of > filtered > > space, by providing simultaneous support for site/global space, we > > will be stuck with nat forever. > > You have said nothing which supports such a statement. Or you have refused to accept all the statements that support it... I have made the case that several have supported in private mail (but they refuse to do so on the public list to avoid being "subjected to the wrath of a rabid attack dog"), so I will not add anything further to this thread. 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] --------------------------------------------------------------------
