Category: Internet
Published on , commented on March 10, 2023
Small Site Multihoming in IPv6: Mission Impossible?
Summary: I can’t figure out how to make small-site multihoming (without BGP or PI address space) work reliably and decently fast (failover in seconds, not hours) with IPv6. I’m probably not alone.
Problem: There are cases where a small site needs (or wants) to have Internet connectivity from two ISPs without going through the hassle of getting a BGP AS number and provider-independent address space, and running BGP with both upstream ISPs.
Internet peering disputes: follow the money
You’ve probably heard about the recent peering dispute between Level-3 and Comcast ... and might have enjoyed the frenzy with which the blogging pundits have followed the false net neutrality scent left by Level-3 spin doctors.
Facts first: Level-3 is trying to dump huge amount of data into Comcast’s network for free.
Introduction to LISP
I’ve been mentioning LISP several times during the last months. It seems to be the only viable solution to the global IP routing table explosion. All other proposals require modifying layers above IP and while that’s where the problem should have been solved, expecting those layers to change any time soon is like waiting for Godot.
If you’re interested in LISP, start with the introduction to LISP I wrote for Search Telecom, continue with the LISP tutorial from NANOG 45 and (for the grand finale) listen to three Google Talks from Dino (almost four hours).
BGP: time to grow up
If you’re in the Service Provider business, this is (hopefully) old news: on Friday, RIPE decided to experiment with the Internet causing routers running IOS-XR to hiccup. They stopped the experiment in less than half an hour and only 2% of the Internet was affected according to Renesys analysis (a nice side effect: Tassos had great fun decoding the offending BGP attribute from hex dumps).
My first gut reaction was “something’s doesn’t feel right”. A BGP bug in IOS-XR affects only 2% of the Internet? Here are some possible conclusions:
TCP/IP is like a mainframe ... you can’t change a thing
Almost 30 years ago, I was lucky enough to work on one of the best systems of those days, VAX/VMS (BTW, it was able to run 30 interactive users in 2 MB of main memory), which had everything we’d wished for – it was truly interactive with hierarchical file system and file versioning (not to mention remote file access and distributed clusters). I couldn’t possible understand the woes of IBM mainframe programmers who had to deal with virtualized 132-column printers and 80-column card readers (ironically running in virtual machines that the rest of the world got some 20 years later). When I wanted to compile my program, I started the compiler; when they wanted to do the same, they had to edit a batch job, submit the batch job (assuming the disk libraries were already created), poll the queues to see when it completed and then open the editor to view the 132-column printout of compiler errors.
After a long discussion, I started to understand the problem: the whole system was burdened with so many legacy decisions that still had to be supported that there was nothing one could do to radically change it (yeah, it’s hard to explain that to a 20-year old kid full of himself).
P2P Traffic and the Internet, Part 2
As expected, my P2P traffic is bad for the network post generated lots of comments; from earning me another wonderful title (shill for Internet monopolies) that I’ll proudly add to my previous awards to numerous technical comments and even a link to a very creative use of BitTorrent to solve software distribution problems (thanks again, @packetlife).
Most of the commentators missed the main point of my post and somehow assumed that since I don’t wholeheartedly embrace P2P traffic I want to ban it from the Internet. Far from it, what I was trying to get across was a very simple message:
P2P Traffic Is Bad for the Network
I’m positive you all know that. I also hope that you’re making sure it’s not hogging your enterprise network. Service Providers are not so fortunate – some Internet users claim using unlimited amounts of P2P traffic is their birthright. I don’t really care what kind of content these users transfer, they are consuming enormous amounts of network resources due to a combination of P2P client behavior (which is clearly “optimized” to grab as much as possible) and the default TCP/QoS interaction.
The need for Internet data caps
A few days ago my friend Greg (also known as @etherealmind) wrote an interesting tweet (probably prompted by the change in AT&T data plans):
If a data cap doesn't affect 97% of users, why bother implementing it at all? Surely the 3% can be that significant?
A few of us immediately responded that the 3% could represent 80 (my guess) to 97% (@icemarkom) of the traffic. As I’m tracking my home Internet connection with MRTG for over a year, I was also able to get some hard facts (although the sample size is admittedly very small). We’re pretty heavy internet users (no limits on what my teenage kids are doing and I’m mostly working from home), but the average yearly utilization of my 20 Mbps pipe is only 180 Kbps or less than 1% of its capacity (still, over a year, that’s almost 700 GB of data or 350 months of AT&T’s DataPro plan).
The FTP Butterfly Effect
Anyone dealing with FTP and firewalls has to ask himself “what were those guys smokingthinking?” As we all know, FTP is seriously broken interestingly-designed:
- Command and data streams use separate sessions.
- Layer-3 addresses and layer-4 port numbers are carried in layer-7 messages.
- FTP server opens a reverse session to a dynamic port assigned by the FTP client.
Once upon a time, there was a very good reason for this weird behavior. As Marcus Ranum explained in his Internet nails talk @ TEDx (the title is based on the For Want of a Nail rhyme), the original FTP program had to use two sessions because the sessions in the original (pre-TCP) Arpanet network were unidirectional. When TCP was introduced and two sessions were no longer needed (or, at least, they could be opened in the same direction), the programmer responsible for the FTP code was simply too lazy to fix it.
Cloud computing and public transport
Greg Ferro has republished an older post in which he compares Cloud Computing with public transport (and notes that nothing has changed in more than a year since he wrote the original article). His analogy is more than fitting; a perfect example is Google’s new Google Docs offering, where Stephen Foskett did a nice cost analysis of the unsupported service as compared to supported one.
I’m describing aspects of cloud computing in its various incarnations in my Next-generation IP Services workshop. You can attend an online version of the workshop or we can organize a dedicated event for your team.