[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

[Benson Schliesser]

Hi, Bill.

On May 31, 2011, at 12:18 PM, William Herrin wrote:

> If that's the consensus goal then put together some verbiage for 8.3
> that hits these five points:
> 
> a. Any registrant may offer an entire ARIN IPv4 address block
> registration for transfer without restriction.
> 
> b. Any registrant may offer part of an ARIN IPv4 address block
> registration with a prefix no longer than /24 for transfer. /8 through
> /24 allowed, /25 through /32 prohibited.
> 
> c. Transfers under 8.3 are only received as fulfillment of an ordinary
> section 4 request following all ordinary policies and procedures under
> section 4. To the extent that turns out to obstruct reasonable
> behavior, we'll fix it in section 4.
> 
> d. Any registrant may receive any number of address blocks from (a) as
> needed to fulfill their ARIN-approved section 4 request.
> 
> e. Any registrant may receive no more than $N discontiguous address
> blocks per $UNIT_TIME from (b) as needed to fulfill their approved
> section 4 request. So if you buy a partial fill, shop wisely.

It seems to me that disaggregation in the routing table will be dominated by the source of an address block rather than a recipient.  If somebody disaggregates a very large block, in order to parcel it out or because they can only spare a part of it, then multiple new routes will appear from the original source even if the new recipient only announces a single route.  For example, if I have a /16 announcement in BGP today and I want to sell a /19, then I have to start announcing a /17, /18, and /19 to cover the retained space - while my buyer starts announcing a /19 prefix that I transfer to him.  That results in 4 routes in BGP where there used to be 1.

Clearly, limiting what people can receive will have an effect on disaggregation - reducing the number of blocks allowed per-recipient-per-time-period will encourage buyers to acquire as much as they can afford as a single block, rather than many small blocks over time.  That's good.  But just as disaggregation occurs today at the "whim" of the announcing AS, it will continue to do so under the regime described above.

ARIN could attempt to limit this by only accepting disaggregation in Whois by +N (e.g. +1 or +2) bits of prefix-length per year.  Of course, that means holders of very large blocks will have a hard time selling their unused space - they may need to disaggregate by larger values of N in order to meet demand under a "justified need" regime - so some kind of sliding scale might be useful, based on original block size.  Otherwise, for a uniform value of N this policy would limit the supply of address blocks (and probably drive up prices).

I'm personally inclined to view this (+N idea) as market distorting, and probably ineffective since ARIN doesn't control BGP anyways. But I offer it for your consideration, regardless.

Cheers,
-Benson