Routing problems to www.eurovision.tv 2400:CB00::/32 CLOUDFLARE

Michael Sinatra michael at rancid.berkeley.edu
Fri Jun 15 19:45:00 CEST 2012 

There are really two responses to this:

One is that if you have a /32 out of the LIR allocation address block 
from your RIR, and you don't announce the covering prefix, there are 
people out there who WILL filter you.  Period.

Plenty of example filters exist out there that do this sort of strict 
filtering; see for example Gert Doering's "strict" filter in section 5.2 
here:

http://www.space.net/~gert/RIPE/ipv6-filters.html

As you can see from this thread, there are plenty of people out there 
who use filters like this.  From the perspective of a content provider, 
if I don't at least announce a covering prefix with global reachability, 
I will have unreliable IPv6.  That's your trade-off.  And by the way, 
"just carry a default" sounds an awful lot like "let them eat cake."  I 
could go into the whole tragedy-of-the-commons-route-table argument 
here, but that's been done many times before.

The second response is from the network operators' (i.e. my) 
perspective.  I am pretty much resigned to accepting down to /48s from 
*some* peers, i.e. not from those who are expensive and/or 
low-bandwidth.  There are two reasons for this:

1. Making my own routing policy beholden to the moving target of RIR 
IPv6 policy may not be the best strategy (and I have to keep up with 
policy and addressing changes).

2. I want to provide good service to my customers (in this case US 
National Labs) and that means making sure that I carry the full route 
table and don't filter the content they need.

In the run-up to World IPv6 Launch, I audited my peerings and the routes 
I was receiving.  Cloudflare was an obvious case of /48s out of a 
/32-or-shorter allocation space with no covering prefix, but there were 
a handful of others.  I made exceptions for those routes.

To me, it was annoying, but I viewed it as something I had to do.  Many 
other operators don't have the time or desire to write a bunch of 
scripts to capture all of the filtered routes and flag the ones that 
aren't covered by shorter prefixes.  My point is that operators probably 
SHOULD carry down to /48s, but they're not required to, and content 
providers who do what Cloudflare does, do so at their own risk.

michael

