Bruce Davie collected numerous articles describing various aspects of early Internet history and pre-Internet days, including A Brief History of the Internet and The Design Philosophy of the DARPA Internet Protocols.
Have fun ;)
Brandon Hitzel published a detailed document describing various Internet WAN edge designs. Definitely worth reading and bookmarking.
I’m always in a bit of a bind when I get an invitation to speak at a security conference (after all, I know just enough about security to make a fool of myself), but when the organizers of the DEEP Conference invited me to talk about Internet routing security I simply couldn’t resist – the topic is dear and near to my heart, and I planned to do a related webinar for a very long time.
Even better, that conference would have been my first on-site presentation since the COVID-19 craze started, and I love going to Dalmatia (where the conference is taking place). Alas, it was not meant to be – I came down with high fever just days before the conference and had to cancel the talk.
Another interesting column by Geoff Huston: performance of TCP congestion control protocols when using Low-Earth Orbit or Geosynchronous Orbit satellites for Internet access.
Straight from the “Bad Ideas Never Die” (see also RFC 1925 Rule 11) department: Geoff Huston described a proposal to use hop-by-hop IPv6 extension headers to implement Path MTU Discovery. In his words:
It is a rare situation when you can create an outcome from two somewhat broken technologies where the outcome is not also broken.
IETF should put rules in place similar to the ones used by the patent office (Thou Shalt Not Patent Perpetual Motion Machine), but unfortunately we’re way past that point. Back to Geoff:
It appears that the IETF has decided that volume is far easier to achieve than quality. These days, what the IETF is generating as RFCs is pretty much what the IETF accused the OSI folk of producing back then: Nothing more than voluminous paperware about vapourware!
Networking engineers proposing strict hierarchical addressing scheme as a solution to global BGP table explosion often cite the international telephone system numbering plan (E.164) as a perfect example of an addressing plan that uses hierarchy to minimize routing table sizes. Even more, widespread mobile roaming and local number portability indicate that we could solve IP mobility and multihoming if only insert-your-favorite-opinion-here.
Every now and then someone tells me how much better the global Internet would be if only we were using recursive layers (RINA) and hierarchical addresses. I always answer “that’s a business problem, not a technical one, and you cannot solve business problems by throwing technology at them”, but of course that has never persuaded anyone who hasn’t been running a large-enough business for long enough.
We also touched on VAX/VMS history, how early CCIE lab exams worked, how BGP started, why there are only 13 root name servers (not really), and the transition from networking being pure magic to becoming a commodity. Hope you’ll enjoy our chat as much as I did.
James Miles sent me a long list of really good questions along the lines of “why do we see so many Internet-related outages lately and is it due to BGP and DNS creaking of old age”. He started with:
Over the last few years there are more “high profile” incidents relating to Internet connectivity. I raise the question, why?
The most obvious reason: Internet became mission-critical infrastructure and well-publicized incidents attract eyeballs.
Ignoring the click baits, the underlying root cause is in many cases the race to the bottom. Large service providers brought that onto themselves when they thought they could undersell the early ISPs and compensate their losses with voice calls (only to discover that voice-over-Internet works too well).
Johan Gustawsson wrote a lengthy blog post describing Telia’s approach to next-generation Internet backbone architecture… and it’s so refreshing seeing someone bringing to life what some of us have been preaching for ages:
- Simplify the network;
- Stop cramming ever-more-complex services into the network;
- Bloated major vendor NPUs implementing every magic ever envisioned are overpriced – platforms like Broadcom Jericho2 are good enough for most use cases.
- Return from large chassis-based stupidities to network-centric high availability.
I don’t know enough about optics to have an opinion on what they did there, but it looks as good as the routing part. It would be great to hear your opinion on the topic – write a comment.
I love the recent Internet of Trash article by Geoff Huston, in particular this bit:
“Move fast and break things” is not a tenable paradigm for this industry today, if it ever was. In the light of our experience with the outcomes of an industry that became fixated on pumping out minimally viable product, it’s a paradigm that heads towards what we would conventionally label as criminal negligence.
Of course it’s not just the Internet-of-Trash. Whole IT is filled with examples of startups and “venerable” companies doing the same thing and boasting about their disruptiveness. Now go and read the whole article ;)
Corey Quinn mentioned me in a tweet linking to AWS announcement that they are the biggest user of BGP RPKI (by the size of signed address space) worldwide. Good for them – I’m sure it got their marketing excited. It’s also trivial to do once you have the infrastructure in place. Just saying…
On a more serious front: how important is RPKI and what misuses can it stop?
If you’ve never heard of RPKI, the AWS blog post is not too bad, Nick Matthews wrote a “look grandma, this is how it works” version in 280-character installments, and you should definitely spend some time exploring MANRS resources. Here’s a short version for differently-attentive ;))
A long while ago I found a great article explaining TLS 1.3 and its migration woes on CloudFlare blog. While I would strongly recommend you read it just to get familiar with TLS 1.3, the real fun starts when the author discusses migration problems, kludges you have to use trying to fix them, less-than-compliant implementations breaking those kludges, and options that were supposed to be dynamic, but turn out to be static (rusted shut) due to middleboxes that implemented protocols as-seen-in-the-wild not as-described-in-RFCs.
The REST API calls return text results, so you can use them straight in a Bash script. For example, here’s a simple script to print a bunch of details about your current IP address: