> > Well, there are far more people saying yes than no, but let > > me respond to some of the comments made. > > > > 1. Process (Tony Hain). Of course. If we make a substantive > > change to a draft that's already passed the IESG, a last call > > is needed IMHO. It would still be cleaner than publishing the > > RFC and then publishing a change. > > The way I read the thread, the plan was to simply change a few words in > the RFC editor queue. In any case, this is more than a few words, it is > a major architectural change and would require recycling to the WG & PS.
We don't normally require recycling to proposed when we fix bugs in a standards-track document while it advances. Indeed, that's the reason we advance documents in grade - so we can revise them in light of mistakes discovered in earlier versions. Nor is there anything in the process that requires documents to be recycled to a WG when bugs are found - in most cases the WG is no longer around. How the document is handled is up to IESG. > > 3. Can't stop NAT's anyway. (several people). That may sadly > > be true, but we shouldn't publish specs that seem to encourage them. > > Preventing simultaneous use of SL & Global will in fact encourage NAT. no, not "in fact". that's just a figure of speech. > Network managers require that some nodes are invisible to the global > network. Most will find it easier to force the systems that need public > access to use NAT, rather than try to maintain a lengthy filter list at > the border for those that don't. 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. > Giving them the tool that allows easy > filtering, with simultaneous with global addresses for those nodes that > need it, is the only real way to avoid NAT. 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. 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. If sites want to use NAT they should stick with IPv4. > > 4. Impact on existing implementations and ongoing work. > > (several people). I don't really understand what the > > implementation change would be - surely this is basically a > > configuration issue? Products will still have to support SL. > > If we are going to impact ongoing work, however, the sooner > > the better. > > This is not a simple address format change, it is a major architectural > issue. All the implementations that already know how to deal with > simultaneous scopes will have to do major surgery strip that out, or > ship non-compliant code. No they won't. It will just be code that isn't exercised. 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. > > 5. Why not just kill SL completely? (JINMEI) That would > > definitely annoy implementors, and close off our options. > > > > 6. We have to handle multiple scopes anyway (Brian Zill, Tony > > Hain). Right. And by retaining SL, we retain the option of > > reversing the "disconnected" decision if we ever do figure > > out how to handle them properly. > > 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. The closest thing to a general solution is Teredo, but even that will fail if SLs are widely used in 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. 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] --------------------------------------------------------------------
