Basics: Network layers; ping; ARP; DHCP


Last class we saw the physical pieces of a network — hubs, switches, routers, access points — and noted that each one operates at a different "layer." Today we define those layers properly, and then follow one concrete question all the way down through them: what actually has to happen, in order, between plugging in a laptop and getting a reply back from ping 8.8.8.8? The answer involves three protocols you'll soon implement and capture for yourself: DHCP to get an IP address, ARP to translate that IP address into a MAC address, and ICMP to carry the ping itself.

Slides from class

Files:

Additional information:

Agenda

These notes cover the layered model of networking and the three protocols that get a host from "just plugged in" to "talking to the Internet." Transport-layer detail (TCP and UDP) and DNS are only sketched here; each gets its own day later in the term.

Notes

Why layers?

In the early days of networking, protocols were proprietary to each manufacturer. IBM machines spoke IBM's protocols to other IBM machines — SNA, for instance — and DEC machines spoke DECnet to other DEC machines. An IBM machine and a DEC machine on the same floor simply could not communicate. If you had bought from both vendors, that was your problem to solve.

This was not an accident, and it is worth understanding why. Proprietary protocols are excellent business if you already control the market: they are a barrier to entry for competitors and they lock existing customers in. ("No one ever got fired for buying IBM" captures the customer side of the same dynamic — choosing the dominant vendor is the safe decision for whoever signs the purchase order, even when it isn't the best technical choice.) Incompatibility was a feature for the incumbent vendors and a problem for everyone else.

The fix was to standardize, and specifically to standardize in layers. The key property a layered design buys you is this: upper layers keep working even when lower layers change. The Network layer and everything above it behaves the same way whether the bits are traveling as radio waves over Wi-Fi or as electrical pulses down an Ethernet cable. Each layer offers a defined service to the layer above and depends only on the defined service of the layer below, so you can replace the implementation of one layer without rewriting the others. That single idea is why the Internet survived the transition from dial-up to fiber to LTE without the web having to be redesigned.

The OSI and TCP/IP models

Two frameworks emerged. The Open Systems Interconnection (OSI) model, published by the International Organization for Standardization (ISO) in 1984, defines seven layers from the physical medium up to the application:

7) Application
6) Presentation
5) Session
4) Transport
3) Network (IP)
2) Link (MAC)
1) Physical

The TCP/IP model — which actually came first, despite usually being taught second — collapses OSI's top three layers into a single Application layer, giving five layers: Application, Transport, Network, Link, Physical. (Some authors also merge Physical and Link, giving four; you will find anywhere from three to seven layers in the literature.) A useful quirk of history: even in the five-layer model we still call the Application layer Layer 7, because the numbering comes from OSI.

The TCP/IP model also travels under many names — the network model, the Internet model, the protocol stack, the reference model. Fair warning: I will use all of these interchangeably, and so will the textbook, and so will anyone you work with.

Which model should you learn? Both, for different reasons. OSI's value is largely educational and conceptual: it is a clean framework for thinking about layering and for designing new protocols so they fit together. TCP/IP is what actually runs the Internet. In practice, people describe real systems in TCP/IP terms while using OSI's layer numbers, which is why "that's a Layer 7 problem" and "the Layer 2 header" are both things you'll hear in the same sentence.

The layers, one at a time

Working from the bottom up. For each layer, the questions to keep in mind are: what unit of data does it move, how does it name the thing it's moving, and what does it not know about?

Layer 1: Physical — transports bits

The physical layer is concerned only with how data is physically transmitted. A transmitter converts logical 1 and 0 bits into electrical pulses, pulses of light, or the phase and amplitude of a radio frequency signal, and sends them down a wire or over the air. A receiver converts them back into logical 1s and 0s. That's the whole job.

Fiber optic cable uses a glass or plastic core to channel light from a laser or LED; at a given instant, a light pulse is a 1 and no pulse is a 0. Two varieties of fiber optic cable matter. Single mode fiber uses one light frequency through a small core (~9 microns) and carries a signal a long way (~40 km), which makes it the choice for long-haul links. Multimode fiber uses multiple frequencies through a larger core (~60 microns) but only reaches about 100 m, which suits it to runs inside a building or across a campus. Theoretical capacities are in the petabits per second; practical deployed rates are around 800 Gb/sec. One piece of hands-on advice: do not bend fiber cables. They break.

