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 ]
Per Heldal
heldal at eml.cc
Sat Sep 12 01:02:29 CEST 2009
On Fri, 2009-09-11 at 20:31 +0900, Masataka Ohta wrote: > Another good reason to change the policy is recent development > of NAT technology. > > Recent NAT even allows for end to end transparency that there > is no reason for old entrants not to deploy NAT to reduce address > consumption to leave room for new entrants. > > Masataka Ohta > > PS > > 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 ? :) 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. Industry-wide standardisation is what counts in this area. 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. 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. The only argument in favor of changing policies at this stage is IMHO to, if possible, be able to dodge accusations of anti-competitive practises against new entrants. All that is required for that is to reserve a relatively small block from which everyone who qualify for a /32 or larger PA v6-block gets for example a /22 v4-block if they have no prior v4 allocation. Everything else that has been suggested are policy tweaks which aim to benefit certain types of operators, but they make no significant difference to the bigger picture. //per
- 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 ]