Keith Moore wrote: > > 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?
Unnecessary, dubious, & marginal are one perspective. The point is that the recommendation to preclude simultanious use of SL & global is a serious architectural change. It is not a minor edit. > > > > 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. Using what routing technology ??? If there are devices sitting on the same wire, they need to have some coorelation in the address space for current routing protocols to deliver packets. > > > > 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. For apps that it is insufficient, apply a rule that says SL is not an acceptable choice. That is a local app decision. > > > > 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? Because with 1918 & nat, they have no choice about the matter. Telling them they can't have a tool that will allow apps to work where required, while breaking those that should be broken, is not getting to where you want to go. They will insist on nat because filtering takes precidence to making apps work for a subset of nodes. > > 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? Preventing the SL space does not discourage the practice, preventing simultaneous use of SL & global does. Filtering will be the priority, and if the filter list is unwieldy, nat will take its place. > > > > 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. No one is requiring that SL be used, so the assertion that everyone has a burden is absurd. > > > > > 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. Documenting the hacks will expose the goals, which could in turn lead to better engineering. > > > > 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. You are arguing that an app needs to work over a global scope, despite the network manager's intention that it not. The point of scoping is to prevent interoperation across the boundary. > > 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. The point is that the network manager intends some aspects of the network to be broken. The tool we have provided to allow that to happen without requiring all nodes to be subject to the brokenness is SL. > > > > > 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. It is not increased or decrease complexity. It is simply moving the complexity around so that nodes that should not be subjected to draconian policies have an out. The benefit is for those nodes that need global accessability but have to share infrastructure with devices that should not have public access. 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] --------------------------------------------------------------------
