Time to write a new BGP book

▼ 20 years ago this month, my book BGP: building reliable networks with the Border Gateway Protocol was published by O'Reilly.

My 20 author copies of the book arrived a bit later:

Back in those days, publishers would only order a print run if they thought they could sell those copies in a reasonable amount of time. (I think print runs of about 1000 copies to be sold within a year.) If not, no more print runs, and the book would be out of print.

But right around the time sales dipped below the levels required for continued print runs, it started to become possible to have books printed on demand. These days, print on demand shops will print a single book on demand, and you wouldn't know the difference between such a book and a traditionally printed one. So it looks like the old book will be available "in print" forever.

But isn't all the info in the book completely outdated by now?

Perhaps surprisingly, a large part of the book is still current and relevant. When the book was published, BGP version 4 had been around for about a decade. And BGP version 4 is still what we use today. But there have been many (optional) additions to the protocol, and the environment in which BGP finds itself today has evolved.

So time for something new. However, doing an update of the existing book was not in the cards.

So instead, I'm currently writing a new BGP book. This one will be shorter and focus on core BGP topics. It will also have lots of examples that you can try out yourself in a "BGP mini lab".

Keep an eye on this page for updates.

Permalink - posted 2022-09-29

Oh SNAP! There is more to Wi-Fi ↔︎ Ethernet than I thought

▼ The tag line for World IPv6 Launch ten years ago was "the future is forever". You know what else seems to be forever? The past. Let's talk about IEEE 802 LLC/SNAP encapsulation.

I always thought when you send IP packets over Wi-Fi, the IP packet would go inside an Ethernet frame, and then the Ethernet frame inside an 802.11 frame. Turns out this is not how it works: there is no Ethernet header inside IEEE 802.11 packets/frames¹.

What actually happens is that packets are bridged between Ethernet and Wi-Fi. Surprising. But the real shock is that the bridging between Ethernet and Wi-Fi is exactly the same as bridging between Ethernet and FDDI. (An old 100 Mbps fiber ring technology from when Ethernet was still stuck at 10 Mbps.) It's all laid out in this ancient RFC from 1988: RFC 1042.

Bridging is the process of translating one OSI layer 2 frame format to another. In this case, a Wi-Fi access point translates between the Wi-Fi 802.11 header and the Ethernet II header.

Most of the stuff in a Wi-Fi header or Ethernet header is only relevant on the Wi-Fi and Ethernet drivers, respectively. But higher layers in the networking stack do need to interact with two things from the Ethernet header: the MAC addresses and the ethertype. So bridging between two network protocols is possible if the MAC addresses and ethertype are compatible.

Which creates a bit of a problem, as the 802.x family, including 802.11, doesn't do ethertypes. So how do they make sure different packets, such as IP, ARP, IPX, AppleTalk, Wake-on-LAN, et cetera are interpreted correctly by the receiver? Their first try was the LLC header. But that didn't accommodate a sufficiently large number of possible protocols. So add to LLC the SNAP header. The ethertype goes inside the SNAP header. So now we have all the information we need to translate between 802.x protocols (such as 802.11 Wi-Fi) and Ethernet II. The slide below that I copied from this presentation shows how that works:

(Where DEST and SRC are the MAC addresses, type is the ethertype, and AA AA 03 00.00.00 are the values in the LLC and SNAP headers preceding the ethertype. P is the IP packet. Also see the last image here for an actual packet dump.)

But wait... isn't Ethernet IEEE 802.3, so shouldn't it use LLC/SNAP, too?

Well, kinda-sorta-but-not-really. Remember that Ethernet was developed by the DIX consortium (DEC, Intel, Xerox) and then handed off to the IEEE for further tinkering and standardization. As a result, there is a difference between the old Ethernet II header, which has the ethertype, and the 802.3 header, where the same place in the header is actually a length field. (Which we don't need, the Ethernet hardware can tell how long packets are just fine by itself.)

So for IP over actual IEEE 802.3 you need at least the LLC header (which supports IPv4 and ARP) but in practice IP over 802.x always uses LLC+SNAP.

So IP over Ethernet II is actually a relic from the past. But still quite alive. Novell did move to LLC and SNAP, but this just meant that there were now four different frame formats to choose from in your IPX network, and having four incompatible ways to do the exact same thing is never helpful when running a network.

¹ Remember, OSI layer 2 has frames, OSI layer 3 packets and OSI layer 4 segments. So the TCP segment goes inside an IP packet and the IP packet inside an Ethernet frame, each layer adding a header and sometimes a trailer with information relevant to that layer.

Permalink - posted 2022-07-21