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

[Kevin Kargel]

 On the topic of prefix filtering, don't forget that it will happen for
reasons other than being mean to deagregators.  As a case in point
currently the US Federal Government is forcing all ISP's to run some
sort of CALEA intercept program.  For many ISP's the best place to run
this is within the IOS on their routers.  

The problem turns up that in many routers there is not enough memory to
run both the CALEA software and a full BGP table.  One method of dealing
with this is for the ISP to implement prefix filters to limit the size
of the BGP table and free up memory to allow the router to run the
mandated CALEA.

Granted there are other ways to reduce the BGP table, but prefix
filtering is perhaps the easiest, requiring just three lines of code in
the router config and very little thought.  /16 or maybe /19 are pretty
natural points to set a filter at.  Filtering to /16 will reduce a BGP
table from over 200K routes to under 2K routes.

Anyway, my point is that deaggregated routes will likely be hurt just
because some admins take other actions to make their networks more
efficient, with no thought to restricting networks for any purpose.  I'm
not saying this is good or a good way to do things, just that it will
happen.

Kevin

:$s/worry/happy/g 

 


> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Scott Leibrand
> Sent: Wednesday, August 01, 2007 7:08 PM
> To: Paul Vixie
> Cc: ppml at arin.net
> Subject: Re: [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
> _______________________________________________
> This message sent to you through the ARIN Public Policy 
> Mailing List (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>