Ethernet cable uses twisted pairs of copper wire, either unshielded twisted pair (UTP) or shielded twisted pair (STP). Categories run from Cat 5e (1 Gb/sec) up to Cat 8 (40 Gb/sec), and a run goes about 100 m before signal degradation becomes a problem, although Cat 8 is limited to about 30 m, which is why it is used inside data centers rather than for building wiring. Cables come in two wirings. A straight-through cable connects a computer to a switch or router; a crossover cable connects two computers directly. The difference is which pin-out standard is used on each end: T568A and T568B differ by swapping the green and orange pairs, so B-to-B (or A-to-A) is straight-through and A-to-B is a crossover.

T568A: 1-white/green, 2-green, 3-white/orange, 4-blue, 5-white/blue, 6-orange, 7-white/brown, 8-brown.
T568B: 1-white/orange, 2-orange, 3-white/green, 4-blue, 5-white/blue, 6-green, 7-white/brown, 8-brown.

A question worth sitting with, since it will come back all term: how would you tap an Ethernet cable? One answer is to cut the cable and splice in a hub — recall from last class that a hub broadcasts everything to every port, so anything you attach sees all the traffic. That works but requires power and is fairly obvious. A Throwing Star LAN Tap does the same job passively, with no power at all, by wiring the transmit pairs out to monitor ports. The physical layer has no notion of authentication or secrecy; if you can reach the medium, you can read the bits. Everything protecting your traffic lives at higher layers.

Radio frequency (RF) sends data over the air: Wi-Fi, Bluetooth, cellular, satellite. The transmitter sends at a known phase and amplitude and the receiver converts that back into bits. Wi-Fi reaches roughly 100 m, Bluetooth roughly 10 m, and the theoretical maximum speed for current Wi-Fi (802.11be) is around 46 Gb/sec.

The crucial point about all three media: however the bits arrived, they are decoded and handed up to Layer 2 in exactly the same form. Does the Link layer care whether its bits came from glass, copper, or air? No. That indifference is the layering principle doing its work.

Layer 2: Link — moves frames within a LAN

The link layer moves frames within a single local area network, a process called switching. Each host is identified by the MAC address on its Network Interface Card, burned into the NIC's ROM by the manufacturer and not normally subject to change. Two iPhones of the same model have different MAC addresses. This layer goes by many names: Layer 2, the MAC layer, the data link layer, or the Ethernet layer.

You can see your own MAC address with ifconfig on macOS and Linux, or ipconfig on Windows. On a Mac, the ether line of the en0 stanza holds it for the en0 network interface:

% ifconfig
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 5c:e9:1e:a2:4d:4f
    inet 10.0.0.64 netmask 0xffffff00 broadcast 10.0.0.255
    status: active

Note that both addresses are visible there: the Layer 2 ether address and the Layer 3 inet address. (If the full output is more than you want, ifconfig | grep "en0" -A 7 prints the interface line plus the following seven lines.)

Switches operate here at Layer 2. A switch connects devices in a local area and forwards traffic based on MAC addresses, and it learns: when a device transmits for the first time, the switch records which MAC address was seen on which port and keeps that in a table that maps MAC to switch port. Thereafter, frames for that MAC go out that port only. Critically, a switch knows nothing about the layers above it — IP addresses are invisible to it. Which gives us the key point of this layer: Layer 2 deals only with hosts in the same LAN. There is no routing here.

Layer 3: Network — moves packets between LANs

The network layer moves packets between local area networks, a process called routing. Every host on the Internet is identified by an IP address (IPv4, 32 bits, or IPv6, 128 bits). This layer is also called Layer 3 or the IP layer, and ICMP — the protocol behind ping — lives here.

An IP address is assigned in one of two ways: statically, by hand, or dynamically via DHCP. How an IP address is assigned is the subject of its own section below.

Two properties of Layer 3 to hold onto. First, it is the mirror image of Layer 2 in what it ignores: Layer 3 does not know about MAC addresses, just as Layer 2 does not know about IP addresses. This clean separation is exactly what will force us to introduce ARP below. Second, delivery is not guaranteed at Layer 3. Routing finds efficient paths between LANs, large packets may be broken into pieces and reassembled at the receiver, and packets may simply be lost along the way. Layer 3 makes a best effort and makes no promises of delivery.

Layer 4: Transport — moves segments and datagrams

The transport layer moves segments (TCP) or datagrams (UDP) and may add error control, flow control, and application addressing. The two protocols you'll care about are TCP, which is connection-oriented and provides sequencing, retransmission of dropped packets, and congestion control, and UDP, which is connectionless and provides essentially none of that.

