[ppml] Proposed Policy: Changes to IPv6 initial allocation criteria
Jeroen Massar wrote:
> There is already an IPv6 PI policy which covers these cases.
> Startup ISP's that need >=/32 address space can start out using the PI
> policy and don't need to be covered by the PA policy. If a startup can
> demonstrate the need for >=/44 which one can get with the IPv6 PI policy
> then they can under the current PA policy already get this space without
> much hassle or ado.
The current policy seems to prohibit this migration path.
You should not apply for a PI /48 if your intent is to be an ISP and
should not apply for a /32 if your intent was to use it as an end site.
Allowing or requiring ISP's to go from a PI /48 to a /32 would mean each
ISP having at least two prefixes. This kind of slow-start induced
address fragmentation accounts for about half of the more specifics
seen in IPv4 tables today. We should try to avoid that.
Reducing the minimum for ISP allocations from /32 to something smaller
would be ok as long as the same space (currently /29) is reserved for
future expansion to prevent fragmentation, and it is made from the
ISP address pool. If the requirements are reduced then it probably
would be a good idea to reduce the minimum allocation size.
> Applying this 'delete' to the current PA policy will only make the PA
> policy so blatantly open that there will (maybe ;) be a landrush on the
>> =/32's blocks, effectively creating, again, the "class A" situation for
> early adopters even though the requesting entity will never use the full
> address space of the /32. Remember that 65536 /48's is a *lot* of space.
As you point out, anything less than the current policy would basically
be a no justification "shall issue" /32 policy, and I do not support
> As such, startups can use the PI policy which should satisfy their
> needs. Others, larger established ISP's, can use the PA policy.
As noted above, startups that cannot come up with the plan required in
184.108.40.206 (d) could use PA space to establish themselves as an ISP, but
should not use the PI policy if the plan to be an ISP.