> > I think that we can make rules that say "no NATs in IPv6" and > > "advertisements of PI prefixes on the public Internet should be > > filtered" and that those rules will have a useful effect. They > > might not entirely prevent either practice, but they may make them > > rare enough that they do not cause huge problems. > > Enforced by whom? Heck, forget enforcement. > *Voiced* by whom?
IETF. Who did you think? Do we need enforcement in order for vendors to more-or-less conform to other specifications that we write? > > In the case of NATs, I believe users will be less eager to deploy > > NATs in IPv6 because (a) the absence of NATs in IPv6 allows the > > Internet to support new kinds of applications that will drive > > deployment and (b) IPv6 gives users better ways to solve some > > problems (renumbering, attachment of a home network) whereas in > > IPv4 NATs were the best tools available. > > If people really, really want PI space -- which they manifestly do to > isolate themselves from PA address changes amongst other things -- why > does it not follow that they'd like to make those nice unroutable PI > addresses that we so kindly provide to not have reach farther than was > intended? I can't even tell what question you are asking. could you rephrase that more simply? > As in, why doesn't the experience of RFC 1918 directly apply > here? *which* experience of RFC 1918? there are lots of experiences, some of them conflicting. > Even if you can get a globally routable PA provided address, > would the network adminstrators who desire PI even want to deal with > them? it depends. do they want their networks to be able to communicate with other networks (outside of private agreements) or not? if no, PI space will do just fine. if yes, they'll need to use PA space for those hosts (unless of course we solve the problem of making PA addresses universally usable). > Because they're still faced with the daunting task of > renumbering PA addresses if they use them which was... sort of the > reason that they like PI addresses. bad assumption. renumbering need not be a daunting task if you have tools and the necessary support. I've seen fairly large v4 networks renumbered without too many glitches - it will be even easier in v6 if we finish the work. though it seems like we'd rather argue that it's infeasible than work on the tools... > > In the case of advertising PI prefixes, I believe ISPs will > > understand the wisdom of filtering them. They might not start > > filtering them immediately, but if routers get overloaded, the > > price of advertising a PI prefix will increase rapidly. > > Sure. Which leads directly to NAT's to get around > the perceived meanness of the ISP. nayh, nayh, nayh. saying "this will lead directly to NATs" is starting to sound a lot like comparing somebody to Hitler. it's a meaningless assertion because there's no way to evaluate it. IMHO: you won't use NATs in IPv6 - because NATs will break your apps - because the very reason you adopted IPv6 was to get away from the problems with NATs and to let you run apps that aren't NAT compatible. for the forseeable future, apps that are NAT compatible are going to use IPv4. > > Of course, we do need to provide better solutions for scalable > > routing renumbering, and multihoming. We also need a better > > security architecture. My impression is that we are devoting too > > much energy to freaking out, when there are important problems we > > need to be working on. > > I dunno, is it "freaking out" when the end result > of this exercise looks like the current IPv4 > deployment except for a larger IP header? yep, that's freaking out. stop assuming that the past will repeat itself - first because v4+NAT isn't going away (why bother with v6 if you're going to keep using NATs?), and second, because the conditions aren't the same. > > In particular, we need to get ourselves out of the habit of crying > > "that will lead to NAT" or "that will lead to route explosion" and > > using these as excuses to stop investigating a solution path. > > Even when there's ample existance proofs that it > will? no such proofs exist, just unfounded assertions based on questionable assumptions. 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] --------------------------------------------------------------------