This layer also introduces ports: numbers that identify which application on the host should receive the data. Note that a Layer 4 port is a number, not a physical socket like a Layer 2 switch port — unfortunately we use the same word for both.

Layer 3 gives no delivery guarantee, and yet TCP claims to provide reliable delivery. So: can you build a reliable channel on top of an unreliable one? You can, and the ingredients are sequence numbers and acknowledgments — number each piece, have the receiver confirm what it got, and resend whatever goes unconfirmed. Working out the details is a significant chunk of the transport unit later in the term.

Layer 7: Application — moves messages between applications

The application layer interacts with application programs to send messages. Each application is assigned a port, and multiple instances can run at once (think many browser tabs). Familiar examples: HTTP, SSH, FTP, SMTP, DNS.

Encapsulation: down the stack and back up

Layers are not just a taxonomy; they describe the literal structure of the bytes on the wire. When a transmitter wants to send a message, that message starts at the top of the stack and travels down. Each layer encapsulates what it received from above — treating it as an opaque payload — and prepends its own header. At Layer 7 HTTP adds HTTP headers; at Layer 4 TCP prepends those bytes and with a TCP header containing sequence numbers and ports; at Layer 3 IP prepends an IP header with source and destination IP addresses; at Layer 2 Ethernet or 802.11 prepends that and adds a Layer 2 header with source and destination MAC addresses. You can think of what finally goes out the NIC is a set of nested envelopes, but really each layer simply prepends bytes to the bytes passed down from the layer above.

At the receiver the process runs in reverse. The message arrives at the physical layer and moves upward, each layer stripping off the header its counterpart added and handing the payload up. The Layer 2 removes the MAC header and hands the IP packet up; Layer 3 removes the IP header and hands the segment up; and so on up to the application.

This is precisely what you see in Wireshark. The top pane summarizes each captured frame, the middle pane lets you expand Layer 2, Layer 3, Layer 4, and Layer 7 in turn, and the bottom pane shows the raw bytes in hex, highlighting the bytes corresponding to whatever field you selected. Network communication is just a pile of bytes; Wireshark's contribution is knowing how to decode them layer by layer. Getting comfortable moving between those three panes is one of the practical skills this course is trying to build.

Getting an IP address: static assignment and DHCP

A new host on a network has a MAC address burned into its NIC, but has no IP address, and without one it cannot participate at Layer 3. There are two ways to get an IP address:

Static assignment. A network administrator sets the address by hand. In the old days this was how every host got configured, which is as tedious and error-prone as it sounds. It's still used today for things that shouldn't move — servers, printers, network equipment — precisely because other machines need to be able to find them at a known address.

Dynamic assignment via DHCP. The Dynamic Host Configuration Protocol designates a server that hands out addresses from a pool. When a host joins the network, the DHCP server gives it an address not currently in use. Each assignment is a lease with an expiration time, so that addresses belonging to devices that have left the network eventually return to the pool; a host that is still around can renew its lease before it expires.

The DORA exchange

DHCP has a bootstrapping problem that makes it a nice thing to study early: the arriving client has no IP address, and does not know the DHCP server's IP address either. So how do you address a message? The answer is to broadcast. The exchange takes four messages, easily remembered as DORA — Discover, Offer, Request, Acknowledge. In the example below the DHCP server is at 223.1.2.5 and it will offer the client an address of 223.1.2.4. Remember, initially the new client does not have an IP address or know the DHCP server's address.

  1. DHCP Discover. The client broadcasts: is there a DHCP server out there?
    src: 0.0.0.0, 68   dest: 255.255.255.255, 67   yiaddr: 0.0.0.0   transaction ID: 654
    Two things to explain here. The source IP is 0.0.0.0 because the client has no address yet. The destination is 255.255.255.255, the broadcast address, because the client doesn't know the server's address. Each host that receives a broadcast message will evaluate the packet. A DHCP server will reply to a DHCP Discover message, other hosts will ignore it. Note also the ports: DHCP clients use port 68 and servers use port 67.
  2. DHCP Offer. The DHCP server replies to the Discover message: I'm a DHCP server, and here's an address you may use.
    src: 223.1.2.5, 67   dest: 255.255.255.255, 68   yiaddr: 223.1.2.4   transaction ID: 654   lifetime: 3600 secs
    The reply is broadcast too, since the client has no address yet. So how does the client know this reply is for it and not for some other machine booting up at the same moment? The transaction ID: the client generated 654 the DHCP Discover message in this example, and matches it in the reply. The yiaddr field ("your IP address") carries the offer, and lifetime is the proposed lease duration.
  3. DHCP Request. The client replies that it will take the offered address.
    src: 0.0.0.0, 68   dest: 255.255.255.255, 67   yiaddr: 223.1.2.4   transaction ID: 654   lifetime: 3600 secs
    The source is still 0.0.0.0 — the client doesn't own the address until the server confirms. The extra round trip exists because there might be more than one DHCP server on the network, each having made an offer; this message announces which offer the client accepted.
  4. DHCP ACK. The server confirms: yes, that address is yours.
    src: 223.1.2.5, 67   dest: 255.255.255.255, 68   yiaddr: 223.1.2.4   transaction ID: 654   lifetime: 3600 secs

