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
Wes George highlighted operational problems from accepting 2002::/16 on the
data-plane slide 6:
http://iepg.org/2018-03-18-ietf101/wes.pdf
Is there still really any legit reason left to accept, or propagate,
2002::/16 on EBGP sessions in the DFZ?
Kind regards,
Job
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
I personally would love to see social pressure applied removing this
from the internet.
certain prominent google search results. e.g.
https://getipv6.info/display/IPv6/Linux+or+BSD+6to4+Relays probably also
could use some curation given the appropriateness of reling on a anycast
translator for your transition at this point.
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
Dear alll,
Thank you all for your input. Just a heads-up - we deployed a few days ago.
NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32”
to be bogon prefixes, and no longer accepts announcements for these
destinations from any EBGP neighbor.
Kind regards,
Job
Hello Job,
Thank you for this feedback. I guess that NTT adopting this as a best practice will ring some bells around.
Do you know if Team Cymru has updated their filters accordingly ?
Best regards.
Youssef & all,
My team will investigate this and get back to the list on what we are
going to do.
Thanks,
Scott Fisher
Systems Engineer
Team Cymru
Hello Scott,
I believe Gary has already provided the community with an official answer yesterday on Team Cymru’s behalf.
Best regards.