> > 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.
It's a perspective supported by a lot of people and a lot of work. > The point is that > the recommendation to preclude simultanious use of SL & global is a > serious architectural change. It is not a minor edit. It's a minor change to the text, and a serious architectural improvement. It doesn't break much that exists now, and it helps a lot of things to avoid being broken in the future. > > > 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. Only in the most significant bits. If an admin wants to assign some bits within a subnet allocation for this purpose, he's free to do so. Once you start having RA respond differently to different hosts on a subnet there are all kinds of games you can play. > > > 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. That doesn't work for all apps, if SLs are widely used. Some apps would need to use SLs, others would need to avoid SLs. It gets even more complex than that when you consider privacy addresses, link locals, and multiple global prefixes. > > 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. No, I'm not telling them that. I'm saying that SL is not a good tool for that job, that it does far more harm than good. Because SL doesn't allow those apps to work where required and break those that should be broken. It breaks some apps that shouldn't break and forces other apps to circumvent SL restrictions which make SL even less useful as a mechanism for advertising policy. > > 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. There are ways to keep filtering from being unwieldy without forcing apps to choke down SLs. > > 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. no one is requiring that NAT be used, so the assertion that everyone has a burden of dealing with NATs would be absurd - if it weren't widely accepted that NATs should be used. if SLs are permitted in networks with globals then people WILL require that they be used - whether or not this provides any useful security and whether or not this allows applications to work reliably. > > > 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. We already know how to do better engineering for this (which after all is about providing a sound way to solve the problems with the lowest cost) Discourage use of SLs on networks that have globals. Don't claim that they are a useful security mechanism. Tell apps that do referrals not to use them. Provide as many hosts as possible with globals. > > > > 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. Existing apps are expected to work over global scope even though they are operating on networks isolated by NATs and using RFC 1918 addresses - often because the network manager *thinks* this provides him some measure of increased security. He's generally wrong about that, for several reasons. So I'd say no, the point of scoping is not to prevent interoperation of apps across that boundary, since for many apps on many hosts interoperation across that boundary is quite often found to be desirable. Scoping is a really poor tool for that kind of access control. The real point of scoping is security through obscurity - trying to pretend that those internal hosts don't exist, by hiding their addresses from the outside world, and by preventing external hosts from doing traffic analysis. And to some extent doing that might be desirable. But we have better mechanisms for solving that problems - mechanisms that aren't imposed for all apps on a host. > > 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. And what we've found out is that it's a really crude tool. Not only is it too inflexible to serve this purpose, its use does a lot of harm. > > > > 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. No, it's making both apps and network filters more complex by forcing apps to do the job of the network. > The benefit is for those nodes that need > global accessability but have to share infrastructure with devices that > should not have public access. It's not just the nodes that need global accessibility that are affected; those that communicate through intermediaries are also harmed by lack of a uniform address space. 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] --------------------------------------------------------------------
