Newbie Needs Help: someone is announcing less-specific IPv6 (BGP) route on top of me
Dear Gurus, Radar tool by Qrator [Reference: https://radar.qrator.net ] claims that Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’ on top of my more-specific address block. The tool classifies it as a type of hijacking. [Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the information I received] My neighboring organization also has a more-specific block that falls under The Umbrella too. However, other tools (https://stat.ripe.net , https://irrexplorer.nlnog.net , https://bgp.he.net , etc.) seem unable to see that particular announcement. Questions: 1. Is Qrator claim true? (because I have already tried but cannot verify) 2. If so, should I be concerned? Even though I already ROA-ed *and* IRR-ed my own block, but if “the other end” doesn’t validate, it won’t do any good, correct? (Oh, yeah, the other end also has to somehow “not see” my longer-prefix. But that can happen as well, no?) 3. In that case, what more do I must do? I would extremely appreciate someone helping me out on this matter. Best Regards, Pirawat.
Am 30.08.2025 um 13:58:21 Uhr schrieb Pirawat WATANAPONGSE via NANOG:
Radar tool by Qrator [Reference: https://radar.qrator.net ] claims that Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’ on top of my more-specific address block.
What is your address block? Is it assigned to you and your ASN? I assume the toll doesn't distinguish between whois allocation info and real BGP data.
The tool classifies it as a type of hijacking.
HE shows that 2400::/20 is assigned to KRNIC, but not announced / propagated via BGP. Normal behavior. Whois shows that it is assigned to KRNIC.
[Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the information I received] My neighboring organization also has a more-specific block that falls under The Umbrella too.
Name it.
However, other tools (https://stat.ripe.net , https://irrexplorer.nlnog.net , https://bgp.he.net , etc.) seem unable to see that particular announcement.
Maybe they drop it.
Questions: 1. Is Qrator claim true? (because I have already tried but cannot verify) 2. If so, should I be concerned?
Check the looking glass of peers. Or ask their netmaster address.
Even though I already ROA-ed *and* IRR-ed my own block, but if “the other end” doesn’t validate, it won’t do any good, correct?
If they accept your route, it will be preferred because it is more specific.
(Oh, yeah, the other end also has to somehow “not see” my longer-prefix. But that can happen as well, no?)
It can, but then communication is not possible anyway. They would receive your traffic and reject it via ICMP route unreachable, as they don't have a more specific route, unless they intentionally want to do nasty things.
3. In that case, what more do I must do?
Ask them not to do so, other options don't really exist. -- Gruß Marco Send unsolicited bulk mail to 1756555101muell@cartoonies.org
According to RIPEStat, 2400::/12 hasn't been seen since Oct 2023, from AS13030 (Init7). I also cannot seem to see any recent announcement of that anywhere in the usual sources, or my internal data. I would say this was an error on Qrator's part. In that case, what more do I must do? Although it didn't seem to happen here, best practice is to always announce 100% of your allocated IPs at all times. This provides protection against someone announcing an umbrella and pulling traffic for any uncovered space. It's not perfect , but protects against general stupid. On Sat, Aug 30, 2025 at 2:59 AM Pirawat WATANAPONGSE via NANOG < nanog@lists.nanog.org> wrote:
Dear Gurus,
Radar tool by Qrator [Reference: https://radar.qrator.net ] claims that Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’ on top of my more-specific address block. The tool classifies it as a type of hijacking. [Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the information I received] My neighboring organization also has a more-specific block that falls under The Umbrella too.
However, other tools (https://stat.ripe.net , https://irrexplorer.nlnog.net , https://bgp.he.net , etc.) seem unable to see that particular announcement.
Questions: 1. Is Qrator claim true? (because I have already tried but cannot verify) 2. If so, should I be concerned? Even though I already ROA-ed *and* IRR-ed my own block, but if “the other end” doesn’t validate, it won’t do any good, correct? (Oh, yeah, the other end also has to somehow “not see” my longer-prefix. But that can happen as well, no?) 3. In that case, what more do I must do?
I would extremely appreciate someone helping me out on this matter.
Best Regards,
Pirawat. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GT2M54NG...
As long as you advertise more specific routes, your routes will always win. So not a problem that I can see. -mel
On Aug 30, 2025, at 5:57 AM, Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
According to RIPEStat, 2400::/12 hasn't been seen since Oct 2023, from AS13030 (Init7).
I also cannot seem to see any recent announcement of that anywhere in the usual sources, or my internal data. I would say this was an error on Qrator's part.
In that case, what more do I must do?
Although it didn't seem to happen here, best practice is to always announce 100% of your allocated IPs at all times. This provides protection against someone announcing an umbrella and pulling traffic for any uncovered space. It's not perfect , but protects against general stupid.
On Sat, Aug 30, 2025 at 2:59 AM Pirawat WATANAPONGSE via NANOG < nanog@lists.nanog.org> wrote:
Dear Gurus,
Radar tool by Qrator [Reference: https://radar.qrator.net ] claims that Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’ on top of my more-specific address block. The tool classifies it as a type of hijacking. [Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the information I received] My neighboring organization also has a more-specific block that falls under The Umbrella too.
However, other tools (https://stat.ripe.net , https://irrexplorer.nlnog.net , https://bgp.he.net , etc.) seem unable to see that particular announcement.
Questions: 1. Is Qrator claim true? (because I have already tried but cannot verify) 2. If so, should I be concerned? Even though I already ROA-ed *and* IRR-ed my own block, but if “the other end” doesn’t validate, it won’t do any good, correct? (Oh, yeah, the other end also has to somehow “not see” my longer-prefix. But that can happen as well, no?) 3. In that case, what more do I must do?
I would extremely appreciate someone helping me out on this matter.
Best Regards,
Pirawat. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GT2M54NG...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/47LPGUEA...
I looked at some RIS (and routeviews) MRT data. First I looked at BGP updates: * There were no BGP updates captured by RIPE RIS between 2025-08-12..2025-08-26 for 2400::/12. * The largest prefix in 2400::/12 for which updates/withdraws were seen in that period was 2400:2000::/20. When I look at the combined RIS+routeviews RIBS at 08:00 UTC on 2025-08-30, these are the largest prefixes in 2400::/12 and their visibility: ┌────────────────┬────────────┐ │ prefix │ visibility │ │ │ (peers) │ ├────────────────┼────────────┤ │ 2400:2000::/20 │ 689 │ │ 2400:4000::/22 │ 690 │ │ 2400:6280::/30 │ 268 │ │ 2400:7b80::/30 │ 799 │ │ 2400:a840::/31 │ 795 │ │ 2400:a842::/31 │ 795 │ │ 2400:a844::/31 │ 795 │ │ 2400:a846::/31 │ 795 │ │ 2400:a848::/31 │ 795 │ │ 2400:a84a::/31 │ 795 │ │ 2400:a84c::/31 │ 795 │ │ 2400:a84e::/31 │ 795 │ │ 2400:a980::/29 │ 777 │ │ 2400:ca00::/28 │ 792 │ │ 2400:d800::/30 │ 780 │ │ 2400:d800::/31 │ 780 │ │ 2400:dd00::/28 │ 693 │ If 2400::/12 was widely visible, it indicates a gap in the coverage of routeviews and RIS. I can’t speak for routeviews, but as RIS project we would be very happy to add peers that cover such a blindspot. We want to make data analysis like I just did easier. We have a prototype for a new way to search in MRT data. It started as an internal research/debugging aid, but we want to start releasing pre-processed data soon. If things work out I will do a talk on this at the next RIPE and NANOG meetings on this way to search in BGP data - the talk is about to be submitted. Kind regards, Ties On Sat, 30 Aug 2025 at 14:56, Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
According to RIPEStat, 2400::/12 hasn't been seen since Oct 2023, from AS13030 (Init7).
I also cannot seem to see any recent announcement of that anywhere in the usual sources, or my internal data. I would say this was an error on Qrator's part.
In that case, what more do I must do?
Although it didn't seem to happen here, best practice is to always announce 100% of your allocated IPs at all times. This provides protection against someone announcing an umbrella and pulling traffic for any uncovered space. It's not perfect , but protects against general stupid.
On Sat, Aug 30, 2025 at 2:59 AM Pirawat WATANAPONGSE via NANOG < nanog@lists.nanog.org> wrote:
Dear Gurus,
Radar tool by Qrator [Reference: https://radar.qrator.net ] claims that Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’ on top of my more-specific address block. The tool classifies it as a type of hijacking. [Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the information I received] My neighboring organization also has a more-specific block that falls under The Umbrella too.
However, other tools (https://stat.ripe.net , https://irrexplorer.nlnog.net , https://bgp.he.net , etc.) seem unable to see that particular announcement.
Questions: 1. Is Qrator claim true? (because I have already tried but cannot verify) 2. If so, should I be concerned? Even though I already ROA-ed *and* IRR-ed my own block, but if “the other end” doesn’t validate, it won’t do any good, correct? (Oh, yeah, the other end also has to somehow “not see” my longer-prefix. But that can happen as well, no?) 3. In that case, what more do I must do?
I would extremely appreciate someone helping me out on this matter.
Best Regards,
Pirawat. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GT2M54NG... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/47LPGUEA...
2400::/12 is larger than any prefix allocated to a network. In fact it's a prefix allocated to ARIN, which sub-allocates prefixes to various North American networks. A route to 2400::/12 is effectively a route to North America - well, part of it, because ARIN has more than one prefix. Network operators can announce whatever they want to their customers. It's not uncommon for some customers to get summarized routes. Some ISP far away from America could be telling its customers "yes, I know how to get to North America". This radar tool seems to be showing what ISPs tell it, without filtering such ISP-specific routes. You can see other "invalid" routes such as /128 routes in the same tool. Such routes won't propagate across the whole internet, by convention, but there's no rule that a single ISP can't use them. On 30 August 2025 08:58:21 CEST, Pirawat WATANAPONGSE via NANOG <nanog@lists.nanog.org> wrote:
Dear Gurus,
Radar tool by Qrator [Reference: https://radar.qrator.net ] claims that Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’ on top of my more-specific address block. The tool classifies it as a type of hijacking. [Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the information I received] My neighboring organization also has a more-specific block that falls under The Umbrella too.
However, other tools (https://stat.ripe.net , https://irrexplorer.nlnog.net , https://bgp.he.net , etc.) seem unable to see that particular announcement.
Questions: 1. Is Qrator claim true? (because I have already tried but cannot verify) 2. If so, should I be concerned? Even though I already ROA-ed *and* IRR-ed my own block, but if “the other end” doesn’t validate, it won’t do any good, correct? (Oh, yeah, the other end also has to somehow “not see” my longer-prefix. But that can happen as well, no?) 3. In that case, what more do I must do?
I would extremely appreciate someone helping me out on this matter.
Best Regards,
Pirawat. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GT2M54NG...
Am 30.08.2025 um 18:54:15 Uhr schrieb nanog--- via NANOG:
2400::/12 is larger than any prefix allocated to a network. In fact it's a prefix allocated to ARIN, which sub-allocates prefixes to various North American networks.
Isn't 2400::/16 used in the APNIC area? Various Asian countries use networks in that area. According to whois, 2400::/20 is allocated to South Korea. KRNIC is not an ISP but a National Internet Registry similar to APNIC. [ Network Information ] IPv6 Address : 2400:0000::/20 Organization Name : Korea Telecom Service Name : KORNET Address : Gyeonggi-do Bundang-gu, Seongnam-si Buljeong-ro 90 Zip Code : 13606 Registration Date : 20050601 Name : IP Manager Phone : +82-2-500-6630 E-Mail : kornet_ip@kt.com - KISA/KRNIC WHOIS Service -
Network operators can announce whatever they want to their customers. It's not uncommon for some customers to get summarized routes. Some ISP far away from America could be telling its customers "yes, I know how to get to North America".
Summarizing routes is different to that - not all prefixes from that net are announced.
This radar tool seems to be showing what ISPs tell it, without filtering such ISP-specific routes. You can see other "invalid" routes such as /128 routes in the same tool. Such routes won't propagate across the whole internet, by convention, but there's no rule that a single ISP can't use them.
Do they use that to reduce the amount of routing table entries in routers that are far away from such networks? -- Gruß Marco Send unsolicited bulk mail to 1756572855muell@cartoonies.org
A route to 2400::/12 is effectively a route to North America - well, part of it, because ARIN has more than one prefix.
2400::/12 is APNNIC, not ARIN. https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unica... On Sat, Aug 30, 2025 at 12:54 PM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
2400::/12 is larger than any prefix allocated to a network. In fact it's a prefix allocated to ARIN, which sub-allocates prefixes to various North American networks.
A route to 2400::/12 is effectively a route to North America - well, part of it, because ARIN has more than one prefix.
Network operators can announce whatever they want to their customers. It's not uncommon for some customers to get summarized routes. Some ISP far away from America could be telling its customers "yes, I know how to get to North America".
This radar tool seems to be showing what ISPs tell it, without filtering such ISP-specific routes. You can see other "invalid" routes such as /128 routes in the same tool. Such routes won't propagate across the whole internet, by convention, but there's no rule that a single ISP can't use them.
On 30 August 2025 08:58:21 CEST, Pirawat WATANAPONGSE via NANOG < nanog@lists.nanog.org> wrote:
Dear Gurus,
Radar tool by Qrator [Reference: https://radar.qrator.net ] claims that Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’ on top of my more-specific address block. The tool classifies it as a type of hijacking. [Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the information I received] My neighboring organization also has a more-specific block that falls under The Umbrella too.
However, other tools (https://stat.ripe.net , https://irrexplorer.nlnog.net , https://bgp.he.net , etc.) seem unable to see that particular announcement.
Questions: 1. Is Qrator claim true? (because I have already tried but cannot verify) 2. If so, should I be concerned? Even though I already ROA-ed *and* IRR-ed my own block, but if “the other end” doesn’t validate, it won’t do any good, correct? (Oh, yeah, the other end also has to somehow “not see” my longer-prefix. But that can happen as well, no?) 3. In that case, what more do I must do?
I would extremely appreciate someone helping me out on this matter.
Best Regards,
Pirawat. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GT2M54NG... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/IGZBNRW3...
I suspect what is happening here is not as uncommon as some might think. At one point in time, I was working for a network that was concerned about table size growth on some of its older routers. To alleviate those concerns, large aggregate routes were installed internally sending regionalized prefix blocks towards their respective portions of the planet. IE, APNIC allocated ranges from IANA were pointed towards the APAC portion of the network, RIPE allocations were pointed towards Europe, and then more specifics were filtered out from iBGP at the cross-continental route reflectors. This worked fairly well for filtering out smaller prefixes while still more or less keeping routes flowing in the right directions. Then we started feeding routes to a routing intelligence platform; they wanted a full feed of all our routes, not just our normal export list of our customer cone. So, we gave them a full feed of everything--which included the internal traffic engineering super-aggregates that were used to steer traffic internally. The prefixes in question were never used for anything other than general steering of traffic at trans-oceanic crossings, and were never announced externally (other than to the routing intelligence platform), and thus were never in a position to 'hijack' any traffic. But they did indeed show up when people dug through prefix information on the routing intelligence platform. You might be seeing similar artifacts here; internal traffic engineering routes that aren't announced externally on any data-carrying links, but that are being exported to a RIB-monitoring service only. I wouldn't worry too much; unless there's a Pakistan/Youtube or AS7007 level leakage from the network in question, your traffic won't ever be impacted by those RIB entries. Matt On Sat, Aug 30, 2025 at 7:34 AM Ties de Kock via NANOG < nanog@lists.nanog.org> wrote:
I looked at some RIS (and routeviews) MRT data.
First I looked at BGP updates: * There were no BGP updates captured by RIPE RIS between 2025-08-12..2025-08-26 for 2400::/12. * The largest prefix in 2400::/12 for which updates/withdraws were seen in that period was 2400:2000::/20.
When I look at the combined RIS+routeviews RIBS at 08:00 UTC on 2025-08-30, these are the largest prefixes in 2400::/12 and their visibility:
┌────────────────┬────────────┐ │ prefix │ visibility │ │ │ (peers) │ ├────────────────┼────────────┤ │ 2400:2000::/20 │ 689 │ │ 2400:4000::/22 │ 690 │ │ 2400:6280::/30 │ 268 │ │ 2400:7b80::/30 │ 799 │ │ 2400:a840::/31 │ 795 │ │ 2400:a842::/31 │ 795 │ │ 2400:a844::/31 │ 795 │ │ 2400:a846::/31 │ 795 │ │ 2400:a848::/31 │ 795 │ │ 2400:a84a::/31 │ 795 │ │ 2400:a84c::/31 │ 795 │ │ 2400:a84e::/31 │ 795 │ │ 2400:a980::/29 │ 777 │ │ 2400:ca00::/28 │ 792 │ │ 2400:d800::/30 │ 780 │ │ 2400:d800::/31 │ 780 │ │ 2400:dd00::/28 │ 693 │
If 2400::/12 was widely visible, it indicates a gap in the coverage of routeviews and RIS. I can’t speak for routeviews, but as RIS project we would be very happy to add peers that cover such a blindspot.
We want to make data analysis like I just did easier. We have a prototype for a new way to search in MRT data. It started as an internal research/debugging aid, but we want to start releasing pre-processed data soon.
If things work out I will do a talk on this at the next RIPE and NANOG meetings on this way to search in BGP data - the talk is about to be submitted.
Kind regards,
Ties
On Sat, 30 Aug 2025 at 14:56, Tom Beecher via NANOG <nanog@lists.nanog.org
wrote:
According to RIPEStat, 2400::/12 hasn't been seen since Oct 2023, from AS13030 (Init7).
I also cannot seem to see any recent announcement of that anywhere in the usual sources, or my internal data. I would say this was an error on Qrator's part.
In that case, what more do I must do?
Although it didn't seem to happen here, best practice is to always announce 100% of your allocated IPs at all times. This provides protection against someone announcing an umbrella and pulling traffic for any uncovered space. It's not perfect , but protects against general stupid.
On Sat, Aug 30, 2025 at 2:59 AM Pirawat WATANAPONGSE via NANOG < nanog@lists.nanog.org> wrote:
Dear Gurus,
Radar tool by Qrator [Reference: https://radar.qrator.net ] claims that Zenlayer Inc. [AS4229] is “umbrella-ing” me by announcing ‘2400::/12’ on top of my more-specific address block. The tool classifies it as a type of hijacking. [Disclaimer: apologies to Zenlayer if you didn’t do it; but that’s the information I received] My neighboring organization also has a more-specific block that falls under The Umbrella too.
However, other tools (https://stat.ripe.net , https://irrexplorer.nlnog.net , https://bgp.he.net , etc.) seem unable to see that particular announcement.
Questions: 1. Is Qrator claim true? (because I have already tried but cannot verify) 2. If so, should I be concerned? Even though I already ROA-ed *and* IRR-ed my own block, but if “the other end” doesn’t validate, it won’t do any good, correct? (Oh, yeah, the other end also has to somehow “not see” my longer-prefix. But that can happen as well, no?) 3. In that case, what more do I must do?
I would extremely appreciate someone helping me out on this matter.
Best Regards,
Pirawat. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GT2M54NG...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/47LPGUEA... _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FCMDVDY6...
participants (7)
-
Marco Moock -
Matthew Petach -
Mel Beckman -
nanog＠immibis.com -
Pirawat WATANAPONGSE -
Ties de Kock -
Tom Beecher