# RFC7999 Published articles for RFC7999. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Analysis of Telegram IPv6 BGP announcements by Indian ISPs DevFeed: [Analysis of Telegram IPv6 BGP announcements by Indian ISPs]() Original publisher: [Read original article]() Published: 2026-06-17T23:52:47Z Content type: opinion Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [BGP](), [networking](), [DDoS]() Tags: [as135709](), [as152144](), [as45820](), [bgp](), [ddos](), [lightstorm](), [rfc7999](), [rtbh](), [telegram](), [ttsl]() ### AI overview The article examines unusual BGP announcements for Telegram IPv6 prefixes by several Indian ISPs after a reported Telegram prefix hijack. It proposes that existing BGP blackholing configurations may have been used to block Telegram traffic, while noting this is the author's interpretation. ### Source excerpt Since the Telegram's prefix hijack (4 days ago on 17-Jun-2026) by RCom, there is visible noise in the BGP routing table from multiple other Indian ISPs, including Tata Teleservices (AS45820) / Lightstorm (AS135709/AS152144), etc. mostly in IPv6. Let's look at 2a0a:f280::/48 (Live lookup here) Notice all the ASNs here largely seem to be downstreams or peers of AS45820 in India, no major large peer or upstream that would take this announcement outside of India. Similarly, take the case of aggregate - 2a0a:f280::/32. This has TTSL (AS45820) as well as Lightstrom (AS152144/135709) originating these prefixes to smaller peers. Analysis: Possible reason and impact of this behaviour Today I tested some config in lab to see why this could be happening. Here's what I strongly feel is happening (quite sure, unless someone has a better explanation): Indian Govt. has asked ISPs to block Telegram and unlike past blocks mostly at the DNS layer, ISPs have been asked to drop IPs as well. Technically in these cases ISPs could simply add a blackhole route and that would drop traffic going towards these prefixes (from their customers) and that would not be visible at BGP (control plane) but only in traceroutes (data plane). If any of these customers had a full routing feed from those respective ISPs, they would keep on learning Telegram's route with the correct/expected AS_PATH and expected origin AS. Very likely these players had blackhole config setup for the DDoS protection and ended up using the same i.e they are treating Telegram's IPv6 prefixes like they would treat their own when under attack. Also, blackholing is a common practice during DDoS attacks. Imagine a network with a 100G uplink gets hit by a 400G volumetric attack. It will take up all the link bandwidth and thus in these cases ISPs blackhole their own (or downstream) IPs (often small - single /32s or a few) and they signal this to their BGP adjacencies as well. There is a standard BGP blackhole community: 65535:666 as