Re: Time to add 2002::/16 to bogon filters?
2002::/16 is still valid - not a bogon as long as there is an IPv4 Internet. Add the IPv4 bogons, though (2002:7f00:::/48 through 2002:7f.ff:ff.ff::/48, & others) On July 9, 2018 3:06:00 PM PDT, "Fabien VINCENT (NaNOG)" wrote: >Le 2018-07-09 18:10, valdis.kletni...@vt.edu a écrit : > >> On Mon, 09 Jul 2018 15:21:31 +0200, "Fabien VINCENT (NaNOG)" said: >> >>> I think it's still used a bit ? I see today announcements over the >>> following OriginAS over more than 2000 peers. >>> >>> as1103SURFnet bv >>> as1835Forskningsnettet - Danish network for Research and >Education >>> as2847Kauno technologijos universitetas >>> as6939HURRICANE >>> as16150 Availo Networks AB >>> as25192 CZ.NIC, z.s.p.o. >>> as28908 A3 Sverige AB >> >> Announced and used are two different things.. :) >> >> sudo tcpdump -ni any 'net 2002::/16' tcpdump: verbose output >> suppressed, use -v or -vv for full protocol decode >> listening on any, link-type LINUX_SLL (Linux cooked), capture size >> 262144 bytes >> 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 > >> 2001:470:1f12:dead::beef.51413: UDP, length 94 >> 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 > >> 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365 > >I'm pretty sure that 2002: address is (a) *your* end of the tunnel and > >(b) >only visible inside your network and *inside* the HE tunnel to the >other >end. >In other words, it shouldn't be seen out on the public net if it's >transiting >an HE tunnel. I bet if you changed that '-i any' to '-i wlan' (for >whatever >your router calls the outbound-facing interface) you won't see traffic >on 2002: > > >You're right, it does need to be public to work ;) So my question is >why >it is still and it was announced on DFZ ? > >Regards, > >-- >FABIEN VINCENT >_@beufanet_ -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Time to add 2002::/16 to bogon filters?
Le 2018-07-09 18:10, valdis.kletni...@vt.edu a écrit : On Mon, 09 Jul 2018 15:21:31 +0200, "Fabien VINCENT (NaNOG)" said: I think it's still used a bit ? I see today announcements over the following OriginAS over more than 2000 peers. as1103SURFnet bv as1835Forskningsnettet - Danish network for Research and Education as2847Kauno technologijos universitetas as6939HURRICANE as16150 Availo Networks AB as25192 CZ.NIC, z.s.p.o. as28908 A3 Sverige AB Announced and used are two different things.. :) sudo tcpdump -ni any 'net 2002::/16' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 > 2001:470:1f12:dead::beef.51413: UDP, length 94 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 > 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365 I'm pretty sure that 2002: address is (a) *your* end of the tunnel and (b) only visible inside your network and *inside* the HE tunnel to the other end. In other words, it shouldn't be seen out on the public net if it's transiting an HE tunnel. I bet if you changed that '-i any' to '-i wlan' (for whatever your router calls the outbound-facing interface) you won't see traffic on 2002: You're right, it does need to be public to work ;) So my question is why it is still and it was announced on DFZ ? Regards, -- FABIEN VINCENT _@beufanet_
Re: Time to add 2002::/16 to bogon filters?
On Mon, 09 Jul 2018 15:21:31 +0200, "Fabien VINCENT (NaNOG)" said: > I think it's still used a bit ? I see today announcements over the > following OriginAS over more than 2000 peers. > > as1103SURFnet bv > as1835Forskningsnettet - Danish network for Research and Education > as2847Kauno technologijos universitetas > as6939HURRICANE > as16150 Availo Networks AB > as25192 CZ.NIC, z.s.p.o. > as28908 A3 Sverige AB Announced and used are two different things.. :) > > sudo tcpdump -ni any 'net 2002::/16' > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 > bytes > 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 > > 2001:470:1f12:dead::beef.51413: UDP, length 94 > 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 > > 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365 I'm pretty sure that 2002: address is (a) *your* end of the tunnel and (b) only visible inside your network and *inside* the HE tunnel to the other end. In other words, it shouldn't be seen out on the public net if it's transiting an HE tunnel. I bet if you changed that '-i any' to '-i wlan' (for whatever your router calls the outbound-facing interface) you won't see traffic on 2002: pgpu1yumLSQur.pgp Description: PGP signature
Re: Time to add 2002::/16 to bogon filters?
Le 2018-07-06 16:43, Gary McArtor a écrit : Hi Youssef, My original reply wasn't sent to the Nanog list. Team Cymru considers 2002::/16 and 192.88.99.0/24 to be legitimate prefixes at this time, and will be not be adding them to our bogon filters. Our interpretation of the 6to4 anycast rfc is that while these are encouraged to be made obsolete, in practice they may still be in use, excluding them from being universally defined as a bogon in our feed. The RFC in question: https://tools.ietf.org/html/rfc7526 The rule, as it always should be, is to know your network, and know what is best for it. As noted in the RFC you are encouraged to review any current deployments and any existing filtering and adjust based on your own discretion. Regards, Gary McArtor Team Cymru On 6/28/18 2:32 PM, Rabbi Rob Thomas wrote: FYI, the question has been raised. I'm not sure if this is wise or not. Gary, what are your thoughts? Forwarded Message Subject: Re: Time to add 2002::/16 to bogon filters? Date: Thu, 28 Jun 2018 21:11:22 +0200 From: Youssef Bengelloun-Zahr To: Job Snijders CC: NANOG [nanog@nanog.org] 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. Le 28 juin 2018 à 20:58, Job Snijders a écrit : 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 I think it's still used a bit ? I see today announcements over the following OriginAS over more than 2000 peers. as1103SURFnet bv as1835Forskningsnettet - Danish network for Research and Education as2847Kauno technologijos universitetas as6939HURRICANE as16150 Availo Networks AB as25192 CZ.NIC, z.s.p.o. as28908 A3 Sverige AB I'm pretty curious about customers impacts if your drop these anycast 6to4 prefixes from your RIB/FIB ;) At home, I use HE.net tunnel broker, because no native IPv6 (yes we already lose matches against Belgium regarding IPv6 and ... beer) and a quick dump shows traffic to 2002:/16 : sudo tcpdump -ni any 'net 2002::/16' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 15:10:59.588097 IP6 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413 > 2001:470:1f12:dead::beef.51413: UDP, length 94 15:10:59.588233 IP6 2001:470:1f12:dead::beef.51413 > 2002:6bab:c6c6:0:e561:b9f7:b221:a73.51413: UDP, length 365 So I'm pretty sure it's still used when no IPv6 is available from an eyeball provider to mount a 6to4 tunnel over a provider that have well deployed IPV6 infrastructure. Perhaps some of the 6to4 tunnel can be tuned to not use anycast prefixes ? -- FABIEN VINCENT _@beufanet_
Re: Time to add 2002::/16 to bogon filters?
Hi Youssef, My original reply wasn't sent to the Nanog list. Team Cymru considers 2002::/16 and 192.88.99.0/24 to be legitimate prefixes at this time, and will be not be adding them to our bogon filters. Our interpretation of the 6to4 anycast rfc is that while these are encouraged to be made obsolete, in practice they may still be in use, excluding them from being universally defined as a bogon in our feed. The RFC in question: https://tools.ietf.org/html/rfc7526 The rule, as it always should be, is to know your network, and know what is best for it. As noted in the RFC you are encouraged to review any current deployments and any existing filtering and adjust based on your own discretion. Regards, Gary McArtor Team Cymru On 6/28/18 2:32 PM, Rabbi Rob Thomas wrote: > FYI, the question has been raised. I'm not sure if this is wise or not. > Gary, what are your thoughts? > > > Forwarded Message > Subject: Re: Time to add 2002::/16 to bogon filters? > Date: Thu, 28 Jun 2018 21:11:22 +0200 > From: Youssef Bengelloun-Zahr > To: Job Snijders > CC: NANOG [nanog@nanog.org] > > 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. > > > >> Le 28 juin 2018 à 20:58, Job Snijders a écrit : >> >> 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 > signature.asc Description: OpenPGP digital signature
Re: Time to add 2002::/16 to bogon filters?
Hello Scott, I believe Gary has already provided the community with an official answer yesterday on Team Cymru’s behalf. Best regards. > Le 5 juil. 2018 à 21:17, Scott Fisher a écrit : > > 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 > > > On 6/28/18 3:11 PM, Youssef Bengelloun-Zahr wrote: >> 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. >> >> >> >>> Le 28 juin 2018 à 20:58, Job Snijders a écrit : >>> >>> 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 >
Re: Time to add 2002::/16 to bogon filters?
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 On 6/28/18 3:11 PM, Youssef Bengelloun-Zahr wrote: > 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. > > > >> Le 28 juin 2018 à 20:58, Job Snijders a écrit : >> >> 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 signature.asc Description: OpenPGP digital signature
Re: Time to add 2002::/16 to bogon filters?
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. > Le 28 juin 2018 à 20:58, Job Snijders a écrit : > > 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
Re: Time to add 2002::/16 to bogon filters?
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
Re: Time to add 2002::/16 to bogon filters?
> On Jun 19, 2018, at 8:03 PM, Mark Andrews wrote: > >> >> On 20 Jun 2018, at 4:16 am, Wes George wrote: >> >> On 6/18/18 7:34 PM, Mark Andrews wrote: >> >>> 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. > > 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. 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
Re: Time to add 2002::/16 to bogon filters?
> On 20 Jun 2018, at 4:16 am, Wes George wrote: > > On 6/18/18 7:34 PM, Mark Andrews wrote: > >> 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. 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 > Wes George > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Time to add 2002::/16 to bogon filters?
On 6/18/18 7:34 PM, Mark Andrews wrote: > 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 signature.asc Description: OpenPGP digital signature
Re: Time to add 2002::/16 to bogon filters?
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 - 1 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
Re: Time to add 2002::/16 to bogon filters?
Jared Mauch wrote:
>
> 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 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 ::/3{ bogus yes; };
server 2001:::/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.
--
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Cyclonic, mainly westerly, 6 to gale 8, decreasing 5 later.
Rough or very rough, becoming moderate or rough later. Showers. Moderate or
good.
Re: Time to add 2002::/16 to bogon filters?
* ma...@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.
Re: Time to add 2002::/16 to bogon filters?
On 6/18/18 6:18 PM, Jared Mauch wrote: > 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. > - Jared >
Re: Time to add 2002::/16 to bogon filters?
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. On 6/18/18 2:08 PM, Job Snijders 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 > > 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 >
Re: Time to add 2002::/16 to bogon filters?
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... -- Harald
Re: Time to add 2002::/16 to bogon filters?
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:::::: 172.16.0.0 – 172.31.255.255 2002:ac10:: - 2002:ac10:::::: 192.168.0.0 – 192.168.255.255 2002:c0A8:: - 2002:c0A8:::::: 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 On Mon, Jun 18, 2018 at 9:18 PM, Jared Mauch wrote: > > > > On Jun 18, 2018, at 8:31 PM, Mark Andrews wrote: > > > > 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. > > 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
Re: Time to add 2002::/16 to bogon filters?
> On Jun 18, 2018, at 8:31 PM, Mark Andrews wrote: > > 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. 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
Re: Time to add 2002::/16 to bogon filters?
On Mon, Jun 18, 2018 at 5:31 PM Mark Andrews wrote: > 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 > 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. > > > On 19 Jun 2018, at 10:23 am, Ca By wrote: > > > > > > > > On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews wrote: > > 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 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 > > > On 19 Jun 2018, at 8:56 am, McBride, Mack > wrote: > > > > > > This should have been filtered before. > > > Lots of people improperly implemented this so it caused issues. > > > > > > Mack > > > > > > -Original Message- > > > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John > Kristoff > > > Sent: Monday, June 18, 2018 3:48 PM > > > To: Job Snijders > > > Cc: NANOG [nanog@nanog.org] > > > Subject: Re: Time to add 2002::/16 to bogon filters? > > > > > > On Mon, 18 Jun 2018 21:08:05 + > > > Job Snijders wrote: > > > > > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > > > > > 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 > > > E-MAIL CONFIDENTIALITY NOTICE: > > > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are notified > that any use, dissemination, distribution, cop > <https://maps.google.com/?q=ed+that+any+use,+dissemination,+distribution,+cop=gmail=g>ying, > or storage of this message or any attachment is strictly prohibited. > > > > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > >
Re: Time to add 2002::/16 to bogon filters?
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. > On 19 Jun 2018, at 10:23 am, Ca By wrote: > > > > On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews wrote: > 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 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 > > On 19 Jun 2018, at 8:56 am, McBride, Mack > > wrote: > > > > This should have been filtered before. > > Lots of people improperly implemented this so it caused issues. > > > > Mack > > > > -Original Message- > > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff > > Sent: Monday, June 18, 2018 3:48 PM > > To: Job Snijders > > Cc: NANOG [nanog@nanog.org] > > Subject: Re: Time to add 2002::/16 to bogon filters? > > > > On Mon, 18 Jun 2018 21:08:05 + > > Job Snijders wrote: > > > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > > > 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 > > E-MAIL CONFIDENTIALITY NOTICE: > > The contents of this e-mail message and any attachments are intended solely > > for the addressee(s) and may contain confidential and/or legally privileged > > information. If you are not the intended recipient of this message or if > > this message has been addressed to you in error, please immediately alert > > the sender by reply e-mail and then delete this message and any > > attachments. If you are not the intended recipient, you are notified that > > any use, dissemination, distribution, copying, or storage of this message > > or any attachment is strictly prohibited. > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Time to add 2002::/16 to bogon filters?
On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews wrote: > 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 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 > > On 19 Jun 2018, at 8:56 am, McBride, Mack > wrote: > > > > This should have been filtered before. > > Lots of people improperly implemented this so it caused issues. > > > > Mack > > > > -Original Message- > > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff > > Sent: Monday, June 18, 2018 3:48 PM > > To: Job Snijders > > Cc: NANOG [nanog@nanog.org] > > Subject: Re: Time to add 2002::/16 to bogon filters? > > > > On Mon, 18 Jun 2018 21:08:05 + > > Job Snijders wrote: > > > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > > > 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 > > E-MAIL CONFIDENTIALITY NOTICE: > > The contents of this e-mail message and any attachments are intended > solely for the addressee(s) and may contain confidential and/or legally > privileged information. If you are not the intended recipient of this > message or if this message has been addressed to you in error, please > immediately alert the sender by reply e-mail and then delete this message > and any attachments. If you are not the intended recipient, you are > notified that any use, dissemination, distribution, copying, or storage of > this message or any attachment is strictly prohibited. > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > >
Re: Time to add 2002::/16 to bogon filters?
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 > On 19 Jun 2018, at 8:56 am, McBride, Mack wrote: > > This should have been filtered before. > Lots of people improperly implemented this so it caused issues. > > Mack > > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff > Sent: Monday, June 18, 2018 3:48 PM > To: Job Snijders > Cc: NANOG [nanog@nanog.org] > Subject: Re: Time to add 2002::/16 to bogon filters? > > On Mon, 18 Jun 2018 21:08:05 + > Job Snijders wrote: > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > 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 > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely > for the addressee(s) and may contain confidential and/or legally privileged > information. If you are not the intended recipient of this message or if this > message has been addressed to you in error, please immediately alert the > sender by reply e-mail and then delete this message and any attachments. If > you are not the intended recipient, you are notified that any use, > dissemination, distribution, copying, or storage of this message or any > attachment is strictly prohibited. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Time to add 2002::/16 to bogon filters?
> On Jun 18, 2018, at 5:08 PM, Job Snijders 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
RE: Time to add 2002::/16 to bogon filters?
This should have been filtered before. Lots of people improperly implemented this so it caused issues. Mack -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff Sent: Monday, June 18, 2018 3:48 PM To: Job Snijders Cc: NANOG [nanog@nanog.org] Subject: Re: Time to add 2002::/16 to bogon filters? On Mon, 18 Jun 2018 21:08:05 + Job Snijders wrote: > TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? 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 E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
Re: Time to add 2002::/16 to bogon filters?
On Mon, 18 Jun 2018 21:08:05 + Job Snijders wrote: > TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? 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
Time to add 2002::/16 to bogon filters?
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
