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/address-policy-wg@ripe.net/
[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 ]
Mohacsi Janos
mohacsi at niif.hu
Fri Sep 18 10:21:24 CEST 2009
On Fri, 18 Sep 2009, Masataka Ohta wrote: > michael.dillon at bt.com wrote: > >> The point is that if RIPE changes the policy, it has to do so in >> a way that does not convert the bad luck of running out of IPv4, >> into selective discrimination. > > Or, better, in a way that does not cause the bad luck for foreseeable > future, which is possible by reducing amount of address allocation > assuming extensive use of NAT and start working on using Classes E > and part of D for unicast. This hardly work: you have to change protocol stack of billions of device. > > Note that NAT can be end to end tranparent. Can you explain how? Best Regards, Janos Mohacsi
- 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 ]