For
]]>For network operators and policymakers, the takeaway is simple: sometimes the best way to stimulate growth is to just get out of the way.
The data tells a clear story. When networks are allowed to interconnect freely, the internet ecosystem thrives. Here’s why:
For incumbent telcos, there’s a huge opportunity to grow revenues in an expanding market—but only if they embrace interconnection.
At the moment, the Middle East lacks a dominant IXP. Many networks still haul traffic to London, Amsterdam, or Frankfurt for peering. But that will change as regional provider density increases and local IXPs reach a critical mass. The key question is: which providers will adapt and grow, and which will cling to outdated models until it’s too late?
The lesson from deregulated markets worldwide is clear—embracing competition and interconnection doesn’t weaken the market, it supercharges it. The Middle East is at a turning point, and those who seize the opportunity now will define the region’s digital future.
]]>Fast forward to today, and we have a modern equivalent: a tax on glass fibre. The UK government levies a charge on firms based on the length of fibre optic cable they deploy. Like its 17th-century counterpart, this tax is both unfair and avoidable. But instead of bricking up windows, companies are simply choosing not to roll out fibre at all. And that hurts everyone.
When fibre is cheap and accessible, it powers a compelling vision for the future. Faster broadband, better infrastructure, and more resilient networks become possible. Firms can invest in ultra-fast connectivity—tens or even hundreds of times faster than what most UK households currently have. Network providers can build better redundancy, meaning fewer outages, more business continuity options, and stronger digital infrastructure across the country.
The fibre tax puts all of this at risk. By making fibre unnecessarily expensive, the government is discouraging the rollout of next-generation broadband. That doesn’t just mean slower internet—it means a weaker, less competitive digital economy.
This tax also sends the wrong message to international firms looking to bring content and services to the UK. Global tech companies and network providers weigh up the costs of expansion carefully. If deploying fibre in the UK is disproportionately expensive, they will go elsewhere. This isn’t a hypothetical problem—it’s already happened. Over the past year, multiple projects that could have improved the UK's connectivity have been abandoned because the numbers simply didn’t stack up.
This morning, George Osborne appeared on BBC TV, declaring that advancing next-generation broadband was a government priority. If that’s true, then the first step must be repealing the fibre tax—our 21st-century window tax.
So far, the government’s focus has been on scrapping the much-criticised 50p per month broadband levy proposed in the flawed Digital Britain report. But repealing one tax while keeping another that’s just as damaging is hardly a victory.
With this tax in place, the UK is making itself uncompetitive in the global digital economy. Faster broadband isn’t a luxury—it’s a necessity for businesses, innovation, and growth. If the government is serious about next-gen broadband, the fibre tax must go.
Because if we’ve learned anything from history, it’s that taxes designed to stifle progress never end well. Just ask the homeowners still living behind bricked-up windows.
]]>Let's do some maths! First, a
]]>Let's do some maths! First, a comparison with the previous addressing scheme: Class C IPv4 networks topped out at a mere 2,097,152 networks. Quaint and probably wont even fill a quarter of Lake Ontario.
Now, for our base M&M dimensions: Each M&M, we'll assume, is a perfectly oblate spheroid:
Our canvas: Lake Erie, a hefty 484 cubic kilometres of freshwater real estate.
Crunching the numbers reveals a delightful absurdity:
But here's where IPv6 gets truly mind-bending. From just the 2000::/3 address range:
And this? This is just a fraction of the total IPv6 address space. To put it mildly: THE IPV6 ADDRESS SPACE IS VERY, VERY, VERY BIG.
Can we please, finally, just roll out some IPv6 services?
]]>Some brutally technical context: Every network on the internet needs a unique
]]>Some brutally technical context: Every network on the internet needs a unique identifier. Currently, these Autonomous System Numbers (ASNs) range from 1 to 65,535—we're approaching 50,000 in use. RFC4893 was the community's elegant solution to expand this numbering system.
BGP (Border Gateway Protocol) allows large networks to configure internal 'confederations'—essentially virtual divisions within their network. The standard explicitly forbids these internal confederation IDs from being passed between networks in BGP messages.
But what happens when that rule is accidentally broken?
AS196629 is announcing routes to AS35320, who are not stripping confederation information from their large-ASN BGP messages. Learn this prefix via AS6886, and you're fine. Learn it via AS35320, and you're receiving a network-destroying message.
We tested this on a Cisco 7200 router with first-generation ASN4 support, peering with NetSumo's research network (AS15653). The results were surgical in their destruction:
*Jan 16 11:29:58.531: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Up
*Jan 16 11:30:02.595: %BGP-6-ASPATH: Invalid AS path (65044 65048 65062) 3.21 23456 received from 193.239.32.2: Confederation found in AS4_PATH
*Jan 16 11:30:02.595: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Down BGP Notification sent
The standard currently mandates that if confederation ASNs appear in the ASN4 part of a BGP message, the connection between networks should be severed. This means a network that doesn't understand large ASNs can forward a broken message to a network that does—resulting in the receiving network tearing down its session.
The consequence? If this happens across all transit sessions, a network will lose its entire internet connectivity.
The message I reported in December is still leaking. Cisco honours the RFC precisely, which means a misconfigured message can disconnect an entire network from the internet.
We need to change BGP error handling behaviour. The current standard provides a simple mechanism to potentially "break the internet"—just waiting for unsuspecting network upgrades.
The internet is held together by protocols, trust, and an extraordinary amount of duct tape. Stay vigilant, network warriors!
[Edit: We presented on this flaw and way forward at NANOG45]
]]>The technical challenges felt impossible to overcome. TCP's delivery guarantees, the bandwidth requirements for high-definition content, and the huge infrastructure needed
]]>The technical challenges felt impossible to overcome. TCP's delivery guarantees, the bandwidth requirements for high-definition content, and the huge infrastructure needed to handle mass viewership of live events seemed insurmountable.
But I had failed to grasp how the internet would reinvent TV: the internet isn't solving broadcast, it is reinventing content distribution.
Indeed, traditional broadcast requires a monolithic and centralised infrastructure, massive transmitters, mass programming and such. My recent personal viewing habits tell a different story. I've been syndicating shows from platforms like Revision3, downloading content that seamlessly migrates from laptop to iPhone to hotel room television. One moment, I'm watching Diggnation on a train; the next, I'm plugging my phone into a hotel TV, transforming a generic screen into a personal content hub.
The technical magic lies not in perfect replication of broadcast, but in radical flexibility. Where traditional TV saw constraints, internet video has possibilities.
Take bandwidth—the perennial bugbear of IP video. A high-definition stream requires approximately 5-7 Mbps for consistent quality. Traditional broadcast laughs at such limitations, but internet infrastructure is learning, adapting. Content delivery networks (CDNs) now use sophisticated caching, edge computing, and adaptive bitrate streaming to transform what was once a technical impossibility into a seamless experience.
The real innovation? Protocols like HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH) that can dynamically adjust video quality based on available bandwidth. Your connection drops from fibre to 4G? The stream adjusts without interruption, a technological trick that was like witchcraft a decade ago.
Bandwidth is just one piece of the puzzle, the true disruption is in distribution economics. Previously, global content distribution required negotiating with dozens of regional broadcasters, navigating a labyrinth of licensing agreements. Now? A creator with a camera and an internet connection can reach a worldwide audience.
My prediction for the near future is a hybrid model. Niche content will be downloaded on-demand, while mainstream programming will be cached via more traditional broadcast mechanisms. We're already seeing devices that blur these lines. Smart TVs that can switch between broadcast and internet streams as effortlessly as changing channels.
I was wrong, I am happy to have been wrong. Bring on choice, and bring on the bandwidth.
]]>When routers receive network updates, they rely on defined
]]>When routers receive network updates, they rely on defined protocols to ensure coherent global routing. In this case, BGP updates contained CONFED_SET (confederation) autonomous system paths within the AS4_PATH attribute—a configuration explicitly forbidden by RFC4893. The result was disruptive: routing sessions summarily terminated, interrupting network connectivity.
The technical minutiae reveals a broader systemic risk. While the current impact remains limited, the incident portends more significant disruptions as network implementations become increasingly sophisticated. The potential for widespread network isolation looms should similar protocol breaches become more frequent.
Instead of terminating the session when such errors are encountered, network engineers require configurable options to handle such violations: e.g. rejecting problematic routes while maintaining network session integrity, logging infractions, or implementing graduated response mechanisms.
The incident underscores a fundamental truth of networked systems: complexity is the enemy of reliability. Each layer of technical specification represents both a solution and a potential point of failure.
Investigations are ongoing, with the network's technical team working to isolate the specific implementation that originated the non-compliant routing update. Their findings will be crucial in preventing similar incidents and refining the robustness of global internet routing infrastructure.
]]>In a wild two-and-a-half-hour BGP routing misadventure, Pakistan Telecom managed to hide YouTube from most of the world. What happened? Let’s dive in.
Earlier today, the Pakistan government reportedly instructed ISPs to block YouTube in the country due to controversial content. Pakistan Telecom, however, took things a step further. They didn’t just block YouTube locally—they accidentally broadcast a route claiming YouTube’s IP range as their own. This announcement spread far and wide, redirecting YouTube-bound traffic to Pakistan instead.
Here’s how it works: the Border Gateway Protocol (BGP), which underpins global internet routing, loves specificity. If a network announces a more "specific" group of IP addresses, BGP prioritises it. For example, if I announce a network with 1,024 addresses, but someone else announces a subset of 256 from that range, their announcement takes precedence. It’s a feature, not a bug—designed to optimise routing. But when someone injects fake routes (whether intentionally or not), the consequences can range from mildly inconvenient to catastrophic.
Pakistan Telecom tried to use this feature to block YouTube domestically. They inserted a route into their own network for a subset of YouTube's addresses. It was intended to block YouTube within the administrative domain of the Pakistan Telecom network only. This route accidentally "leaked" beyond Pakistan, via a insecure filters at their upstream ISP, PCCW Global, spreading to ISPs worldwide. And just like that, YouTube was off the air.
Small networks and end sites can reduce the risk of leaking bad routes by explicitly defining the network prefixes they plan to announce to their peers and upstream providers. But for larger networks, the picture is more complex. Many have contractual obligations to propagate their customers’ announcements. Add political pressure, human error, or both, and mistakes become more likely—especially when engineers are scrambling to implement rushed decisions from government ministers.
What happened today was loud and obvious. YouTube would have noticed something was wrong almost immediately, as their traffic disappeared into nothingness in Pakistan. But what if the hijack wasn’t so blatant?
Imagine this: a malicious actor hijacks your IP range, proxies your traffic, and sends it back to you after tampering with it. Your website or network will probably still function, but sensitive data—like customer behaviour or checkout information—could be quietly siphoned away. The impact on e-commerce could be devastating, especially if you’re unaware it’s happening.
The root of the problem lies in the routing protocol itself. BGP wasn’t designed with security in mind, and that’s where efforts like S/BGP (Secure BGP) come in. S/BGP integrates public key infrastructure (PKI) into routing announcements. Essentially, you’d sign your announcements, and your peers could verify them against an impartial internet registry.
If S/BGP were widely adopted, ISPs would’ve been able to spot Pakistan Telecom’s rogue announcement and reject it, saving YouTube from its unintended vacation. While adoption of these technologies remains slow, they represent a vital step forward in protecting the global routing infrastructure from accidents—and more sinister threats.
Today’s YouTube incident serves as a reminder that the internet, while miraculous, is far from bulletproof. Routing errors like this one highlight the importance of robust security measures, transparency, and collaboration across the network. Let’s hope the future brings more secure systems—and fewer moments where we collectively wonder why YouTube has disappeared.
]]>I recently attended a PulverMedia conference on voice peering. I went in with some strong assumptions about what voice peering would involve—and promptly had them dismantled. One of the most enlightening moments came from Gary Kim, who said, “I’m more confused about where peering is going today than I was two years ago.” After a few days of presentations and good conversations, I relate.
My frustration: “Why can’t I configure a voice peer the way I configure a BGP peer?”
In IP peering, everything is gloriously standardised. Protocols are well-known, prefixes adhere to global norms, peering is usually settlement-free, and billing is straightforward because traffic is treated equally. In the voice world, it’s like stepping into a labyrinth where every turn introduces new quirks:
This complexity has given rise to a familiar telecoms creature: the clearing house. These organisations act as intermediaries, translating codecs, signalling, and call detail records (CDRs) between peers. They provide a useful service, but it comes at a cost—literally and metaphorically. Clearing houses create barriers to entry, as they rarely offer their services for free. And for telcos that like to retain control of their networks, the model can feel intrusive.
Clearing houses abstract vital aspects of the call:
There’s also the monopoly problem. If you belong to one clearing house and your potential peer belongs to another, you’re stuck. Some clearing houses have suggested protocols to allow them to peer with each other, but that only adds another layer of abstraction. For many service providers, this is a step too far.
So, if voice peering is this complicated, why bother? Simple: it benefits everyone—telcos and customers alike.
In short, peering is a key strategy for next-gen telcos looking to deliver cheaper, higher-quality calls. The challenge lies in making it work without unnecessary intermediaries.
The solution, I believe, is bilateral communication between telcos. Prefixes (phone numbers) and standards should be exchanged directly, without a clearing house acting as referee. To this end, I’m collaborating with some of the people I met at the conference to develop a new protocol. Think of it as TRIP 2.0, but with enough commercial logic baked in to make it genuinely useful.
I hope we publish an Internet-Draft this year. It’s an ambitious project, but one that could simplify voice peering and bring the world of telecoms a little closer to the elegance of BGP. Stay tuned—this is a work in progress, but it’s one I’m excited to share.
We never got there and nothing in this field has changed (for the better).
]]>“Ma Bell is a system I want to explore. It’s a beautiful system, you know, but Ma Bell screwed up.” Those words, plucked from an article Steve Wozniak describes as “the one that changed history,
]]>“Ma Bell is a system I want to explore. It’s a beautiful system, you know, but Ma Bell screwed up.” Those words, plucked from an article Steve Wozniak describes as “the one that changed history,” capture the curiosity and ingenuity of one of the world’s greatest engineers. Like countless others, Wozniak’s fascination with computer systems grew out of a teenage obsession: exploring the vulnerabilities of the telephone network.
The telephone system, for decades, was a treasure trove for budding tinkerers for two simple reasons. First, its vulnerabilities were relatively well-documented (though hardly advertised). Second, telephony was painfully expensive, so figuring out how to game the system wasn’t just a learning experience—it saved money. But here’s the question: now that global communication is so cheap, does anyone still care enough to poke around?
Take a look at the numbers. BT users still pay 18.5p per minute to call France, or a staggering 31p to chat with friends in New Zealand. But what if those calls cost a penny per minute to France, or 1.4p to New Zealand? For users of services like Localphone, that’s already a reality. With prices this low, where’s the incentive to hack the system? Does this mean the end of the curious young Wozniaks of the world—those who might otherwise channel their rebellious curiosity into groundbreaking innovation?
The first "phreaks"—those who explored and exploited the telephone system—often stumbled upon their skills by accident. Josef Carl Engressia, a blind eight-year-old, discovered he could stop a phone from billing a call simply by whistling a 2600Hz tone. That frequency, unbeknownst to him, signalled the phone system that the call had ended. Engressia’s discovery became the foundation of phone "phreaking" and inspired a generation of hackers and engineers.
Later phreaks, like Steve Wozniak, approached the challenge with methodical precision. Phreaking became an engineering exercise, a way to master systems and understand their inner workings. As Wozniak himself said, “The blue box year was 1972. Apple started in 1975. The biggest connection was some design tricks and techniques that I honed on the blue box.” His experiments with the telephone system laid the groundwork for Apple’s early innovations. The curiosity that drove him to tinker with Ma Bell ultimately helped him build something far greater.
The telephone system served as a proving ground for countless engineers, providing both the challenge and the motivation to push boundaries. Even today, its legacy lives on: the frequency 2600Hz may no longer fool a modern exchange, but it remains an icon, lending its name to the influential 2600: The Hacker Quarterly. The journal is a bible for security enthusiasts, publishing vulnerabilities to promote stronger systems and greater transparency. Without phreaking, would we have such openness in the field of information security?
But what about today? When calling halfway across the world is cheaper than your morning coffee, does the telephone system still hold the same allure? Services like Localphone make international calls so affordable that there’s little point in “borrowing” them. Yet, the fascination with these sprawling networks hasn’t entirely vanished—it’s just changed form.
Thankfully, modern engineers can explore telecom systems without resorting to piracy. Tools like Asterisk—a free, open-source PBX—make it possible to experiment with telephone networks legally and safely. And while VoIP networks have long operated as isolated silos, the landscape is shifting. Early pioneers like the FWD system allowed free calls within their network but couldn’t bridge into traditional telephone systems. Today, services like Localphone have made that connection seamless and cheap, offering the best of both worlds.
In a way, the same forces that drove early phreaks to tinker with the system—curiosity, creativity, and the desire to make something better—are still at play. Cheaper telecoms remain a powerful motivator, and with today’s tools, aspiring engineers can dive into these systems without breaking the law.
So here’s to the next generation of tinkerers and dreamers. They may not be chasing free calls, but they’ll find new ways to explore, innovate, and build something extraordinary.
Disclaimer: the author worked as an engineer at Localphone when this article was written in October 2007.
]]>For the past ten years, I’ve been confidently peddling a lie. Not maliciously, of course—but I’ve been telling anyone who’d listen that Round Robin DNS (RRDNS) is useless for high availability. Turns out, I was
]]>For the past ten years, I’ve been confidently peddling a lie. Not maliciously, of course—but I’ve been telling anyone who’d listen that Round Robin DNS (RRDNS) is useless for high availability. Turns out, I was wrong. Two clever solutions crossed my path last week and made me rethink everything. So, consider this my public mea culpa.
First, let’s cover the basics: Round Robin DNS is a method where a single DNS record rotates among multiple IP addresses in response to queries. Think of it as a bouncer at a club, directing guests to one door, then the next, and so on. When combined with resilient protocols (like DNS itself), RRDNS actually works quite well. If you need proof, run dig . @a.root-servers.net, and you’ll see it in action at the root DNS level.
But here’s the rub: when you use RRDNS to distribute traffic to less forgiving protocols (like HTTP), it often goes pear-shaped. Imagine you’ve got two nodes serving your website:www IN A 10.1.1.2
www IN A 10.1.1.3
If one of those nodes keels over, half your users are still going to be sent to the dead IP. This is decidedly not high availability. True high availability means a system only fails when all nodes are down—not when just one has popped its clogs.
Here’s the game-changer: you don’t point your RRDNS records to the actual IPs of your nodes. Instead, you use virtual IPs that can float between servers. Imagine the setup looks like this:www1 IN A 10.1.1.2
www2 IN A 10.1.1.3
www IN A 10.1.1.201
www IN A 10.1.1.202
Each server keeps its own IP (so you can still SSH in and fiddle with it), but the user-facing IPs (10.1.1.201 and 10.1.1.202) can roam around like nomads. If one server dies, the other scoops up its floating IPs, keeping everything running smoothly.
Now, I didn’t come up with these solutions—I just watched two very smart people demonstrate them. But they’re clever, they work, and they deserve a shoutout:
RRDNS with floating IPs is not magic. It’s a bit like nudging traffic with a polite "over there, please," rather than directing it with military precision. This is load sharing, not load balancing. Plus, if one node in a two-server setup fails, the other has to handle double the traffic. That might be fine—or it might bring your remaining server to its knees. Planning is key.
Still, this approach has its charms. It’s inexpensive, relatively simple, and with a bit of elbow grease, it works. Sometimes, the best solutions don’t involve fancy load balancers or expensive software. Sometimes, it’s just about using the tools you have in unexpected ways. And if it means I’ve got to admit I was wrong about RRDNS, well… so be it.
]]>