Atlas probes and 6to4 [Re: IPv6 ingress filtering]

[Brian E Carpenter]

On 18-May-19 08:46, Nick Hilliard wrote:
> Brian E Carpenter wrote on 17/05/2019 21:06:
>> And surely the question is "What would produce the most help desk calls?".
>> Filtering something that is presumably working for its remaining users
>> might not be a good idea from that point of view.
> 
> 6to4 connectivity is probably already too broken to use.  Here are some 
> atlas measurements from a couple of days ago:
> 
> https://atlas.ripe.net/measurements/21449877/
> https://atlas.ripe.net/measurements/21449878/
> https://atlas.ripe.net/measurements/21449879/
> 
> This was 3-packet ping from the same 1000 probes to three ipv6 hosts. 
> The results were:
> 
> server in IE: 14.5% unreachability
> www.kame.net: 15.0% unreachability
> random 6to4 address: 23.1% unreachability
> 
> What's also unfortunate is after downloading the json results:
> 
>> % cat *.txt | jq '.[] | select (.rcvd == 0) | .from' | cut -d\" -f2 | grep ^2002 | sort | uniq -c
>>    2 2002:2ea7:331c:0:1ad6:c7ff:fe2a:1a7c
>>    1 2002:4e1a:aba9:10:fa1a:67ff:fe4d:7ee9
>>    1 2002:4e79:421e:0:a62b:b0ff:fee0:ae0
>>    1 2002:5253:a51b:0:1:e3ff:febb:121b
>>    2 2002:55d4:648c:0:f6f2:6dff:fe5d:a19c
>>    1 2002:566:3896:0:6666:b3ff:feb0:e87a
>>    3 2002:568:1047:1:220:4aff:fee0:20ac
>>    2 2002:592:4daf:0:1:7dff:feac:317e
>>    2 2002:5aba:3e12:1:eade:27ff:fe69:b644
>>    1 2002:5b64:65f8:0:a62b:b0ff:fee0:1572
>>    2 2002:5b73:5fdd:ffff:c66e:1fff:fe3a:d118
>>    2 2002:8603:d75b:0:280:a3ff:fe91:408d
>>    1 2002:b2f8:fe64:0:a2f3:c1ff:fec4:591c
>>    2 2002:d58f:794c:0:eade:27ff:fe69:c8fa
>>    2 2002:d5d1:57ac:1:c24a:ff:fecc:99fa
>> %

What does the leading digit (1, 2 or 3) mean? Because all
those with "1" are pingable from here, but none of the others.

> I.e. 1.5% of the sample probes were using 6to4.  Of these, 8 had 
> connectivity to the two control hosts, but not to the 6to4 host.  This 
> is awful!

If they are nodes using the deprecated anycast solution to get their
6to4 connectivity, this is unfortunately the expected result, and exactly
why we deprecated it. But in any case, Atlas probes with 6to4 addresses
seems pathological to me. However, there is a bit more to learn (see
below).

> Anyway, none of this exceeds the level of "anecdatum", but it's 
> potentially interesting nonetheless, and it does suggest connectivity 
> problems between the 6to4 network and chunks of the native ipv6 internet.

Yes, and if they are *not* using the anycast solution, it means that
the return path via a route to 2002::/16 is not working.

I tried to traceroute one of them (Probe #3009) at
2002:568:1047:1:220:4aff:fee0:20ac
and it petered out at 6to4.tyo1.he.net [2001:470:0:17a::2]

The embedded IPv4 address is 5.104.16.71, which is reachable,
and is indeed the published address of probe #3009, so it does
indeed look like a failure in the return relay path.

The same thing for a couple of other of the probes tagged "2"
or "3" in the above list, chosen at random.

But the ones tagged "1" seem to work. For example,
2002:566:3896:0:6666:b3ff:feb0:e87a works. Its embeded IPv4
address is 5.71.38.96, which allegedly belongs to BSKYB in
the UK. (It's probably probe #13420 whose details are private.)

Dear he.net, RFC3056 says that a site MUST NOT advertise a route
to 2002::/16 unless it's willing to act as a relay router, which
means relaying to *any* IPv4 address. Could it be that 6to4.tyo1.he.net
is only willing to relay to a limited set of IPv4 addresses? If so, 
the external BGP4 route to 2002::/16 needs to die. If not, the problem
lies elswhere.

(Why do I bother, not being an operator? Maybe some slight guilt
at having propagated 6to4 in the first place...)

   Brian