This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] The final /8 policy proposals, part 3.2
- Previous message (by thread): [address-policy-wg] The final /8 policy proposals, part 3.2
- Next message (by thread): [address-policy-wg] The final /8 policy proposals, part 3.2
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Masataka Ohta
mohta at necom830.hpcl.titech.ac.jp
Sat Sep 12 04:01:29 CEST 2009
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
- Previous message (by thread): [address-policy-wg] The final /8 policy proposals, part 3.2
- Next message (by thread): [address-policy-wg] The final /8 policy proposals, part 3.2
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]