On 06/15/12 09:42, Tom Paseka wrote:
> Hi Chris,
>
> Understand this, but the filtering in tern is going to leave you
> disconnected from very large portions of the internet. CloudFlare is not
> the only provider using routing like this, without an aggregate matching
> the minimum allocation size.
>
> Large numbers of content providers (not just CloudFlare) who do not
> operate contiguous networks are doing this so. We are discontiguous, so
> are unable to route between nodes internally. There are also many access
> providers who are not announcing the full subset of their routes, so
> reachability will be a problem.
>
> You may note, all Tier-1 carriers are carrying our routes today and I
> can see from your looking glass that you are receiving our routes, just
> filtering.
>
> I understand you want to protect your routers memory, however, could you
> install default routes? As I mentioned there are many other parts of the
> IPv6 table that you'll be missing out on, without either accepting the
> full table, or a default.
>
> Best Regards,
> Tom
>
>
>
> On Fri, Jun 15, 2012 at 9:28 AM, Chris Welti <chris.welti at switch.ch
> <mailto:chris.welti at switch.ch>> wrote:
>
>     Hello Tom,
>
>     Then you should have applied for /48 portable address space for all
>     your different regions.
>     APNIC has a separate address space for this in 2001:0C00:/23
>     See
>     http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations
>     We strictly filter by minimum allocation polices of the RIR and
>     don't make exceptions.
>     The problem with just accepting all /48 is that you end up with a
>     lot of unnecessary /48 deaggregations in the table, even if there
>     would be a covering /32.
>
>     Btw within your AS you should be able to route all your prefixes
>     yourself, otherwise it wouldn't be an autonomous system :)
>
>     Regards,
>     Chris
>
>     Am 6/15/12 6:08 PM, schrieb Tom Paseka:
>      > Hello Chris,
>      >
>      > CloudFlare operates a discontiguous network and we are unable to
>     announce the /32.
>      >
>      > The /48 is a valid announcement for the global table. While we
>     understand there are some concerns about de-aggergation, aggregation
>     is not possible and we would either be announcing the deaggregated
>     address space from a single assignment, or we'd have multiple
>     assignments for the same purpose, so the impact on the routing table
>     would be the same.
>      >
>      > If the full table can not be accepted, I would recommend
>     installing a default route to one or all of your upstreams,
>     otherwise many parts of the global table will not be reachable, not
>     just to CloudFlare.
>      >
>      > Thanks,
>      > Tom
>      >
>      > On Fri, Jun 15, 2012 at 8:57 AM, Chris Welti
>     <chris.welti at switch.ch <mailto:chris.welti at switch.ch>
>     <mailto:chris.welti at switch.ch <mailto:chris.welti at switch.ch>>> wrote:
>      >
>      >     This could be because there is no covering 2400:CB00::/32
>     route by Cloudflare in the global IPv6 routing table.
>      >     There is only 2400:CB00:2048::/48 and this might be filtered
>     by ISPs due to the APNIC miniumum allocation size of /32 for 2400::/12.
>      >     Cloudflare must announce at least the covering /32 for it to
>     be globally reachable.
>      >
>      >     Regards,
>      >
>      >     Chris
>      >     AS559
>      >
>      >     Am 6/15/12 4:08 PM, schrieb Thomas Schäfer:
>      > > The (web) access to
>      > >
>      > > www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv>
>      > >
>      > > has some problems:
>      > >
>      > > from LRZ/DFN                           ok
>      > > from Sixxs-Tunnel                      failed
>      > > via http://ipv6-test.com/validate.php ok
>      > > via sixy.ch <http://sixy.ch> <http://sixy.ch> (adding failed)
>              failed
>      > >
>      > >
>      > > traceroute from sixxs
>      > >
>      > >
>      > >
>      > > traceroute www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv>
>      > > traceroute to www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv> (2400:cb00:2048:1::6ca2:c904), 30 hops
>     max, 40 byte packets using UDP
>      > >  1  fritz.box (2001:6f8:120c:0:21c:4aff:fe28:8a31)  0.664 ms
>     0.489 ms   0.504 ms
>      > >  2 gw-892.ham-01.de.sixxs.net
>     <http://gw-892.ham-01.de.sixxs.net>
>     <http://gw-892.ham-01.de.sixxs.net> (2001:6f8:900:37b::1)  39.374 ms
>     38.900 ms   38.261 ms
>      > >  3  2001:6f8:862:1::c2e9:c729 (2001:6f8:862:1::c2e9:c729)
>       38.653 ms 37.531 ms   36.400 ms
>      > >  4 vl2280.cr10.noham.de.easynet.net
>     <http://vl2280.cr10.noham.de.easynet.net>
>     <http://vl2280.cr10.noham.de.easynet.net>
>     (2001:6f8:862:1::c2e9:c72c) 44.705 ms   43.567 ms   42.446 ms
>      > >  5  2001:6f8:1:0:87:86:69:214 (2001:6f8:1:0:87:86:69:214)
>     41.202 <tel:214%29%2041.202> <tel:214%29%20%2041.202> ms * *
>      > >  6  2001:6f8:1:0:87:86:77:83 (2001:6f8:1:0:87:86:77:83)  37.765
>     ms * *
>      > >  7  2001:6f8:1:0:87:86:77:62 (2001:6f8:1:0:87:86:77:62)  51.138
>     ms * *
>      > >  8  2001:6f8:1:0:87:86:77:71 (2001:6f8:1:0:87:86:77:71)  44.403
>     ms * *
>      > >  9  2001:6f8:1:0:87:86:77:15 (2001:6f8:1:0:87:86:77:15)  53.309
>     ms * *
>      > > 10  2001:6f8:1:0:87:86:77:47 (2001:6f8:1:0:87:86:77:47)  58.516
>     ms * *
>      > > 11  2001:7f8:1::a501:3335:1 (2001:7f8:1::a501:3335:1)(H!)
>       2100.484 ms * *
>      > >
>      > >
>      > > LANG=C wget -6 www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv>
>      > > asking libproxy about url 'http://www.eurovision.tv/'
>      > > libproxy suggest to use 'direct://'
>      > > --2012-06-15 16:07:55-- http://www.eurovision.tv/
>      > > Resolving www.eurovision.tv... 2400:cb00:2048:1::6ca2:cb04,
>     2400:cb00:2048:1::6ca2:cc04, 2400:cb00:2048:1::6ca2:cd04, ...
>      > > Connecting to www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv>|2400:cb00:2048:1::6ca2:cb04|:80...
>     failed: No route to host.
>      > > Connecting to www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv>|2400:cb00:2048:1::6ca2:cc04|:80...
>     failed: No route to host.
>      > > Connecting to www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv>|2400:cb00:2048:1::6ca2:cd04|:80...
>     failed: No route to host.
>      > > Connecting to www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv>|2400:cb00:2048:1::6ca2:ca04|:80...
>     failed: No route to host.
>      > > Connecting to www.eurovision.tv <http://www.eurovision.tv>
>     <http://www.eurovision.tv>|2400:cb00:2048:1::6ca2:c904|:80...
>     failed: No route to host.
>      > >
>      > >
>      > >
>      > >
>      > >
>      > >
>      > > Regards,
>      > >
>      > > Thomas Schäfer
>      > >
>      > >
>      > >
>      >
>      >
>
>

More information about the ipv6-ops mailing list