Steps 1 and 2 can be skipped when a client remembers and wishes to reuse an address it was previously allocated (RFC 2131). Dartmouth's network remembers your MAC address, so in practice you'll often observe the short version of the exchange rather than the full DORA.

The ACK typically carries more than just an address. DHCP commonly also returns the IP address of the client's first-hop router (its default gateway), the name and IP address of a DNS server, and the network mask indicating which portion of the address identifies the network and which identifies the host. So this exchange is what bootstraps a host into being a functioning participant on the network.

Worth pausing on the security posture here, since we'll return to it: nothing in this exchange is authenticated. The client believes whoever answers its broadcast. A machine on your LAN that answers Discover messages faster than the real server can make itself your default gateway and your DNS server — which is to say, can put itself in the middle of all of your traffic.

Watching DHCP in Wireshark

You can force this exchange to happen and capture it. Start Wireshark in your VM ($ wireshark), then in a terminal find your interface with ifconfig. On the course VM the interface is ens160. Then drop and renew the lease:

$ sudo dhclient -r ens160   # release the lease
$ sudo dhclient ens160       # get a new lease

In the resulting capture, expand the Discover message layer by layer and confirm that the story above is literally what's on the wire. At Layer 2 the frame goes from the VM's MAC at 00:0c:29:40:05:21 to broadcast on Layer 2 at ff:ff:ff:ff:ff:ff — it uses the broadcast MAC, because the client doesn't know the server's MAC address either. At Layer 3 it goes from IP address 0.0.0.0 to broadcast at 255.255.255.255, with a time to live of 128 (0x80) and a protocol field of 17 (0x11) indicating that Layer 4 holds UDP. At Layer 4, the UDP source port is 68 (0x44) and the destination port is 67 (0x43). At Layer 7, the DHCP message type byte distinguishes the four messages: 01 Discover, 02 Offer, 03 Request, 05 ACK.

In the capture from the VM, the server at 192.168.159.254 offers 192.168.159.133 along with a lease timeout and the LAN router's address; the client Requests it; the server ACKs. Afterward, ifconfig confirms the new inet 192.168.159.133, and ip route shows the gateway the offer supplied:

$ ip route
default via 192.168.159.2 dev ens160 proto dhcp src 192.168.159.133 metric 100
192.168.159.0/24 dev ens160 proto kernel scope link src 192.168.159.133 metric 100

At this point the new client now know the router's IP address (from the DHCP ACK message), but not its MAC address. We will soon use Address Resolution Protocol (ARP) to learn the router's MAC.

ICMP and ping

Let's say the new client now wants to confirm it has Internet access. It might use the Internet Control Message Protocol (ICMP) to exchange network-level information, principally error reporting: host unreachable, network unreachable, port unreachable, protocol unreachable. ICMP messages are carried inside IP datagrams, which makes ICMP a Layer 3 protocol.

Ping is the best-known use of ICMP. ping <IP address> sends an ICMP echo request and listens for an ICMP echo reply, timing the round trip. It's the first thing to reach for when testing whether a host is reachable. ping 8.8.8.8 is a common test network engineers use because 8.8.8.8 is Google's public DNS server and the address is easy to remember.

An ICMP message carries a type and a code, plus the first 8 bytes of the IP datagram that caused it (so the sender can tell which of its packets went wrong). The types you'll meet most:

0  0  echo reply (ping)
3  0  destination network unreachable
3  1  destination host unreachable
3  2  destination protocol unreachable
3  3  destination port unreachable
3  6  destination network unknown
3  7  destination host unknown
4  0  source quench (congestion control — not used)
8  0  echo request (ping)
9  0  route advertisement
10 0  router discovery
11 0  TTL expired
12 0  bad IP header

