Resilience is an important factor when evaluating Internet Service Providers. Unfortunately, it is not always easy to quantify the resilience of a given ISP by using measurements or information about the ISP. The resilience of an ISP depends on a wide range of factors and a small detail can sometimes significantly lower the resilience of an entire ISP. Often, these details are only exposed by catastrophic or unexpected events. This happened a few weeks ago when Optus, a major ISP in Australia, went offline for almost half a day. Several posts provide an analysis and attempt to explain the reasons for this outage: a detailed blog by kentik show the impact on traffic and BGP and a short article on LightReading points a possible culprit.

Researchers and network engineers often turn to iperf to measure the performance of Internet protocols on various types of networking technologies. A recent post by Simon Leinen on LinkedIn reminded us that there are two very different versions of iperf.

• iperf3 supports TCP, SCTP and UDP. It can measure bandwidth, packet looses and delay jitter with UDP. It supports multicast with UDP.
• iperf2 supports TCP and UDP, but not multicast. It can perform tests with isochronous traffic, TCP bounce back and other tests. It also provides more metrics, including latency than iperf3. See the detailed comparison between the two iperfs

The next time you plan to use iperf, take a few seconds to select the tool that best matches your requirements instead of using the first result from your favorite search engine.

The MIRAI botnet is often used as a case study when analyzing Distributed Denial of Service attacks. A Wired article provides a detailed interview with the three main authors of this botnet.

IPv6 continues its deployment and operational details matter. An APNIC blog post discusses the importance of supporting IPv6 (and IPv4) on authoritative name servers, and analyzes measurement results. A blog post provides a brief and interesting overview of the operation of DHCPv6 with sample packet traces to better understand this important protocol.

Major CDNs have started to support Encrypted Client Hello (ECH). This is a TLS extension that enables the encryption of the ClientHello message on TLS session. The main benefit of ECH is that passive observers, such as firewalls, cannot anymore extract the server name from the packets that they process. The deployment of ECH has several operational implications for network administrators who manage firewalls and security devices. If you’d like to test and experiment with ECH, the Guardian Project provides a detailed tutorial on how to support ECH on servers.

During the last years, network operators have deployed RPKI to counter different forms of prefix hijacking using interdomain routing. A growing number of ISPs support this effort. The last addition is AWS summarized their deployment in a blog post.

We are used to the A, AAAA, MX, NS or CNAME DNS records. Recently, the IETF approved RFC9460 which defines the SCVB and HTTPS resource records. These records are already used by by large CDNs and web operators. They provide useful information for browsers needing to access remote web sites. An interesting blog post provides a detailed explanation of these two new record types and sample packet traces.

The last note for this week is the Packet Run. This artistic installation at the Dutch Design Week 2023 in Eindhoven is an interactive marble run that shows people how the Internet works. A rare example of art meeting networking…

This blog aims at encouraging students who read the open Computer Networking: Principles, Protocols and Practice ebook to explore new networking topics. You can follow this blog by subscribing to its RSS feed or by following @cnp3_ebook on mastodon.