[ppml] Legacy /24s

[briand at ca.afilias.info]

> I don't have the time to write it but I would support a
> proposal that gives legacy /24 holders a permanent IPv4 fee waiver,
> an efficient usage waiver so that they don't have to worry about
> reclamation,

I agree that reclamation on IPv4 is truly orthogonal to the deployment
of IPv6.

IPv6 will be necessary to support new allocations beyond 2010, and we
need to remove as many barriers to IPv6 deployment as we can.

There is little or no benefit to reclamation of IPv4 swamp space.

Much more benefit could be achieved by placing pressure on operators
who deaggregate, to stop doing so - and I would encourage adoption of
any such policy, e.g. requiring fees per globally announced prefix,
regardless of whether it is covered by another prefix.

> With the only contingency that the space be actively used in the DFZ
> or showing that the space is in use in a manner that cannot be readily
> replaced by 1918 space.

The ideas being circulated relating to the DFZ, that have widespread
support, are those that avoid polluting it with large numbers of prefixes,
where the prefixes in question could/should be aggregated.

To wit: if any current IPv4 prefix is single-homed, but not aggregateable,
the most likely reason is that it was assigned pre-CIDR.

Post-CIDR, the assignment would/should have been made from an LIR/ISP,
from a PA block.

We want to drain the swamp, not move it whole-hog (us who like the idea
of an IPv6 DFZ that scales to global use and lasts more than a year.)

So, if we change the wording to:
"... cannot be readily replaced by PA space.".

This would need to be emphasized by adding the additional requirement that
the policy would apply only to prefixes, where the requester operates an
active AS in IPv4 or IPv6, originating one or more prefixes registered to
them (or assigned to them via legacy assignment(s)).

This keeps the number of PI prefixes in par with the number of ASNs,
while bringing legacy /24's into the RSA fold.

>
> I personally feel that the /24 space needs to be handled differently than
> the /16 and /8 space.

Agreed.

> This obviously would be for the 2008 timeframe.

I think that it would be suitable for immediate implementation, actually.

Brian Dickson