The other day I was searching for a trace file with a decent protocol mix that could be used to introduce a few colleagues to Wireshark. This brought me to Johannes Weber and his Ultimate PCAP.
To get a first impression of a trace file I used Wireshark’s protocol hierarchy – and boy, that’s a lot of protocols. This was not exactly what I was looking for: This single trace file holds snippets from 2014 to 2020 with a myriad of protocols and IP networks. Unfortunately, it’s nothing like the protocol mix found in a network analysis project.
Nevertheless, the trace file caught my interest as a long time Wireshark user. After nearly 20 years of network analysis, I had my own collection of traces with a few odd frames. To my big surprise, I had recorded a few protocols that are not yet part of the Ultimate PCAP.
So here is my small contribution to this collection:
RARP – The Reverse Address Resolution Protocol
Today we use DHCP for dynamic IP address assignment. DHCP relay servers keep the number of DHCP servers to a minimum. You might remember that DHCP is an improvement over the BOOTP protocol, with which it shares the UDP port numbers.
Fun fact: Back in the days, Wireshark used the display filter bootp to identify either BOOTP or DHCP packets. Wireshark 3.0 introduced the new display filter dhcp and deprecated the bootp filter.
RARP, even older than BOOTP, is a layer 2 protocol that shares its data structure with the well-known ARP protocol. A host can (or could) request its own IP address. BOOTP, running on IP, would also deliver more details like the IP address for the default gateway.
Please note that RARP is identified by the Ether type 0x8035. Otherwise, it’s looking pretty much like an ARP frame (you might remember that ARP uses Ether type 0x0806).
The vendor ID suggests that this frame was transmitted by a network printer. I often found the most amusing frames coming from network printers. That is if you are into that type of humor…
ARP with a SNAP header
Another oddball in my collection is an ARP packet that is using a SNAP header:
Please note that Wireshark just shows the protocol ARP in the packet list. Usually, the source MAC address is followed by the Ether type 0x0806, just as the RARP frame is identified by the Ether type 0x8035.
The ethernet header consists of three parts:
- Destination MAC address
- Source MAC address
- Type / Length
The third part is either a type field or a length field, which can be quite confusing. If this value is at least 0x0600 (or 1536 decimal) these two bytes hold an Ethertype. (Refer: IEEE 802 Numbers) Notice how Wireshark decodes the RARP value of 0x8035 as “Type”.
A value of 0x05ff (1535 decimal) or smaller indicates that the two bytes indicate the frame length. This would be 36 byte in the previous screenshot.
Here is a marvel of the type / length field: Over the last decades an incredible number of network protocols were invented. A good part of them was forgotten or superseded by newer, more efficient protocols. A two-byte field would only support 65,536 different network protocols. The smart heads behind Ethernet sacrificed 1,536 of them for a lot flexibility. If the type / length field is smaller than 0x0600 it is considered to be a frame length followed by yet another header, the LLC (Logical Link Control). In this much bigger data structure, a vastly larger number of protocols can be implemented.
I admire the guys who invented Ethernet and build a protocol that held firm in a fast-moving industry for 40 years.
Nowadays the SNAP is mostly used for plain L2 protocols like STP or DTP. ARP is usually identified by an Ethertype, although it is an L2 protocol. Obviously, a few devices still support ARP over LLC. Microsoft has published an article on the inner workings of the TCP/IP implementation of Windows XP. Here is a screenshot from the web page:
If you take a good look at the trace file you will notice that the ARP frames here are not from a Windows system. (Hint: The same MAC address is used for CDP. Also, the ICMP echo requests (“ping”) holds a payload that is pointing to a Cisco device.)
Cisco supports ARP with SNAP encapsulation. Here is one of many pages from the Cisco website:
HDLC over L2TP over IP over MPLS
Johannes, being a keen observer and connoisseur of trace files, also found another interesting detail in my trace file: A L2 VPN tunnel:
This tunnel is the result of a VPLS connection that I had configured in my router lab. VPLS is a technology that can form an Ethernet link between two sites. The full protocol stack will be revealed when we instruct Wireshark to decode the data part as Ethernet: Right-click on the last line of the protocol decode where it says “Data (72 bytes)” and select Decode As …
Now change the protocol to Ethernet, click OK and look what happens to the protocol decode:
The L2TP protocol itself has some control messages as well:
To filter for these HDLC packets you have to use “chdlc”, since it is Cisco HDLC (cHDLC) that is used here.
MPLS & LDP
MPLS stands for Multiprotocol Label Switching, a technology designed for internet service providers and corporate networks of similar size. The other day I picked up a great explanation of MPLS in one sentence: Like a VLAN tag allows for multiple virtual LANs in one local network, the MPLS label allows for multiple virtual WANs in one wide area network.
As seen in the screenshot above, the router inserts a small header between the Ethernet and the IP Header if a packet is forwarded through MPLS. The receiving node will make a forwarding decision based on the label that is found inside the MPLS header. Looking up a label is much faster than a lookup in the routing table.
LDP stands for Label Distribution Protocol. You might guess that it is used between MPLS-enabled routers to inform the remote end how to forward packets marked with a label. Besides “Hello” packets there are initialization, keep alive, and especially “Label Mapping Message” packets. LDP runs on UDP port 646 (discovery) and TCP port 646 (session). As always, you can use “ldp” as the display filter which only shows the mere LDP packets. In case you’re interested in the whole TCP session, you have to use “tcp.port eq 646” or the like. The following screenshot only shows LDP packets without the TCP overhead:
Have fun.