The final /8 policy proposals, part 3.1
Hello again, I'm trying to keep this policy proposal discussion on-topic. We have already discussed two parts, and we should really focus on this third part now. If we keep going back to the beginning we will never get work done... I'll repeat my questions to the list: - If a company demonstrates the need for a /20, we could give them (for example) a /26. Smaller organisations would end up with even smaller amounts of address space. Currently prefixes longer than a /24 can not really be routed on 'the Internet' (for some definition of 'Internet'). Do we expect this to change, or do we have to make the minimum allocation size a /24 so that LIRs receiving address space can use it? - Do we want a maximum allocation size? This might be useful to prevent a few large companies to grab most of the address space, but it might also be unnecessary. - Do we want to make exceptions for certain situations where downscaling is not possible? For example a server farm with many HTTPS sites can't use less IP addresses than the number of websites (with the current protocols). Jim is suggesting that we don't change any policies for the final /8. That would be a downscaling factor of 1. With the current allocation rate of the RIPE NCC (see http://www.potaroo.net/tools/ipv4/index.html, graph 28e) that would mean that the final /8 will be allocated in about 4 to 6 months. Michael proposed to hold a meeting to divide the final /8. After that happens a new entrant will not be able to get any IPv4 addresses from the NCC. This might be seen as the established companies (us) trying to prevent new competition... We now have the chance to prevent that situation, and we should make good policies now to prevent that from happening. At least in the first couple of years after IANA runs out of IPv4 addresses. We can't just think about the current LIRs. If we do a bad/anti-competitive/etc job here some governments will have a good excuse to take the IP address allocation right away from the RIPE community. They might leave us alone, but do we really want to count on that? Thank you, Sander Steffann APWG co-chair
Do we expect this to change, or do we have to make the minimum allocation size a /24 so that LIRs receiving address space can use it?
There should be a minimum and it should be /24. However, we should call for proposals/analysis on changing this minimum. It may be possible and worthwhile to change the minimum even if this is only widely implemented by RIPE region ISPs. But for now we don't have the data to support a change.
- Do we want a maximum allocation size? This might be useful to prevent a few large companies to grab most of the address space, but it might also be unnecessary.
Yes, we want a maximum and I suggest that the maximum be calculated differently for each ISP, based on their run-rates, in order that the TIME of final runout is roughly matched for all ISPs getting allocations after IANA runout.
- Do we want to make exceptions for certain situations where downscaling is not possible? For example a server farm with many HTTPS sites can't use less IP addresses than the number of websites (with the current protocols).
Some business models are dead-ends and it is not RIPE's business to support them longer than their natural life. The HTTPS server farm definitely falls into this category. If broadband ISPs can make the effort to go to IPv6, then so can other business model ISPs.
Jim is suggesting that we don't change any policies for the final /8. That would be a downscaling factor of 1. With the current allocation rate of the RIPE NCC (see http://www.potaroo.net/tools/ipv4/index.html, graph 28e) that would mean that the final /8 will be allocated in about 4 to 6 months. Michael proposed to hold a meeting to divide the final /8.
Some people seem to be violently opposed to a meeting, so let's consider it this way. After IANA runout, RIPE has a severely limited inventory of IPv4 consisting of the final /8 and some additional blocks that are not yet allocated. This inventory is not likely to grow, because during IPv6 transition, ISPs cannot free up IPv4 blocks in the early stages. Therefore, let's make the decision on how the final INVENTORY of IPv4 addresses is allocated, after IANA runout and based on the data available at that time. This does not necessarily have to be done with a meeting as I suggested. As long as the policy is changed to stop all allocation activity until new rules are agreed, that is sufficient. In fact, since IANA will likely announce when we are getting close to IANA runout, it is likely that there will be enough data available to make the decisions before IANA runout happens (and allocations stop) as long as people are reasonable.
After that happens a new entrant will not be able to get any IPv4 addresses from the NCC. This might be seen as the established companies (us) trying to prevent new competition...
??? After RIPE runs out of IP addresses, we might be seen as anti-competitive?
We now have the chance to prevent that situation, and we should make good policies now to prevent that from happening. At least in the first couple of years after IANA runs out of IPv4 addresses.
Are you sure that RIPE will have a sufficient inventory of IP addresses to supply everyone's run-rates for a couple of years after IANA runout? Note that if you have a maximum allocation rule that limits allocations to less than an applicant's needs, that is the same as RIPE running out of IP addresses, from that applicant's point of view.
We can't just think about the current LIRs. If we do a bad/anti-competitive/etc job here some governments will have a good excuse to take the IP address allocation right away from the RIPE community. They might leave us alone, but do we really want to count on that?
I think that this is an overrated fear. As long as RIPE functions as a forum, and has broad participation, governments will not touch it. The biggest danger comes from the current lack of broad participation and excessive cliquism. RIPE really needs to be more proactive in inviting stakeholders in Europe's Internet community to participate in this working group. The danger lies in inaction, not in making sensible policy. --Michael Dillon
On 27 Aug 2009, at 13:12, <michael.dillon@bt.com> wrote:
The danger lies in inaction, not in making sensible policy.
But what if the sensible policy is to do nothing? I really can't see why anyone could have reason to intervene in the dying days of IPv4 if RIPE is sticking by the long-established policies that have served it so well. IMO the danger lies from inventing new policies -- for the sake of being seen to do something it appears -- that may well distort LIR behaviour or introduce artificial barriers for new/late entrants. It's not clear to me what will be gained by having a revised policy for allocations once the NCC gets its last /8. So I think it's reasonable to ask the proponents of these changes to explain why the alterations are better than leaving things as they are. To an extent, I'm playing Devil's Advocate. Even so, I would like to be sure we've fully considered the implications of whatever policy changes (or none) are in front of us.
participants (3)
-
Jim Reid -
michael.dillon＠bt.com -
Sander Steffann