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