> This is not a bug, it is an architectural principle. Those are not > changed on a whim after the review process has completed.
Come on, Tony. If we have a "principle" that justifies burdening applications with unnecessary complexity for dubious and marginal gain, aren't we better off without it? > > Neither SL nor NAT will save those sites from having to > > maintain a filter list. If some hosts on network are allowed > > to be exposed to the outside and others aren't, the list of > > exceptions has to be maintained somewhere. > > Yes, but putting that in the address allocation process scales better > than having to scan a 10,000 entry list for each packet. No it doesn't. Because if you can allocate SL+global addresses for some hosts and only SLs for others, then you can just as easily allocate different kinds of globals (say type A and B) for each host, and filter out just those that match type A. > > But the only way to make SLs work on a network that has > > external connections is to give all nodes global addresses. > > You can't just assign "global addresses for those nodes that > > need it" without burdening apps that need to talk to the > > other hosts with having to do their own addressing and > > routing. > > Read draft-ietf-ipv6-default-addr-select-09.txt for instructions on > sorting that out. That draft is just WRONG for large numbers of applications. The only way it was justified at all was by calling it a default, saying that apps could take exception to it, and claiming that the need for consistency between implementations required us to to get default behavior defined now, even if it was known to be insufficient. > > The strategy that you are advocating is precisely what we > > need to discourage. It's no better than NATs. If it's widely > > adopted it will destroy the additional utility that IPv6 > > provides over IPv4. > > How does use of unmolested global addresses become what we have today? > Nodes that need global access get a global address for that along with a > SL for internal use, and those that don't get only a SL. Today apps are expected to communicate between nodes even though those nodes don't have global addresses. The people who make the decision to deploy NATs and/or to use RFC 1918 addresses aren't aware of the detailed needs of applications - so they create dysfunctional networks, and the app developers are expected to take up the slack. Why will those people be any wiser with their use of SLs? And why should we not learn from our past experience with RFC 1918 and NATs and discourage practices that we now know to be harmful? > > And I disagree that there are implementations that "know how > > to deal with simultaneous scopes". Those implementations are > > almost certainly making unwarranted assumptions (or imposing > > unreasonable constraints, if you prefer) about how people organize > > their networks. > > On the contrary, they are providing the tool that allows people to get > maximum value from the networks the way they are currently organized. They allow *some* people to get more (not maximum) value from *some* networks. It's not reasonable to burden all users and networks for the long term in order to accomodate those few who have organized their networks poorly in the short term. > > > People already know how to deal with 'connected' 1918 space, > > > > No they do not. There is no general solution, there are lots of > > hacks that work only for constrained cases. > > So rather than lots of hacks, we should have formal documentation of the > approaches and constraints. No, Tony. You can't solve the problem simply by documenting the hacks and when they work, because they're still hacks, they still don't work well, and they still impose a lot of complexity. And if the situation is that difficult to document then there's a good chance that it's too complex to use. > > The closest thing to > > a general solution is Teredo, but even that will fail if SLs > > are widely used in IPv6. > > Orthogonal & absurd comment since Teredo is about global prefixes. No, you're just missing the point. Teredo is pretty much what you have to do if you want to produce a general solution for interoperation between networks with scoped addresses. In other words, you have to define a new set of unambiguous addreseses and tunnel between the networks. You don't necessarily need the mechanisms in Teredo to force the NATs to keep mapping state, but you need the rest. The point is we just got finished figuring out how to use IPv6 to allow IPv4-based networks to escape their dysfunction - and now you're trying to impose most of that same dysfunction on IPv6. > > > this is no > > > different in that respect. What is different is the architectural > > > change to support simultaneous use of multiple scopes. This is not > > > rocket science, it just requires working through the engineering of > > > the new edge cases. > > > > First of all, it's not engineering, since we don't yet know > > how to solve the problem. Second, there isn't enough benefit > > to justify the investment in the effort much less the burden > > on applications. > > One opinion that is not supported by current implementations. Only if you consider only the very few apps that try to deal with SLs in a general fashion and ignore the large numbers of apps that cannot deal with them. And only if you ignore the huge amount of complexity that has gone into solving the problems caused by use of RFC 1918 (even without NAT) without a general solution. Actually, the fact that you're trying so hard to preserve complexity that isn't needed unless SLs are imposed on the net argues strongly for getting rid of SLs. Who benefits from that increased complexity? Certainly not the network administrators or the users. 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] --------------------------------------------------------------------
