CloudFlare IPv6 BGP announcements - WTF guys?

Jared Mauch jared at puck.nether.net
Tue Jul 17 14:53:24 CEST 2012


On Jul 16, 2012, at 5:36 PM, Sascha Luck wrote:

> So rules and regulations should supercede operational
> necessities, such as they may be?
> The Internet has changed since 1995 and the system devised by the wise old men does just not fit the current usage anymore. 
> If allocation/assignment policies do not fit the current use cases anymore, *policies* will have to change rather than forcing operators into a model designed by a few
> people in the 1990s. This may or may not also involve the design of a routing
> protocol that can handle this new paradigm.
> 
>> that's not my opinion so much as a fact of life given
>> that AS operators can and do perform strict filtering of the IPv6 DFZ.
> 
> Which, IMO does a lot more harm to ipv6 adoption than
> a few deagreggated /48s in a routing table that is by no means crowded (yet) anyway.
> 
> inet6.0: 9587/9587/9587/0
> 
> meh, excuse me for not panicking just yet...

I think the issue here is people that feel entitled to pollute a global network of routers, etc and impose their policy upon my network.

There are community driven models of this, through the RIR.  Keeping IPv6 table growth reasonably by complying with these policies isn't that hard.  I think that's the problem that myself and others see here.  If you feel entitled to announce a few /64's or /128's to your ISP and they accept them, then great.  That doesn't mean they are globally reachable. 

CloudFlare may have legitimate reasons for doing what they are here.  It could also be that getting a large block was easy and they figured they could deagg and not ask for a few more blocks per site.  They could be in the process of building a network backbone and not have the ability to connect these sites together.  They could have regional geopolitical reasons for segmenting this traffic.

I think the challenge here is that most people expect their prefix to be visible in the global DFZ.  Those spaces cost money.  While you're showing the output from some sort of juniper device, some platforms use TCAM that has to be partitioned at boot-time. Even if there is 'space', it may not be carved properly and the variance in growth in the v4 vs v6 speeds combined with the fact that customers have an unrealistic expectation that there will be no reboots of their devices means: You can't fix the problem until its an emergency in another 2-3 years.

While its just "one slot" here and there, holding the line on this is an important alignment between RIR allocation policies and the global backbone operators that didn't exist in the past.  This may change, but right now those deploying IPv6 tend to be seasoned enough in the cost and risks involved here.  You may think we're all saying "get off my lawn/routing table" but there are real costs of these entries in the RIB + FIB.  I would rather not see a model where you're billed based on your pollution, but that was the Sean Doran model of "send me a check" for use of my FIB entry.  I can assign a cost to it, can you?

- Jared


More information about the ipv6-ops mailing list