[ppml] NANOG IPv4 Exhaustion BoF
John Curran
jcurran at istaff.org
Fri Mar 7 08:44:26 EST 2008
At 7:17 PM +1100 3/7/08, Geoff Huston wrote:
>
>The sad fact is that the global routing table has been under concentrated assault by the legions of /24s for many years now.
>
>Since 2001 50% of the routing table is more specifics - and now there are 135,208 of them. My supposition is that TE is the major factor - when you look at highly deaggregated prefixes you tend to see a collection of upstreams and load spreading across the upstreams.
>
>So in many ways the routing system is already under this "fragmentation" pressure and will remain so whether its IPv4 or IPv6
Agreed, but I'll note that every day hundreds of new entities
connect up to the Internet via PA space with no fragmentation
as a result. Further, ISP's can make conscience decisions to
inject routes for TE and to filter others TE more specifics.
In a post-depletion scenario where customers want IPv4
connectivity and bring their own blocks, ISPs have little
choice but to accept the customers (and inject the route)
rather than sending them to a competitor. This includes
customers showing up with just a /30 and NAT CPE...
There's no reason to think that the number of new sites
per unit time is declining, so it's really a question of the
number of new routes to cover the same growth rate.
>As I understand your argument here John its that fragmented address supply won't make it any better, but it could make it worse, and that could trigger responses such as selective filtering, threatening global connectivity. Yes, thats a valid concern. Without much data to quantify the risk its hard to assess how critical this factor will be.
To rephrase slightly: a fragmented IPv4 address supply, made
available to individual end sites via transfer policy, *will* make
it much, much worse, and inevitably require a high degree of
selective filtering. It still remains to be seen whether any RIR
adopts a transfer policy which creates such an address supply.
/John
More information about the ARIN-PPML
mailing list