Keith Moore wrote: > > > 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.
This is not a bug, it is an architectural principle. Those are not changed on a whim after the review process has completed. > > > > 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. Yes, but putting that in the address allocation process scales better than having to scan a 10,000 entry list for each packet. > > > 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. Read draft-ietf-ipv6-default-addr-select-09.txt for instructions on sorting that out. > > 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. > > 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. On the contrary, they are providing the tool that allows people to get maximum value from the networks the way they are currently organized. > > > > 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. So rather than lots of hacks, we should have formal documentation of the approaches and constraints. > 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. > > > 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. 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
