Whether it’s copper or fiber-optic cable, or even radio waves, physical wire is a layer of the network. Without some physical media to run over, a network cannot function. Everything from the CAT5 cable plugged into your desktop to the fiber-optic cable connecting you to Asia is part of the physical layer. If it can be tripped over, backhoed, or interfered with, it’s part of the physical layer. For simplicity’s sake, I’ll refer to the physical layer as the wire, although it can take innumerable forms.

This is the easiest layer to understand. If your wire meets the requirements of the physical protocol, you’re in business. If not, your network won’t work. One of the functions of Internet routers is to connect one sort of physical layer to another—for example, converting local Ethernet into an OC3 fiber connection.

The physical layer has no decision-making abilities of its own; everything that runs over it is dictated by the datalink layer.

The datalink layer is the protocol that runs over the physical wire. It transforms information into the actual signals that are sent over the physical layer, using the appropriate encoding for that physical media, as follows:

OpenBSD supports other common datalink protocols, such as PPP over Ethernet (PPPoE). If you have unusual network requirements, check the OpenBSD website, mailing lists, or man pages to see if those requirements are supported.

Some datalink layers have been implemented over many different physical layers. Ethernet, for example, has been implemented over twinax, coax, CAT3, CAT5, CAT6, CAT7, optical fiber, and radio waves. And for true device independence, we have seen TCP/IP implemented with a biological transport layer: carrier pigeon.^[27]

With minor changes to the device drivers, the datalink layer can address any sort of physical layer. This is one of the ways in which layers simplify the network.

Chapter 12 discusses Ethernet in detail, as it’s the most common network type for OpenBSD systems. Once you understand how Ethernet works, you’ll have no difficulty adding new datalink protocols as needed.

The datalink layer exchanges information with the physical layer and the network layer.

The network layer is the part that maps connectivity between network nodes, answering questions like “Where are other hosts?” and “Can I get there from here?” This logical protocol provides a consistent interface to programs that run over the network, no matter what the physical and datalink layers look like.

The network layer used on the Internet is the Internet Protocol, or IP. Both version 4 (IPv4) and version 6 (IPv6) provide each host with one or more unique IP addresses, so that any other host on the network can find it. Okay, IPv4 network address translation munges the whole “unique address” rule, but your network still has a unique IP address somewhere.

The network layer talks to the datalink layer below it and the transport layer above it.

The transport layer is where actual data flows. The three most common transport layer protocols are the Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP).

ICMP passes basic connectivity messages between hosts with IP addresses. If IP provides a road and addresses, ICMP provides traffic lights and highway exit signs. Most of the time, ICMP runs silently in the background.

UDP and TCP are the protocols that carry actual data between hosts, and they are so prevalent that the suite of Internet protocols is usually called TCP/IP. UDP is a bare-bones transport protocol, offering the minimum services needed to transfer data over the network. Its minimalism means that if you want to customize exactly how data flows in your application, you can build it out of valid UDP. TCP provides more sophisticated features, such as integrity checking and congestion control, but many of its settings are hard-coded.

In addition to these three, many other protocols run at the transport layer. The file /etc/protocols contains a fairly comprehensive list of transport protocols built atop IP. While it lists many more protocols than you will ever actually deal with out in the wild, it doesn’t include non-IP protocols like IPX/SPX or Digital Equipment Company’s DECnet.

As an example, let’s have a look at the first entry from /etc/protocols:

ip      0       IP HOPOPT       # internet protocol, pseudo protocol number

Each /etc/protocols entry has three key fields: an official name, a protocol number, and any aliases. The IP protocol, protocol 0, is known as IP and (very occasionally) as HOPOPT. Each protocol also has a comment giving it some context. Although some of the protocols in /etc/protocols are long gone, some antediluvian devices out there might still speak them.

Note that ICMP, TCP, and UDP are slightly different when run over IPv4 versus IPv6. Each protocol has clearly defined fields in the IP packet header, leaving specific numbers of bits for things like checksums, destination addresses, and so on. You can’t run a transport protocol over an incompatible network protocol—TCPv6 over IPv4 just doesn’t work.

The transport layer speaks to the network layer below and to the applications layer above it.

Applications are definitely part of the network. Applications request network connectivity, send data over the network, receive data from the network, and process that data. Web browsers, email clients, JavaServer Pages (JSP) servers, and so on are examples of network-aware applications. Applications need to communicate with only the transport protocol and the user. The upper three layers of the OSI network model are inside applications.

Problems with the user layer are beyond the scope of this book, but I find that many of these issues can be solved with proper application of a large chainsaw.