You will write your own ping program in Lab 1, so it's worth knowing that echo requests also carry a sequence number, which you'll need in order to match replies to requests.

Traceroute: ping plus TTL

Ping tells you whether a host is reachable, but not what path your packets took. Last class we used traceroute output without asking how it works; the mechanism is a nice piece of opportunism built from three facts:

Put those together and you can enumerate the path. The source sends sets of UDP segments toward the destination: the first set with TTL = 1, the second with TTL = 2, and so on (three probes per set, which is why traceroute output shows three times per line). The datagrams in the nth set die at the nth router, which discards them and (hopefully) sends back a TTL-expired message identifying itself. When that message arrives, the source records the RTT. Increment, repeat, and the path assembles itself one hop at a time.

Traceroute stops when a UDP segment finally reaches the destination host, which — because the probes are aimed at an unlikely port — replies with ICMP "port unreachable" (type 3, code 3). That distinctive reply is how the source knows it has arrived. Failing that, it stops at a hop limit; note that Dartmouth blocks these probes, so you'll see the limit case on campus.

Notice that this all depends on routers choosing to send TTL-expired messages. Nothing forces them to, and many don't, which is why real traceroute output is full of lines showing only asterisks. You'll implement traceroute in Lab 1 as well.

ARP: from IP address to MAC address

Here is the gap left by our clean layer separation. Our example, a new client knows its own MAC address (burned into the NIC) and its own IP address (from DHCP), and it knows the router's IP address (also from DHCP). To send anything at all, though, it must build a Layer 2 frame, and a Layer 2 frame requires a destination MAC address. The new client does not yet know the router's MAC address. Layer 3 doesn't know about MACs, Layer 2 doesn't know about IPs, and somebody has to bridge the two.

That somebody is the Address Resolution Protocol (ARP), which maps IP addresses to MAC addresses within a LAN. It works by broadcast, in two messages:

The requester then stores the mapping in its ARP table (or ARP cache), so it doesn't have to ask again for every packet. Entries look like 10.0.0.3 -> 00:02:4A:8D:E1:84 and expire after a while.

Once again, note what's missing: authentication. An ARP reply is believed because it arrived. Any host on the LAN can answer "who has the router's IP?" with its own MAC address, and thereby quietly become the router as far as its neighbors are concerned. That's ARP spoofing, it is the standard way to get into the middle of traffic on a switched LAN, and we'll come back to it in Lab 1.

Putting it together: one ping to 8.8.8.8

Imagine a new laptop has just come up on a LAN and wants to ping 8.8.8.8. Here is everything that has to happen, in order:

  1. The laptop knows its MAC address without asking anyone; it was burned into the NIC.
  2. DHCP gives it an IP address — 192.168.159.133 — along with a lease, a network mask, a DNS server, and the IP address of the first-hop router, 192.168.159.2 after the DHCP exchange of DORA messages.
  3. The laptop wants to reach 8.8.8.8, which is not on its LAN. Google's server sits on some other network; the router is what joins the laptop's LAN to the Internet. So the packet must be handed to the router. At Layer 3 the packet is addressed to 8.8.8.8, but at Layer 2 the frame must be addressed to the router.
  4. ARP supplies the router's MAC address. The laptop broadcasts "who has 192.168.159.2?"; the router replies "192.168.159.2 is at 00:50:56:f5:9e:21."
  5. The laptop sends the ping. The frame's Layer 2 header has destination = the router's MAC (from ARP) and source = the laptop's own MAC. Inside, the Layer 3 header has source = 192.168.159.133 and destination = 8.8.8.8. Inside that, the ICMP message is type 8, code 0 — echo request — with a sequence number.
  6. Google replies. The echo reply comes back with Layer 3 source 8.8.8.8 and destination 192.168.159.133, and ICMP type 0, code 0, carrying the same sequence number as the request so the laptop can match them up.
  7. At Layer 2, though, the laptop sees the router's MAC as the source, not Google's. This is the detail most worth extracting from the whole exercise: MAC addresses are rewritten at every hop, IP addresses are not. Layer 2 addressing is local to a single link; Layer 3 addressing is end to end. Google's MAC address is not merely unknown to your laptop, it is irrelevant to it.

One loose end: how did we get 8.8.8.8 in the first place? In this example we typed it, because it's memorable. For google.com we'd need the Domain Name System to translate the name to an address, which is a story for another day.

