[ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use))

Paul Vixie wrote:
> scott wrote, answering my "is there policy work to do?" question:
>
>   
>> Let's say that a legacy /8 holder like MIT decides to start leasing out 
>> their IP space to "customers" buying a tunnel, dial-up, or some other 
>> similar form of connectivity.  Let's say there is sufficient demand for 
>> IP space that they sign up a number of customers, each receiving a /24 
>> with their tunnel and announcing it in BGP to their upstreams.  Now 
>> let's say this kind of behavior causes the routing table to explode.  If 
>> I'm a DFZ operator who is no longer able to handle all these prefixes, 
>> my solution is pretty simple: stop accepting /24's carved up out of /8 
>> allocations.  Doing so would cause me to send traffic to MIT's customers 
>> via the MIT /8.  That in turn would either mean that the traffic would 
>> hit MIT's network and then get sent to MIT's customers via their tunnel, 
>> or it would hit an intermediate network that was listening to the 
>> more-specific /24 announcement from MIT's customers (probably because 
>> they're being paid to do so), who would in turn send the traffic along 
>> normally.
>>
>> In summary, I'm sure this kind of thing will happen as we exhaust the 
>> IPv4 free pool, but I'm not sure it will break things too badly.
>>     
>
> i am less sure that this kind of thing will happen in /8-land.  the actors
> are too large and too bright and too visible.  in /16-land, where it's much
> harder for you to tell the players without a scorecard, and where scorecards
> could be lawsuit magnets, it could be prevalent.  if it happens often enough
> using enough different /16's then you might have trouble figuring out what
> to filter, especially if it changes every day, and the list gets long.  are
> you prepared to say that this problem will be self-correcting and that the
> routing system will remain stable under that sort of growth?  i'm not.  i'm
> also not sure what to do about it.  but someone who thinks it would be bad
> should try to propose some policy to make it better, i'd like to read that.
>   

If someone can come up with a helpful policy, I'm all ears.  But yes, I 
do think this kind of thing will be self-correcting, for one simple 
reason: you don't have to know who's doing it to filter effectively.  
All you need to know is what the minimum allocation size for each 
address range is.  (I know you know all this already, but I'm sure there 
are others who don't.)  A quick look at 
http://www.iana.org/assignments/ipv4-address-space and 
http://www.arin.net/reference/ip_blocks.html gives me a pretty good idea 
that I could filter, more or less safely, anything larger than /8 in the 
0/8 to 56/8 range (with a couple exceptions, like down to /20 in 24/8), 
down to /16 in the 128/8 to 172/8 range, down to /20 in the 63/8 to 99/8 
range, etc.  If I were to implement such a policy, I'd first take a good 
hard look at my BGP table (rather than the cursory look I just did), but 
it's by no means necessary to identify the specific players doing the 
deaggregation in order to appropriately filter it.

If my reading of history is correct (as it was mostly before my time), 
we've been through something similar before, with a number of players 
filtering down to minimum allocation size for many years before routers 
caught back up with the size of the table and the filters became more of 
a problem (affecting reachability of folks not advertising their 
aggregate route) than they were worth.  But if we see a high level of 
deaggregation of allocated netblocks (without a change in the underlying 
IANA or RIR allocation), I suspect we'll see a return of these prefix 
length filters.

-Scott