[ppml] IPv4 address and routing slot markets

[Scott Leibrand]

Stephen Sprunk wrote:
> Thus spake "Scott Leibrand" <sleibrand at internap.com>
>> The only thing that will make that theory true is $$$.  Today, the 
>> $$$ favors accepting all prefixes.  If routing table growth 
>> accelerates to the point where the cost of upgrading hardware gets 
>> much higher
>> than it is today, then some ISPs will consider filtering, perhaps in
>> the manner I outlined at the start of this thread, because the benefits
>> of doing so would outweigh the costs.  If that happens, then
>> organizations wishing to announce deaggregates smaller than the
>> minimum prefix size will need to also announce their covering
>> aggregate to maintain full reachability.
>
> What if the /24 I bought is in space ARIN has marked as having a 
> minimum allocation of /20?

Then ARIN wouldn't recognize your "purchase".  The "seller" could SWIP 
it to you, of course, but it would still be part of a larger 
allocation.  Any large ISPs who decide to filter more-specifics instead 
of buy more big iron could potentially filter your more-specific, 
relying instead on an aggregate announced by the "seller".

>
>> I disagree with Stephen's characterization that this would make 
>> deaggregates pointless for anything but private use. I still see a
>> role for deaggregates, but would expect (in a world of widespread
>> filtering) that they would only be announced as far as the business
>> relationship extends: to one's upstreams and possibly a few
>> peers.  That would preserve the ability to use deaggregates to
>> do inbound TE, while ensuring that only networks wishing to
>> receive the deaggregates need do so.
>
> If buyers had to purchase transit from the seller to get useful 
> reachability, it's no longer a sale/transfer of PI address space but 
> rather a SWIP of PA space to a (possibly multihomed) transit 
> customer.  That isn't what I thought we were discussing when we talk 
> about a black/gray/white market for addresses, since a mechanism for 
> _renting_ address space already exists.

In order for a black/gray market to function, it either needs to be 
possible to con ARIN into transferring the space (i.e. with the 
sale-of-shell-company game), or some other mechanism of tracking the 
"sale" needs to be found.  In the case of a sale of sub-minimum-size 
blocks, the easiest such mechanism would be a SWIP.  As you pointed out, 
it then becomes a legitimate rent/lease arrangement (although it could 
be a long-term lease more like an IRU), with strings attached with 
regards to reachability.
>
> If I'm going to go to the hassle of _buying_ address space, I want it 
> to be completely PI and have full reachability without any requirement 
> for the seller to continue providing me transit service.  That is, 
> AIUI, what people are afraid of because it necessitates the buyer 
> getting a slot in the DFZ for each purchased block.

Agreed.  It would therefore make a lot of sense for small multihomers to 
buy legacy class C blocks, where the minimum allocation size is already 
/24.  For larger multihomed networks, who would qualify for a /22, they 
would presumably be able to buy a /22 out of a netblock used for /22 
assignments.  And, of course, there's always the expedient of simply 
getting a /24 from your ISP and using that to multihome, if you're not 
overly concerned with IPv4 provider independence.

>
> Even if we don't allow chopping up /8s into anything longer than a 
> /20, that's still a heck of a lot of routes added to the DFZ vs. 
> today.  OTOH, there's only ~900k /20s, and router vendors swear 
> they'll be able to handle that (for a price).  Given that's a hard 
> limit if people filter at that boundary, and a lot of big folks (you 
> know, the ones with 80% of the address space) have big blocks they 
> won't deaggregate that far, is the apparent lack of backpressure 
> really a problem?

That's exactly what I'm trying to elucidate: backpressure of various 
forms (charing your transit customers for announcement of lots of 
prefixes, filtering deaggregates, etc.) will emerge if (and only if) 
there start to be lots of routes added to the DFZ, and it becomes 
expensive to upgrade routers.  What we as a community need to guard 
against is the sort of irreversible deaggregation that occurs at the top 
of the hierarchy.  Deaggregation lower down (SWIPping PA space) is less 
of a concern, as it's easily dealt with by these various backpressure 
mechanisms.

-Scott