Based in ITALY
Articles
Likes on articles
Antonio Prado holds a Ph.D. in Computer Science, with a research focus on Internet Routing Security. His doctoral work focused on tools and methodologies for the automated verification of BGP configurations. He is co-author of BGP from Theory to Practice, a book aimed at both technical and academic audiences, and of the outreach volume Parlami di TEch, designed to make technology accessible to a broader readership. His latest book, Crescere con l’intelligenza artificiale (2026), helps adults understand how AI is reshaping children’s everyday lives. He also holds a second-level Master’s degree in Innovation and Digital Transformation in Public Administration, with a specialization in the use of Artificial Intelligence in public-sector processes and services, addressing both opportunities and ethical-organizational implications. Since 2022, he has been a member of the RIPE Programme Committee, contributing to the review and selection of scientific presentations for European community conferences. He has delivered seminars and lectures on Internet and Network Architectures for the Academia, and has taught DNS, Internet Governance, and BGP at the Namex School of Advanced Networking, helping to train the next generation of network professionals. At the time of writing, he is also an External Researcher at the University of Padova, Italy.
• 8 min read
RPKI has made real progress against prefix hijacking. But when you map every known class of BGP attack against the defences that exist, four of them turn out to sit entirely outside cryptographic validation: handled with local filters, static thresholds and reactive response.
• 9 min read
Italy’s Piracy Shield blocks IPs and domains within minutes, but measurements performed by researchers at the University of Twente and colleagues show broad collateral damage to legitimate services. We share the results of those measurements in the hopes of sparking a community discussion around th…
• 9 min read
Internet Exchange Points (IXPs) are often overlooked in discussions about critical infrastructure. Yet their role in routing stability, local resilience, and digital sovereignty is undeniable. In this article, we explore what happens when IXPs fail, and why classifying them as critical infrastructu…
Showing 3 article(s)
“Antonio, Thanks for this. One of the three I can close now, one I can only half close, and one you have given me a way to test. On BDIX, the part I can settle is the alternative you raise. For AS63526 the loss of international routing originated at the AS itself — my own account as the operator, not something the collector view can show — not at an IIG or transit edge failing underneath while domestic peering stayed up. So for at least one network the selective reading holds, on operational grounds rather than on the traffic graph. What I cannot settle is which of those prefixes stayed reachable domestically at the same moment, and the section should not have rested that on the graph. Your caveat about bilateral sessions is the binding constraint here rather than a footnote. Because a share of the peering at this exchange never touches the route servers, a prefix-by-prefix comparison would establish a lower bound on domestic visibility rather than measure it: presence in the logs is evidence, absence is not. That still helps, but it bounds how much the comparison can carry. I am asking what survives from that week, and will run the comparison if anything does. On ROV, the distinction you draw is the one the section missed. A route server can log that a prefix disappeared, but nothing in the deployed stack attests to the disappearance. The nearest thing in progress is the Signed Prefix List work, which makes absence checkable against a declared complete set, but that is a statement about what an AS may originate rather than an authenticated record that a route was removed at a given time. RFC 8205 is explicit about this at the edge of its own threat model: withdrawal suppression is left outside the protocol and deferred to certificate rollover. So the gap is architectural rather than a matter of deployment. Agreed that the recommendation should stand apart from 18 July. On the eight hours, one refinement: the interval is RIS's own per-collector RIB dump cadence surfaced through RIPEstat, rather than something RIPEstat introduces. Your point is unaffected, since the update files are the finer source either way, and I queried the wrong one. Your caveat about MRT timestamps is the real limit on what the timing analysis can claim, and I would rather be explicit about it than work around it. For AS63526 I can say which withdrawals were initiated at the AS rather than inferred from the collector view, which narrows the ambiguity for one network, but that is operator testimony and not a measured offset, and I will label it as such. Where the write-up gives times, they will be collector observations, and I will say so each time rather than let the two blur. You singled out the straggler prefixes, and that is where I will start, since it is the part I would most like to put on firmer footing. I would value your eye on it when it is ready. Kamruzzaman 1 Aug,2026”
Kamruzzaman, there’s nothing I’d push back on here. You’re right about the dump cadence, and I stand corrected: the eight-hour interval comes from the collectors’ bview schedule, while RIPEstat simply exposes it. I also agree that treating the BDIX logs as a lower bound is the most accurate approach. Even an incomplete lower bound would help move the selective-reading argument from testimony to measurement, at least for the subset of routes that appears in the logs. One thought on the straggler analysis: the update files should allow you to distinguish directly between the two possible readings of Signal 2. If the eight /44s were withdrawn within a few seconds of one another, and the pattern is consistent across peers, that would suggest a single cleanup action. If they disappear gradually, or coincide with a session-level event, the explanation is likely different. That inter-arrival pattern is exactly the kind of detail that gets flattened in a RIB snapshot, so it would fit well with the timestamp labelling you already plan to add. Send the draft over when it’s ready. I’d be very happy to read it. -- antonio
Thanks for writing this up. Signal 2, especially the evidence around the straggler prefixes, is a rare operational detail and one of the most valuable parts of the article. A few thoughts came to mind while reading. First, the resilience section may contain another useful signal. If the prefixes that disappeared from RIS were still being advertised or remained reachable through BDIX, that would point to a selective loss of international routing rather than a general network failure. The BDIX traffic graph alone cannot prove this, since a failure or shutdown at the IIG or transit edge could leave domestic peering untouched. Still, the idea may be testable. If BDIX retains route-server logs or snapshots, a prefix-by-prefix comparison could show whether routes remained visible domestically while disappearing from international collectors. Bilateral sessions would not necessarily appear there, but even partial evidence would strengthen the analysis. Second, I think the routing-security section needs a small correction. ROV enforcement at the IXP would not have made these withdrawals cryptographically auditable. RPKI validates the origin of route announcements; it does not sign or authenticate withdrawals. Even BGPsec protects the announcement path, not the later removal of a route. A route server may of course log that a prefix disappeared, but ROV adds no cryptographic attribution to that event. The recommendation that IXPs and transit providers should state whether they enforce ROV is still a good one, but I would keep it separate from the events of 18 July. Third, the eight-hour limitation belongs to the RIPEstat view or endpoint used in the analysis, not to RIS itself. RIS also archives the updates received by its collectors in five-minute MRT files. The July 2024 events can therefore be reconstructed retrospectively without RIS Live and with much finer timing. This could show whether operators placed in the same eight-hour bucket actually withdrew minutes or several hours apart, and clarify how long the IPv6 stragglers remained visible. The MRT timestamp still records when an update was observed by a collector peer, not the exact moment a command was entered, but it would remove much of the ambiguity. I would be very interested to see a follow-up based on the raw MRT data. The combination of public collector data and direct operational experience is what makes this analysis particularly valuable. Thanks -- antonio
Thanks for this follow-up. I asked under the previous article which MAC answers for the sentinel across a failover, and this article answers it: none, because nothing is ever elected. Fair enough, the question simply goes away. The two-IPv4s framing also works much better than the fe80 analogy did, and the VPN /32 example is the right one, every OS already does subnet-less IPv4 on tunnel interfaces every day. Two things I would still want to see addressed before this goes much further. First, the failover story is only complete for the planned case. The RA with lifetime zero works when you decommission a router on purpose. When the first hop dies silently (PSU, linecard, kernel panic) nobody says goodbye. RFC 4861 has NUD for exactly this: unreachability of the next-hop in use should trigger selection of another router, well before the lifetime expires. So the Windows 11 observation is actually the interesting part. If the dead router stayed in the list until lifetime expiry, either NUD did not kick in on that stack, or the test had no active flows through it at that moment. I'd really like to know which, and more generally to see measured reconvergence times for silent failure next to VRRP with aggressive timers. "FHRP vanishes" is a strong claim and that number is what backs it or not. Second, migration on policed segments. The end state (only the router ever answers ARP) is clean, agreed. But during coexistence, on access networks running DHCP snooping, DAI and IP source guard, you have a router answering ARP for an address that appears in no binding table. That is precisely the pattern those features were built to catch. Anyone running them will have to touch switch config to let the fallback path work, which slightly undercuts "no changes needed" for the transition period. Not a blocker at all, but worth a paragraph in deployment considerations before someone finds out in production. Neither of these makes me less interested in the mechanism. Good luck with the adoption discussion.
Excellent thread: the fe80 and DHCPv6-PD exchanges cover the control-plane side thoroughly. Two operational points from the access/data-centre side that haven't come up yet. Both are about the shared-L2 segment the article leads with (Hetzner/OVH-style VLANs, enterprise access), not the routed-to-the-host fabric, where they don't apply because there is no east-west on the wire to begin with. East-west hairpinning. Once every host is a /32 with no on-link IPv4 subnet, two hosts on the same segment no longer have an on-link path to each other. A→B IPv4 now goes host → 192.0.0.11 → router → back out the same interface → B. On a shared broadcast domain that turns a one-L2-hop intra-segment flow into a router hairpin: roughly double the segment traffic for east-west IPv4, plus load on the first-hop router. For the IPv4-heavy east-west workloads that still live on legacy segments (clustering, storage, backup), that is a real cost the /32 model introduces quietly. Worth a line in deployment considerations, even if only to say "keep east-west-heavy IPv4 segments dual-stack for now." L2 integrity and first-hop redundancy. DHCP snooping, Dynamic ARP Inspection and IP Source Guard build bindings from DHCP state and validate against subnet-and-binding assumptions. A gateway deliberately off-subnet plus /32 leases sits outside the envelope these features were written for, so operators running them will need to validate behaviour and likely add explicit permits for the sentinel, mildly ironic for a mechanism whose headline is "no host changes," since on a DAI-enabled access network the no-change fallback path may need a switch-side change. Related: with redundant first-hops, the draft should say which MAC answers for 192.0.0.11 across a failover: a shared/virtual MAC, or you trade ARP churn for neighbour-cache churn. thanks
Good and much-needed analysis. At last, it moves the discussion from “nice, more bits” to the more practical question: who is supposed to run this in real networks? We all know the Internet is messy: routing policy, traffic engineering, anycast, DDoS workarounds, filters, CPEs, logs, tools, outages, people, and all the odd ways things fail in production. Drawing a bigger address space is easy, but making it useful and operable is the hard part. I also liked the point about routing security: there are concrete mechanisms for concrete problems. The buzzword “cybersecurity” does not really help here, IMHO. All in all, maybe an interesting idea, but still a long way from something operators could actually deploy.
Thanks for this article: the historical walk through the RFC wording is really interesting and I enjoyed reading it. I'd like to share a slightly different perspective on some of the points raised. On the risk of accidental transit: in my experience, this is something you solve with route-maps and filters on eBGP, not by removing iBGP sessions. Removing sessions to prevent misconfigurations feels a bit like removing roads to prevent accidents. On failure scenarios: I keep thinking about what happens during convergence. If BR1 loses its upstream and has no iBGP session with BR2, it just has to sit there and wait for the IRs to converge. With that session in place, BR1 would immediately know that BR2 has an alternative path. That seems worth having. On KISS: I'd actually argue it the other way around. A full mesh of 5 or 6 routers is uniform and predictable. A partial mesh means you need to keep track of who sees what, which in my experience makes troubleshooting harder, not easier. "Everyone talks to everyone" is a pretty simple rule to follow. I also think that tools like next-hop-self, BGP communities, and well-designed route policies are what make full mesh safe and manageable in practice, even where it's not strictly necessary. And in the real world, the boundaries between upstream, peering, and customer roles can be less clear-cut than the model assumes, so having full route visibility across all routers can really help with traffic engineering. Anyway, just my two cents; thanks again for putting this out there, it's a topic that doesn't get discussed enough.
“I want to thank you for your article and for the mention of IX.br, and confirm that the article’s description about its wide geographical coverage helping to absorb massive traffic increases is accurate. I would also like to emphasize that the adequate scaling and dimensioning of the largest IXPs: São Paulo, the largest in the world, Fortaleza, and Rio de Janeiro, has been fundamental in supporting the growing traffic demand. However, I want to clarify that stating the coordination is public or state-led is not correct. CGI.br works in the public interest, as does NIC.br, but the coordination of IX.br is multistakeholder through CGI.br, with balanced participation from the public sector, private sector, civil society, and academia. I also want to clarify that no government funds are involved in IX.br. NIC.br is a private non-profit entity that manages IX.br and other initiatives, funded with private resources mainly from the registration of .br domains, while following the guidelines established by the multistakeholder council CGI.br, which guides public policies for the Internet in Brazil. I remain available for any further clarifications.”
Muito obrigado, Antonio, tanto pela leitura quanto pela importante correção. I’ve now updated my internal notes to reflect this. I’m grateful for your detailed comment, and I will make sure any future references distinguish clearly between multistakeholder coordination and state operation.
“Antonio, I together with Keith Mitchell created LINX in the very early days of the Internet. A key factor you miss is actually the reason we created the LINX. It stops large ISPs from extorting "Taxes" from smaller ISPs. The key here is if a large ISP seeks to restrict traffic, the IXPs provide a route around the blockage. We can see how Deutsche Telecom have tried repeatedly to muscle traffic to their advantage and have been repeatedly thwarted. might form a cartel to maximise their profits. The agreements that are the basis of the whole commercial Internet are underwritten by the IXPs. I have an incomplete paper on IXPs available which explain much that may have been forgotten”
Thank you, Peter, for your comment and for reminding us of the foundational motivations behind the creation of LINX. Your point is absolutely crucial: IXPs are not only about performance and resilience, but also about market fairness and interconnection freedom. It would be very valuable to include historical reflections like yours: if you’re open to sharing the incomplete paper you mentioned, I’d be keen to read it and possibly reference it in future revisions or spin-offs of the article. Thank you again for your contribution and for helping make the Internet what it is today.
It would be interesting to have an addition to this fine article on the position of the Internet within cyberspace.
Showing 9 comment(s)