Dan Lanciani writes: > MUST NOTs in RFCs are not going to stop NAT. > > Eliminating NAT is actually very simple. All you have to do is give users > that which by its lack drove them to use NAT in the first place: plentiful, > free, stable address space. I conclude from the effort that folks are putting > into discussing other (pointless) ways to mandate NAT away that they in fact > agree with my prediction that v6 ISPs will not magically change their business > models and offer such address space freely. As long as address space and > stability remain profit centers, you will not be able to eliminate NAT.
Sure, but until then what does IETF do? There seems to be a tacit game which is being played out here which is "don't encourage NAT" which see-saws between the architectural principles of the NAT-less internet, and the reality of NAT's being present. And NAT's will most likely exist going forward primarily because we don't have any assurance of stability of address space (eg PI). There are some who would like to embrace NAT as an architectural principle -- not necessarily here, but they clearly exist -- some who hate NAT's under any circumstance, and then many people in the middle who don't like NAT's and the implications of NAT's being an architectural principle (like the Thou Shalt Consider Security edicts from the IESG these days), but are more pragmatic about their existence. As in, what should we do to minimize the damage? The deal I personally have made with this devil is to realize that we're not going to stop their use until all of the reasons you enumerate are addressed, but in the mean time I'd assume we bide our time and not throw in the towel on a NAT-free world. What this pragmatically means is making NAT's a poor a relation as possible so that we aren't trapped in the quagmire of making it an architectural principle which must be addressed from the outset. It also means turning our back on things that are obvious problems and often let them get hacked on outside of the IETF context. Thus, the fundamental argument going on here is: how much do we allow ourselves to be sucked down the this rathole? My opinion is "the less, the better". Site locals will without any doubt in my mind be primarily used as a replacement for net 10 address space -- all of the other purported uses are marginal, redundant or false-secure. This is why I think pointing would-be site-local people to 6to4/net 10's is probably a good compromise since it shunts the problem off into legacy land, and allows us to postpone having to make decisions about the true implications of routing scope with traditionally routing-dumb hosts. This is obviously unsatisfying for those who would like a more long term solution, but... well, we ain't there. Until we've convinced ourselves we really have no choice but to embrace NAT as an architectural principle since we can't resolve your laundry list of reasons people use them, doing nothing -- or next to nothing -- looks like a pretty reasonable option, IMHO. Taking the *wrong* direction at this point could be extremely harmful. Scoped addresses as have been pretty well demonstrated take us down some pretty scary paths. Let's not go there... yet. Mike -------------------------------------------------------------------- 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] --------------------------------------------------------------------