[ppml] Policy Proposal: IPv6 Assignment Guidelines

[briand at ca.afilias.info]

> In a message written on Sat, Aug 18, 2007 at 10:45:40AM -0700, David
> Conrad wrote:
>> You want to conserve address space?  Never _EVER_ allocate longer
>> than a /32.  If a requester has demonstrated they have consumed the /
>> 32, grow it to a /31.  If they have demonstrated they've consumed
>> the /31, grow it to a /30.  Etc.  Never reserve space or allocate
>> sequentially, simply use sparse allocation with bisection (that is,
>> after all, why each RIR received a /12).
>
> Circling back to my proposal that started this thread....
>
> The issue addressed by this proposal is the size blocks LIR's assign
> from their PA blocks to customers.  This proposal does nothing to
> change the size of blocks given out by ARIN.

Bingo!

The missing piece of the puzzle is one of PI assignments, not PA.

All that is required to manage PA assignments from getting out of hand,
is to limit the *PI* assignments. Let the recipients of PI blocks do with
those as they wish, with one proviso:

One (new/initial) PI assignment *only*, per ASN.

And the *size* of PI assignments should be flexible, with the only
requirement being, that whatever justification for the size of the
request, is that it be self-consistent - that what is used for the
justification matches the size of the requested space.

If we limit one routing slot per ASN, the growth of the DFZ will not
be problematic.

The *only* problem with the IPv4 swamp, was that there were multiple
assignments to ASNs, that couldn't be aggregated by the ASNs. If we
place up front, the requirement that all assignments must always be
aggregateable, by virtue of the fact that there isn't anything to
aggregate, the problem never comes into existence.

There will undoubtedly be cases of acquisition and mergers, where as
a consequence of the joining of ASNs, that a single ASN has more than
one PI block.

But, if the rule is "once you *have* a block, you can't request another",
rather than "you're only allowed one at any point in time", the result
is suitably similar - growth only occurs at the rate of ASN assignments,
which are gated by the rate at which new multihomed-via-BGP networks
enter the DFZ universe.

> In theory if PA is done correctly (and we all know there will be
> some cut outs) these never appear in the global routing table.

If PA is managed by recipients, without any requirement for ARIN to audit,
but with the double-edged sword being that they recipient only gets one
PI block to play with, the PA issue is self-managing.

If the only rule is "one PI per ASN", it is entirely reasonable to expect
that all members of the DFZ will have an incentive to enforce it. If even
a modest proportion of the ASNs in the DFZ filter based on "we won't allow
peers to deaggregate", then deaggregation will be nearly useless, and
as a result, is likely to not be a large problem.

It is a "hammer vs nail" rule set, but in this case, both the hammer and
the nail are the right tools for the job.

> Do you have an opinion on if ISP's should be always giving out /48's
> to every customer, even if they have a single PC?  Or shold an
> HD-Ratio like I proposed be used?  Are you comfortable with ARIN staff
> only having a "guideline" to go on, or would you rather they, and the
> community have a firm criteria in the policy manual?

ARIN staff should never need to evaluate anything other than initial IPv6
requests, and should be extremely lenient in allocating those. Any
justification that passes the giggle test, should be fine.

Brian Dickson