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] 2015-05 proposal
- Previous message (by thread): [address-policy-wg] 2015-05 proposal
- Next message (by thread): [address-policy-wg] 2015-05 proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Arash Naderpour
arash_mpc at parsun.com
Mon May 9 16:16:18 CEST 2016
>Tough. We’re out of IPv4. We’re all struggling due to a lack of IPv4 resources. Everyone just has to make the best of it with whatever they have now. Anyone >planning to grow their network using IPv4 simply cannot base their plans on repeatedly going to >the NCC and asking for more. It’s that simple. No, not everyone struggling due to lack of IPv4. There is a market and some are selling their IPv4 to others. Are they struggling?? >Let’s suppose 2015-05 is adopted. We quickly burn through the remaining IPv4 pool because some LIRs continue to grow their IPv4 networks instead of coming to terms with the end of IPv4. At that point, those LIRs will have a very nasty shock. There would >literally be no IPv4 remaining at the NCC. So these LIRs will then be forced to do something else: use NAT, deploy IPv6, use ALGs, buy addresses on the secondary market, whatever. These LIRs could and should be doing that "something else" now. They’re >going to *have* to do it eventually and might as well start now if they’ve not already done that. That assumption is not necessary valid, when 2015-01 was accepted we had not that much change in depletion rate. Can you please define first what you mean from "Quickly burn"? and how this policy can do that? >These LIRs surely know today that they cannot continue with a model that assumes they can issue IPv4 addresses forever or go back to the NCC and get more. So all these LIRs would have achieved with 2015-05 is buy themselves a little extra time to persist >with a doomed model that they already know no longer works. At that point the NCC would have no IPv4 left for any future entrants who will need some IPv4 to connect to the legacy v4-only Internet. Indeed, that’s why there are supports from a part of community. >Burning through what’s left of IPv4 for the short-term benefit of LIRs who can’t/won’t face up to the exhaustion of IPv4 seems wrong to me. Future entrants would not thank us for frittering away those resources. They’ll need some IPv4 too. We should think >about their needs too. Our IPv4 address policies can’t ignore that in favour of some what appears to be mistaken/misguided short-term benefit and self-interest. >> We need a balance between resource conservation and fair treatment >IMO the existing policy already achieves that. 2015-5, if adopted, does not. Really? How 2015-05 make it unbalanced? >> in addition to those already proposed my suggestions are: >> >> -allocations of a /22 every 18 months only from IPv4 Addresses Available Outside 185/8 to small LIRs (if LIR own < /20 of total allocations) >That’s discriminatory. It’s unfair on those LIRs who have a /20 or greater. No comment! >> -leave the current policy only for IPv4 Addresses Available in 185/8 to avoid the too fast depletion of resources >No. 185/8 should not be treated as “special”. The current last /22 policy applies to all IPv4 blocks at the NCC. That policy kicked in as soon as the NCC made its first allocation from 185/8, the last /8 it got from IANA. >> -the addresses acquired with this system should not be able to be transferred for a long period of time to avoid profit It is not really required to treated it as "special", when it is required we can have a new policy to change the depletion rate. this is not the last policy we can discuss here :) Cheers, Arash
- Previous message (by thread): [address-policy-wg] 2015-05 proposal
- Next message (by thread): [address-policy-wg] 2015-05 proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]