Hi Job,
I've been asking people about this recently. I don't particularly like
having misdirected traffic or badly configured hosts sending junk to
those who happen to be announcing addresses from this prefix. I'm
planning on adding this to a bogon filter here.
John
This should have been filtered before.
Lots of people improperly implemented this so it caused issues.
Mack
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It
they don’t want it all they have to do is withdraw the prefix. It is not up to
the rest of us to second guess their decision to keep providing support.
If you filter 2002::/16 then you are performing a denial-of-service attack on
the few sites that are still using it DELIBERATELY.
None of the problems required removing it from BGP. There were end sites that
had firewalls that blocked 6to4 responses and the odd site that ran a gateway
and failed to properly manage it. The rest could have been dealt with by
configuring more gateways. If every dual stacked ASN had run their own gateways
there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and
dump it onto IPv4 as soon as possible and take the encapsulated traffic for the
rest of IPv6 and de-encapsulate it as soon as possible.
Mark
If a ASN is announcing 2002::/16 then they are are happy to get the
traffic. It
they don’t want it all they have to do is withdraw the prefix. It is not
up to
the rest of us to second guess their decision to keep providing support.
That sounds like an interesting attack scenario where a malicious actor can
insert themselves in a path, via bgp, announcing 6to4 space
If you are using 2002::/16 you know are relying on third parties. Not that it is much
different to any other address where you are relying on third parties.
If one is going to filter 2002::/16 from BGP then install your own gateway to preserve
the functionality.
If you are using 2002::/16 you know are relying on third parties.
I highlly doubt most people using 6to4 know they are using it, let alone
the arbitrary nature of its routing.
Not that it is much
It does not appear the functionality is working at present, which I think is the more critical point. Taking a quick sampling of where I see the packets going from two different networks, it doesn’t seem to be going where it’s expected, nor is it working as expected. These appear to be at best routing leaks similar to leaking rfc6761 space that should be under your local control. They could also be seen as a privacy issue by taking packets destined to 2002::/16 somewhere unexpected and off-continent.
I would expect even in the cases where it does work, it would be subject to the same challenges faced by people using VPN services (being blocked from your kids favorite streaming services) and much poorer performance than native IPv4.
There is also the problem noted by Wes George with 6to4 being used in DNS amplification, which may be interesting..
http://iepg.org/2018-03-18-ietf101/wes.pdf
I don’t believe most providers are intending to offer 6to4 as a global service. Even the large providers (eg: Comcast) seem to have disabled it ~4+ years ago. While I know there’s people on the internet that like to hang on to legacy things, this is one that should end. The networks and devices today no longer require this sort of transition technology, and the networks where it’s left won’t want it as it will be used for various bad things(tm).
- Jared
This week I began mapping IPv6 SPAM headers "Received:" and "X-Received:"
and have discovered over 50% are from:
10.0.0.0 – 10.255.255.255
2002:0a00:: - 2002:aff:ffff:ffff:ffff:ffff:ffff:ffff
172.16.0.0 – 172.31.255.255
2002:ac10:: - 2002:ac10:ffff:ffff:ffff:ffff:ffff:ffff
192.168.0.0 – 192.168.255.255
2002:c0A8:: - 2002:c0A8:ffff:ffff:ffff:ffff:ffff:ffff
Can anyone else confirm my findings?
Joe Klein
"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8
20 years from now when the IETF decides to reclaim / repurpose that prefix,
y'all are going to have to run around removing it from your filters again...
I don’t believe most providers are intending to offer 6to4 as a global service. Even the large providers (eg: Comcast) seem to have disabled it ~4+ years ago. While I know there’s people on the internet that like to hang on to legacy things, this is one that should end. The networks and devices today no longer require this sort of transition technology, and the networks where it’s left won’t want it as it will be used for various bad things(tm).
At some point it transitions from being a legacy transition tool which
you really shouldn't be using to being an attractive nuisance, or worse
genuinely dangerous either for the sender or the receiver. personally I
think we've crossed that point and we have a responsibility to insure
proper burial.
* marka@isc.org (Mark Andrews) [Tue 19 Jun 2018, 01:35 CEST]:
If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY.
Find me one site with a competent admin that deliberately publishes 2002::/16 in DNS.
None of the problems required removing it from BGP. There were end sites that had firewalls that blocked 6to4 responses and the odd site that ran a gateway and failed to properly manage it. The rest could have been dealt with by configuring more gateways.
Could. But hasn't. Right now it's merely a security risk.
People who used to run a gateway and competently managed it took them down years ago when they, being competent admins, realised the utility had run out.
-- Niels.
I configure my DNS servers with a long-ish list of bogon addresses. For
v6, the list includes Teredo and 6to4 and various other horrors:
# RFC 5156 and IANA IPv6 address space registry
server 0000::/3 { bogus yes; };
server 2001:0000::/32 { bogus yes; };
server 2001:0002::/48 { bogus yes; };
server 2001:0010::/28 { bogus yes; };
server 2001:0db8::/32 { bogus yes; };
server 2002::/16 { bogus yes; };
server 3000::/4 { bogus yes; };
server 4000::/2 { bogus yes; };
server 8000::/1 { bogus yes; };
Tony.
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It
they don’t want it all they have to do is withdraw the prefix. It is not up to
the rest of us to second guess their decision to keep providing support.
WG] I don't think that this is intentional in most cases anymore. It's
most likely legacy cruft/zombie services. Because it mostly operates
unattended and the few that are still using it probably don't notice
when it breaks nor can they figure out to whom they should complain
because anycast makes that nearly impossible, it continues operating
quietly in the dusty and disused corners of the net below a sign saying
"beware of the leopard" until the equipment gets retired or dies of old
age. Also this argument would carry more weight if it hadn't already
been had and concluded with RFC7526, and if it wasn't completely
disabled on MS products now:
https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features#features-were-no-longer-developing
If you filter 2002::/16 then you are performing a denial-of-service attack on
the few sites that are still using it DELIBERATELY.
WG] As opposed to the unintentional denial-of-service attacks that
happen all the time because of the inherent flaws in the implementation
and the low importance people place on first-class deployments of this
service? Sites that are still using it deliberately should have found a
more reliable solution years ago, even if it's a statically-provisioned
GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate
this if native IPv6 still isn't available. Keeping this around past its
sell-by date is simply enabling bad behavior and a bad user experience
for IPv6.
Wes George
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It
they don’t want it all they have to do is withdraw the prefix. It is not up to
the rest of us to second guess their decision to keep providing support.WG] I don't think that this is intentional in most cases anymore. It's
most likely legacy cruft/zombie services. Because it mostly operates
unattended and the few that are still using it probably don't notice
when it breaks nor can they figure out to whom they should complain
because anycast makes that nearly impossible, it continues operating
quietly in the dusty and disused corners of the net below a sign saying
"beware of the leopard" until the equipment gets retired or dies of old
age. Also this argument would carry more weight if it hadn't already
been had and concluded with RFC7526, and if it wasn't completely
disabled on MS products now:
https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features#features-were-no-longer-developingIf you filter 2002::/16 then you are performing a denial-of-service attack on
the few sites that are still using it DELIBERATELY.WG] As opposed to the unintentional denial-of-service attacks that
happen all the time because of the inherent flaws in the implementation
and the low importance people place on first-class deployments of this
service? Sites that are still using it deliberately should have found a
more reliable solution years ago, even if it's a statically-provisioned
GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate
this if native IPv6 still isn't available. Keeping this around past its
sell-by date is simply enabling bad behavior and a bad user experience
for IPv6.
Actually there aren’t plenty of tunnel brokers anymore. Lots have shut
up shop in the last couple of years. HE is still there but the others
are gone or are not accepting new tunnels.
At the moment I’m waiting for sane routing between HE and Optus to move
my tunnel end point closer. Crossing the Pacific twice to get to HE’s pop
in Sydney is insane. If I used it for IPv6 traffic there would be 6 crossing
of the Pacific for most IPv6 traffic to get a IPv6 reply. That’s 4 more than
there should be.
I don’t expect Optus to offer IPv6 any time soon.
Mark
Vote with your wallet? Does Optus offer a good 6to4 gateway? Right now the 6to4 gateway
I’m routed to is too far away to even make sense. Going from a US national eyeball provider
to Prague isn’t the right solution either.
At a previous job we tried to figure out if there was value in offering commercial IPv6
tunnels that would workaround some of the problems you speak of. The problem is the
market wasn’t large enough to really justify it. I know a few folks working on offering
some commercial IPv6 transition solutions, perhaps they would be willing to sell it to
you or offer it for a freemium so you can provide feedback? I’d love to solve the physics
problem for you as well, but that’s perhaps a bit harder.
- Jared