Per Heldal wrote:
If we wisely allocate the final /8s, we will be ready to allocate class E and part of class D for unicast before we run out of classes A, B and C.
That is, we don't need IPv6.
Would you care to share a bit of whatever you're smoking ? :)
Sure. Talk with real world ISPs.
I'm afraid the transition to v6 will be well on its way by the time the NAT traversal workarounds that are floating around in various drafts make their way through IETF and into the new generation of HW/SW required to support it.
NAT traversal won't work, because they need modifications on applications. Moreover, IETF has no control over NAT. ISPs, instead, can modify their equipment to support transparent NAT they prefer, regardless of whether it is IETF standard or not.
Industry-wide standardisation is what counts in this area.
Not at all. For example, NAT was deployed without IETF standardization. For another example, ISPs are happy to use RADIUS with their own extensions not standardized by IETF.
The next forklift upgrade of software and/or firmware that providers make to their access-layer and CPE's will most likely have IPv6 already.
The problem for ISPs to support IPv6 is operational cost, which is greater than that of IPv4, which is why most ISPs won't support IPv6 in addition to IPv4.
I'm not saying that v4 NAT won't play a certain role during the transition-phase, but I don't consider it's a viable long-term solution.
A viable long-term solution is yet another IPng, which is easy to operate, easier than IPv4. Until we have such a protocol, we should depend on NAT to reduce IPv4 address space consumption. You know, NAT is easy to operate. Masataka Ohta