> It is clear that some application developers will have to decide if they > want to bother with the new capabilities provided by simultaneous > support for multiple scopes.
that's simple for applications developers to decide, since multiple scopes provide no new capabilities to applications. unfortunately it's not applications developers who are making the decision about whether to impose scoped addresses on networks. your hypothetical example is misleading. any filters that can be implemented with SLs can as easily be implemented with globals - and using globals provides additional flexibility (at the cost of a longer filter list) for when it is needed, that simply is not available with SL. furthermore if the company isn't just being re-organized internally but (as is common these days) is also subject to mergers and/or intensive collaboration with other organizations, SL has to be abandoned anyway. > 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. > 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. > It also consumes 2x the public prefix space, to support > nodes that will never be accessible from the public network. no it does not. > Use of filtered global scope addresses makes it impossible for the > application to know why it failed to connect. that's blatently false, as has been explained multiple times. first, there is an ICMP messages that exists for this very purpose. second, there's no way that SLs can provide a general mechanism for applications to know why a destination was unreachable anyway, because SLs are nowhere nearly flexible enough for general filtering purposes. so having applications have to deal with SL just increases the burden on applications for no gain in functionality. third, applications will be expected to communicate between nodes that use SLs - that's exactly what proxies do, for instance - and use of SLs will unnecessarily increase the complexity of almost any application that involves more than two parties. > 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. > > 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? > 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? > 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. SLs may have some marginal utility, but filtering is not part of that. > 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. 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] --------------------------------------------------------------------
