On Jun 18, 2018, at 5:08 PM, Job Snijders <job@ntt.net> wrote:

Dear all,

TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?

It is kind of strange that in the default-free zone (where we don’t announce defaults to each other) - we will propagate what is effectively an IPv4 default-route, in the IPv6 DFZ.

IETF has politely abandoned the prefix: https://tools.ietf.org/html/rfc7526

I don’t believe there is a reason that folks should accept this prefix from a transit/peer. If they have need for 6to4 within their network, they should operate their own local 6to4 relays. It seems native IPv6 is fairly widely available: https://www.google.com/intl/en/ipv6/statistics.html And there is almost zero 6to4 activity in those stats as well. Since it’s a known path for abuse as well, I would expect networks to not carry these IPv6 routes and filter them. - Jared

Job Snijders wrote on 18/06/2018 22:08:

Is there still really any legit reason left to accept, or propagate, 2002::/16 on EBGP sessions in the DFZ?

Out of curiosity, I ran a some atlas probe ping tests earlier today to both a 6to4 test host and a separate control host with good quality v6 connectivity: - 11000 6to4 probe requests - 10000 native ipv6 probe requests - 10 pings each - 3308 unique probes replied - 2907 attempted to ping both 6to4 and control hosts - 2569 could ping the control host - 2271 could ping the 6to4 host I.e. ~12% of probes were able to ping the control host, but not the 6to4 host. If anyone wants the measurement IDs, please let me know. Contrary to what Mark implied earlier in this thread about 6to4 connectivity failure being an end-site phenomenon, this figure is caused solely by intermediate path problems. If, as he suggested, end-site problems also contribute to poor quality 6to4 connectivity, then that would compound the failure result. From an operational point of view, what's relevant is whether dropping 2002::/16 would materially affect reliability for 6to4 users. Most serious studies into 6to4 connectivity have shown that it causes high failure rates, so arguably it could be seen as an improvement if you had consistent 100% failure instead of double-digit percentage failure rates to arbitrary 6to4 hosts. Consistency is intrinsically valuable. Despite this, the case for organised action is unclear. If individual operators want to drop the prefix, then that's their concern. If they choose to do so, I suspect that the reaction of most of the ipv6 world will be indifference. Nick