Exercises

To do before/around the next class:

Terms

Not a comprehensive reference — the textbook has much more — but these are the terms from Day 2 that will keep coming back.

OSI (Open Systems Interconnection) model
A seven-layer reference model published by ISO in 1984: Physical, Link, Network, Transport, Session, Presentation, Application. Primarily a conceptual and teaching framework, and the source of the layer numbers everyone uses.
TCP/IP model
The five-layer model actually used in practice, collapsing OSI's top three layers into one Application layer: Physical (1), Link (2), Network (3), Transport (4), Application (7). Also called the network model, Internet model, protocol stack, or reference model.
Physical layer (Layer 1)
Converts logical 1s and 0s to and from electrical pulses, light, or radio signals and moves them over a medium. Moves bits.
single mode / multimode fiber
Single mode uses one frequency in a ~9 micron core for long-haul runs (~40 km); multimode uses multiple frequencies in a ~60 micron core for short runs (~100 m).
UTP / STP
Unshielded and shielded twisted pair copper cable. Categories 5e (1 Gb/sec) through 8 (40 Gb/sec), with runs up to about 100 m.
straight-through / crossover cable
Straight-through (same pin-out both ends, e.g. T568B to T568B) connects a computer to a switch or router; crossover (T568A to T568B) connects two computers directly.
Link layer (Layer 2)
Moves frames within a single LAN using MAC addresses; no routing happens here. Also called the MAC layer, data link layer, or Ethernet layer.
MAC address
A 48-bit identifier burned into a NIC's ROM by the manufacturer, unique per interface and not normally changed. ff:ff:ff:ff:ff:ff is the broadcast MAC.
Network layer (Layer 3)
Moves packets between LANs (routing) using IP addresses. Delivery is not guaranteed. Also called the IP layer; ICMP lives here.
Transport layer (Layer 4)
Moves segments (TCP) or datagrams (UDP) and may add error control, flow control, and ports. TCP is connection-oriented with sequencing, retransmission, and congestion control; UDP is connectionless.
port
A Layer 4 number identifying which application should receive data. A number, not a physical socket — DHCP clients use 68 and servers 67.
Application layer (Layer 7)
Moves messages between application programs. Examples: HTTP, SSH, FTP, SMTP, DNS.
encapsulation
Each layer treats what it receives from the layer above as an opaque payload and prepends its own header. At the receiver, each layer strips the corresponding header and passes the payload up.
DHCP (Dynamic Host Configuration Protocol)
Assigns IP addresses to arriving hosts from a pool, as time-limited leases, and commonly also supplies the first-hop router, DNS server, and network mask.
DORA
The four DHCP messages: Discover (client broadcast), Offer (server proposes an address), Request (client accepts), Acknowledge (server confirms). Matched up by transaction ID because neither side can address the other normally yet.
lease
A DHCP address assignment with an expiration time, so addresses return to the pool when devices leave. Clients may renew.
yiaddr
"Your IP address" — the DHCP field carrying the address being offered or confirmed.
ICMP (Internet Control Message Protocol)
A Layer 3 protocol carried inside IP datagrams, used by hosts and routers for network-level signaling and error reporting. Identified by a type and code, and returns the first 8 bytes of the offending datagram.
ping
A program that tests reachability and measures RTT by sending an ICMP echo request (type 8, code 0) and awaiting an echo reply (type 0, code 0).
TTL (time to live)
A hop-count field in an IP datagram, decremented by each router. On reaching zero the router discards the datagram and is supposed to return ICMP type 11, code 0.
traceroute
Discovers a path by sending probes with TTL = 1, 2, 3, ... and collecting the TTL-expired messages each successive router returns. Stops on ICMP port unreachable (type 3, code 3) from the destination, or at a hop limit.
ARP (Address Resolution Protocol)
Maps an IP address to a MAC address within a LAN. The requester broadcasts a "who has <IP>" request (opcode 1) and the holder replies "<IP> is at <MAC>" (opcode 2). Ethernet type 0x0806.
ARP table (ARP cache)
A host's stored IP-to-MAC mappings learned from ARP replies, so it need not re-ask for every packet. Entries expire.
first-hop router / default gateway
The router that connects a host's LAN to other networks, and therefore the Layer 2 destination for any packet whose Layer 3 destination is off-LAN.

Credit: Most information on this page is from Computer Networking: A Top-Down Approach, 9th edition by Kurose and Ross.
This page was generated by Claude from in-class slides.