NSSA-241 Feynman Notebook — the whole course in plain words (standard-font edition)

"How to Use This Notebook"

Learn It the Feynman Way

The rule of this whole book

If you can't explain an idea in plain words, you don't know it yet — the gap is the idea, not the vocabulary.
Every page here teaches with everyday pictures: light switches, envelopes, cakes, receptionists. No jargon lands unexplained.

The loop

Read one page → close it → teach it aloud to an empty chair → notice what you couldn't say → reread just that part.
Phases build on each other: 0 → 1 → 2 → 3 → 4 → 5 → 6. Don't skip — every concept lands on one you already own.
When a page feels "obvious", you've mastered it. Move on, come back tomorrow, and test yourself cold.

Sidebar groups fold and unfold — click a heading; click ⟨ to hide the whole sidebar
Companion: the Field Guide holds the drills (175 questions), mnemonics, and the cheat sheet
Print works — the pages, sketches and banners keep together on paper

What I cannot create from scratch in my own words, I do not understand.

Phase 0 · Number systems

"Binary from Zero" (Phase 0 · page 1/2)

Eight Light Switches Are the Only Math This Course Needs

Bits are just light switches

A bit is the smallest thing a computer stores: one light switch that is either off (0) or on (1) — nothing in between.
Why stop at two symbols? A circuit that only ever has to tell "off" from "on" is cheap and reliable. One that had to reliably tell apart ten brightness levels would misread constantly — two states is the safest bet electronics can make.
Line up eight switches and you get a byte — networking people call it an octet, same eight switches, just a different name.

One octet, 256 patterns

Each of the 8 switches flips independently — on or off no matter what its neighbors are doing.
Two choices for the first switch, times two for the second, times two for the third... eight times over: 2×2×2×2×2×2×2×2 = 256 distinct patterns.
Those 256 patterns are exactly why one octet represents decimal 0 through 255, and nothing beyond it. An IPv4 address strings four octets together (32 switches); a MAC address strings six together (48 switches) — same trick, repeated.

The doubling ladder — and why it can't skip or repeat

Each switch position carries a fixed weight, a value it contributes when it's on. Read right to left, the weights double: 1, 2, 4, 8, 16, 32, 64, 128.
Worth pausing on: every weight equals all the smaller weights added together, plus one. Check it: 2=1+1, 4=(2+1)+1, 8=(4+2+1)+1, all the way up to 128=(64+32+16+8+4+2+1)+1.
That fact is why binary never wastes a pattern and never doubles one up. Turning on the next switch always jumps past every combination the smaller switches could ever make, by exactly one — no gaps, no repeats, like a ruler with every mark drawn once.

Only the shaded (ON) switches count — add their weights to read the value.

Biggest weight first, every time — subtract, then move to the next.

Eight independent switches, two choices each: 2×2×2×2×2×2×2×2 = 256 patterns, exactly 0-255.

Exponents: shorthand for "double this many times"

2ⁿ ("two to the power n") means start at 1 and double it n times: 2¹=2, 2²=2×2=4, 2³=2×2×2=8, 2⁴=16.
Eight switches means eight doublings: 2⁸ = 256 — the very same 256 patterns from the ladder above, just written compactly.
Every "big" number ahead — 256 addresses, 65,536 ports, 4.3 billion IPv4 addresses — is one of these doublings. Learn the doubling trick, not the digits.

Reading binary: add up the weights under the 1s

To turn a switch pattern into a decimal number, look only at the switches that are on. Find the weight sitting under each one and add those weights together. Every switch that's off contributes nothing at all.
Worked example — convert 10010101: line the bits under the ladder 128 64 32 16 8 4 2 1. The 1s land under 128, 16, 4, 1. Add what's lit: 128+16+4+1 = 149.
Try these the same way: 11100100 → 128+64+32+4 = 228. 11000000 → 128+64 = 192 — remember that one, it reappears constantly once you reach subnet masks.

Writing binary: always take the biggest bite first

Going the other way, decimal to binary: ask the biggest weight first — does it fit inside what's left? If yes, switch it on and subtract it. If no, leave it off and ask the next smaller weight. Repeat down to weight 1.
Worked example — convert 94: 128 fit? No → 0. 64 fit? Yes → 1, remainder 30. 32? No → 0. 16? Yes → 1, remainder 14. 8? Yes → 1, remainder 6. 4? Yes → 1, remainder 2. 2? Yes → 1, remainder 0. 1? No → 0. Read top to bottom: 01011110. Check by adding back: 64+16+8+4+2 = 94 ✓.
Why biggest-first can never fail: every weight is one more than all the smaller weights combined — so if you skipped the biggest weight that fits, no combination of the smaller ones left could ever reach it; you'd always fall short. Taking the biggest bite every time is the only strategy guaranteed to land exactly on the target with nothing left over.

Same trick, different multiplier — decimal steps by 10s, binary steps by 2s.

An octet is 8 bits; 8 independent switches make 2⁸ = 256 patterns, decimal 0-255.
Weights double right to left — 128,64,32,16,8,4,2,1 — and every weight equals all smaller weights combined, plus one.
Read binary by adding the weights under the 1s (10010101 = 149); write it by taking the biggest weight that fits, over and over (94 = 01011110).
2ⁿ means "double n times" — the same trick behind 256 addresses, 65,536 ports, and 4.3 billion IPv4 addresses.

Read the lit switches to name a number; flip the biggest one first to build one.

"Hex — Binary for Human Eyes" (Phase 0 · page 2/2)

Same Switches, Grouped Four at a Time

Why hex exists: binary is unreadable at MAC-address scale

A MAC address (a network device's built-in hardware ID) is 48 bits long. Written as raw binary that's a 48-character string of 0s and 1s — easy to mistype, brutal to proofread, painful to read aloud.
Hexadecimal ("hex", base 16) exists purely to make binary readable to humans. It doesn't change what the bits mean — same switches, just grouped and relabeled into friendlier chunks.
Grouping shrinks 48 bits down to 12 characters: a MAC like 6C:F0:49:68:95:68 is far easier to read, say aloud, and compare than its binary equivalent.

Nibble: 4 bits, 1 hex digit

Split every 8-bit octet exactly in half: 4 bits left, 4 bits right. Each 4-bit half is a nibble — a half-byte, small enough to memorize by sight.
One nibble always converts to exactly one hex digit. An octet, having exactly two nibbles, converts to exactly two hex digits — always two, never more, never fewer.
Digits 0-9 mean what they always mean. Once a nibble's value passes 9 the digits switch to letters: A=10, B=11, C=12, D=13, E=14, F=15 — the highest four bits can reach (1111, all on) is 15, exactly F.

The 0x tag

Written alone, a hex value like B2 could be misread as a word. The prefix 0x is a label meaning "everything after this is hexadecimal" — it changes nothing about the value, it only prevents confusion.
You'll see it constantly: 0xB2, 0x4B7C. Always read the characters after the x as hex digits, never as multiplication.

One octet, two nibbles, two hex digits: 1011 to B, 0010 to 2, together 0xB2.

Each landmark octet just switches on one more bit from the left.

Hex place weights multiply by 16 each step — 0x4B7C reads out to 19,324.

Worked example: decimal to hex, through binary

Convert 178 to hex the safe route: go through binary first. 178 = 128+32+16+2, so in binary that's 1011 0010 (the space marks the two nibbles).
Convert each nibble on its own: 1011 = 8+2+1 = 11 = B. 0010 = 2 = 2. Put the two hex digits together in order: 0xB2.

Worked example: hex straight to decimal

Hex digit positions carry weights too, but they multiply by 16 instead of 2 — each position leftward is sixteen times bigger: 1, 16, 256, 4096.
Convert 0x4B7C: multiply each digit by its position's weight and add. 4×4096 + 11×256 + 7×16 + 12×1 = 16,384 + 2,816 + 112 + 12 = 19,324. (Remember B=11 and C=12 before multiplying.)

A first look at the landmark mask octets

Eight particular byte values come up over and over later in the course: 128, 192, 224, 240, 248, 252, 254, 255. For now just learn the shape they make in binary — their job arrives later.
Each one is the last one with one more 1 added, always filling in from the left: 128=10000000, 192=11000000, 224=11100000, 240=11110000, 248=11111000, 252=11111100, 254=11111110, 255=11111111.
The count of 1s climbs 1,2,3,4,5,6,7,8 — each landmark switches on the next switch in line, left to right, never skipping and never doubling back. (These become subnet masks in Phase 3 — for now, just recognize the pattern.)

All sixteen nibble values, binary to hex — 178's two nibbles (0010, 1011) shaded to match the split above.

A nibble is 4 bits and equals exactly one hex digit; an octet is exactly 2 hex digits, always.
Hex digits run 0-9 then A=10, B=11, C=12, D=13, E=14, F=15; the 0x prefix just labels a number as hex.
178 = 1011 0010 in binary = 0xB2 in hex; 0x4B7C = 4×4096+11×256+7×16+12 = 19,324.
The landmark octets 128,192,224,240,248,252,254,255 each switch on one more bit from the left — the pattern behind every subnet mask ahead.

Hex changes nothing about the bits — it just gives your eyes a shorter word to read.

Phase 1 · The big picture

"What a Network Really Is" (Phase 1 · page 1/3)

Two Friends, a Note, and the Rules That Make It Land

Five components, one note passed between friends

Data communication is the exchange of data between two devices over some transmission medium — and underneath every wire or radio signal, it is really just two friends in a classroom passing a note.
Message — whatever is written on the note: text, numbers, a picture, audio, video, anything worth saying. Sender — the friend who writes it and passes it on. Receiver — the friend who unfolds it and reads it.
Medium — however the note actually travels: hand to hand along paired copper wires (twisted pair), sealed inside a shielded copper tube (coax), as a flash of light down a glass strand (fiber), or shouted across the room as radio waves.
Protocol — the rules both friends already share before the note ever moves: same language, same speed, same signal for "your turn." Skip this and the note still physically arrives, but nothing is understood — the two are connected but not communicating, like an Arabic speaker and a Japanese speaker sharing a room, hearing each other perfectly, and learning nothing.

Delivery, on time, unchanged, evenly spaced

Sending a note is worthless unless it lands well — four separate ways to judge that landing.
Delivery: it reaches the right friend, not the one two seats over. Accuracy: the words arrive unchanged, not smudged into something else.
Timeliness: it arrives on time — a punchline delivered a week late has stopped being a joke.
Low jitter: even spacing between packets (jitter = variation in how long each packet takes to arrive). It is why a video call can stutter even when the average speed looks perfectly fine — the packets are not late on average, just unevenly spaced apart.

Three traffic patterns, three streets

Simplex — one direction only, ever, like a one-way street. Example: a keyboard sending to a computer, or a computer sending to a monitor; the reverse trip never happens.
Half-duplex — both directions are possible, but only one at a time, like a single-lane bridge. Example: walkie-talkies — say "over" and let go of the button before the other side can answer.
Full-duplex — both directions at once, like an ordinary two-way street. Example: a telephone call, or a modern switched Ethernet link, where talking and listening happen simultaneously.

Judging a network: three report-card categories

Reliability — how rarely the network fails, and how fast it recovers when it does.
Security — protecting data from unauthorized access and damage, plus having an actual recovery plan for when something still goes wrong.
Performance is the category that trips people up, because four similar-sounding words hide inside it — worth its own close look, just below.

The five components: a note, passed only if the rules match

One pipe, three gauges: 100 promised, 74 delivered, 68 useful

Simplex, half-duplex, full-duplex — three streets for one link

Four performance words, one water pipe

Picture a water pipe running from a tank to your glass. Bandwidth is the width of the pipe — the theoretical capacity, how many bits could cross per second. Throughput is the water actually flowing — how many bits really cross per second, measured, not promised.
Goodput is only the water that reaches your glass — throughput with headers and retransmissions (repeated re-sends of anything lost) filtered out, counting only useful application data. Latency / delay is the length of the pipe itself — how long the data takes to travel from A to B.
These stack in one fixed order, always: bandwidth ≥ throughput ≥ goodput. Worked example: an ISP sells "100 Mbps" (bandwidth), a download actually runs at 74 Mbps (throughput), and only 68 Mbps of that is real file content (goodput) — three different numbers answering three different questions.
The tension worth remembering: pushing more traffic into a network to chase higher throughput builds up queues, and queues increase delay — so high throughput and low latency pull against each other under load. (Careful: some slides call this "two contradictory metrics" and then list four — the truly contradictory pair is throughput vs. delay; bandwidth and goodput are just refinements of throughput, not separate contestants.)

Same average speed, different feel — uneven spacing is jitter

Five components of data communication: message, sender, receiver, medium, protocol — no protocol means connected but not communicating.
Half-duplex = one direction at a time (walkie-talkies); full-duplex = both directions at once (phone calls, modern switched Ethernet).
Bandwidth ≥ throughput ≥ goodput, always — width of the pipe, water actually flowing, water that reaches the glass.
The real contradictory pair under load is throughput vs. delay: chasing more throughput builds queues, and queues raise delay.

A wide pipe can still leave you thirsty.

"Shapes, Sizes & Rulebooks" (Phase 1 · page 2/3)

One Link, Four Shapes, and the Rules That Hold It All Together

Links and topologies: how devices are wired together

A link connects devices one of two ways: point-to-point, a dedicated link between exactly two devices with full capacity reserved for them — like a TV remote talking to one TV — or multipoint, where more than two devices share the one link, splitting capacity either in space (all present at once, smaller slices each) or in time (each gets the whole link, just not simultaneously).
The physical topology is the geometric layout of those links and nodes, where a node is any connected device — a computer, a switch, a router. Four classic shapes cover almost everything.

Four topologies, four trade-offs

Mesh (every pair directly linked): no traffic sharing, robust, private, faults easy to isolate — but cabling and ports explode in cost, so it survives only inside small backbones.
Star (everyone wired to one central device): cheap, easy to install and reconfigure, one bad cable only knocks out one node — but the center is a single point of failure (kill it, everything dies). Today's LAN standard, with a switch at the center.
Bus (one shared backbone cable): least cable, easiest first install — but hard to add to or troubleshoot, and a single break kills the whole segment while reflecting noise both directions. Historic — early Ethernet.
Ring (each node wired to its two neighbors): easy install, simple fault isolation — but traffic flows one direction only, and one broken device can disable the loop. Historic — Token Ring. Real networks often mix these as a hybrid, e.g. a star backbone with bus branches.

The mesh math, worked

Mesh cost is not a feeling, it is a formula: with n devices, links needed = n(n−1)/2, and each device needs n−1 ports.
Worked example: 8 devices → links = 8×7/2 = 28; ports per device = 8−1 = 7.
That is a lot of cabling for just eight machines — exactly why mesh survives only as a small, private backbone (linking a few core routers, say) and never as the way to wire a whole office of laptops.

LAN, MAN, WAN — and the internet vs. the Internet

LAN: privately owned, confined to one office, building, or campus — a few kilometers at most — built so local devices can share resources.
MAN: the in-between size, a whole town or city — e.g. a phone company's DSL (broadband over ordinary phone lines) across a city. WAN: long distance — country, continent, or the world — running over leased lines (dedicated, rented telecom circuits) and the internet backbone.
Connect two or more networks and the result is an internetwork, nicknamed "internet" with a small i. The Internet, capital I, is the one famous internetwork: hundreds of thousands of networks joined by ISPs (Internet Service Providers, the companies that sell access), arranged in tiers — international, national, regional, local — meeting at exchange points (facilities where rival ISPs' networks physically interconnect).

The four base topologies — same four nodes, four different bets

From one DoD project to two protocols, in four steps

Three sizes, one nested truth — WAN contains MAN contains LAN

A short history worth knowing cold

Mid-1960s: ARPA (the US Department of Defense's Advanced Research Projects Agency) wants a way to connect research mainframes together.
1969: ARPANET (ARPA's own network, the Internet's direct ancestor) goes live, with four university nodes talking to each other through IMPs (Interface Message Processors, the first router-like boxes).
1972: Vint Cerf and Bob Kahn invent a single protocol called TCP, which later splits into two — TCP and IP (Transmission Control Protocol and Internet Protocol) — the two protocols this course orbits.

Protocols, and the standards that make them shared

A protocol is a set of rules governing communication: what is communicated, how, and when. Every protocol has three elements: syntax (the structure or format of the data — e.g. "the first 8 bits are the sender's address"), semantics (what each part actually means — is that address the next hop, or the final destination?), and timing (when to send, and how fast — a 100 Mbps sender will drown a 1 Mbps receiver).
Standards are agreed-upon rules that make an open, interoperable market possible. De facto ("in fact") standards are adopted just through widespread use, no official blessing needed — Ethernet started this way, as the DEC-Intel-Xerox "DIX" standard. De jure ("by law") standards are ratified by a recognized body — ISO, ITU-T, ANSI, IEEE, EIA, official organizations that publish technical rulebooks — and Ethernet eventually became de jure too, as IEEE 802.3.
Internet standards are born as an Internet Draft (a 6-month working document), then published as an RFC (Request for Comments) — numbered and public. When this guide cites "RFC 791," that is the actual law defining IP.

Same four nodes, four different failure points (or none)

Point-to-point reserves a link's full capacity for exactly two devices; multipoint splits it, in space or in time, among more than two.
A full mesh of 8 devices needs 8×7/2 = 28 links and 7 ports per device — n(n−1)/2 links, n−1 ports, in general.
ARPANET went live in 1969 with four university nodes talking through IMPs; Cerf and Kahn's 1972 TCP later split into TCP and IP.
De facto standards come from widespread use (Ethernet's original DIX form); de jure ones are ratified by a body like IEEE (Ethernet became 802.3); Internet standards mature from an Internet Draft into a numbered, public RFC.

A shape decides the cabling bill. A rulebook decides if strangers can talk at all.

"Layers & the Nesting Envelopes" (Phase 1 · page 3/3)

Why We Divide the Job, and How Data Gets Wrapped for the Road

Why we bother layering at all

Building "a network" as one giant program would be impossible to design, debug, or upgrade — far too many moving parts tangled together in one place.
The fix is divide and conquer: split the job into layers, each one solving a single part of the problem, each offering a service to the layer above it and quietly using services from the layer below, through a clean interface (the agreed connection point between them).
Human version: a CEO dictates a letter (the application), a secretary formats it and seals it in an envelope (presentation/session), the mailroom addresses that envelope (network), and a courier drives it across town (link/physical). The CEO never learns or cares which road the courier takes.
The payoff: swap WiFi for a plain cable down at the bottom layer, and nothing above notices or has to change one line of its own work. That swappability is the whole reason to layer in the first place.

OSI's 7 vs. TCP/IP's 5 — a map, and the real machine

The OSI model (Open Systems Interconnection, published by ISO in 1984) has 7 layers. It is a reference model — a thinking map, not something actually running: almost nothing implements it exactly, but everyone still borrows its vocabulary.
The TCP/IP model (named after its two core protocols, Transmission Control Protocol and Internet Protocol) is the real machine — what the Internet actually runs on. This course draws it with 5 layers, collapsing OSI's top three (Application, Presentation, Session) into a single Application layer.
OSI, top to bottom: 7 Application (the user interface), 6 Presentation (translate, encrypt, compress), 5 Session (open, manage, end a dialog), 4 Transport (process to process), 3 Network (host to host, routing), 2 Data Link (node to node on one link), 1 Physical (bits on the medium).
TCP/IP's 5, same direction: Application (HTTP, DNS, FTP, SMTP), Transport (TCP, UDP), Network/Internet (IP, ICMP), Data Link (Ethernet, 802.11, ARP), Physical (cables, radio, signals).

The PDU ladder — one chunk, one name, one device

PDU stands for Protocol Data Unit — the name for "one chunk" of data at a given layer as it moves down the stack.
Memorize the column, top to bottom: data (L7, lives on clients and servers) → segment (L4, called a "datagram" specifically for UDP) → packet (L3, handled by routers and Layer-3 switches) → frame (L2, handled by switches, bridges, NICs) → bits (L1, carried by hubs, repeaters, plain cable).
Two memory hooks, bottom-up and top-down: "Please Do Not Throw Sausage Pizza Away," and "All People Seem To Need Data Processing."

Jobs in five words

L7 Application: what the user actually wants — URLs, email addresses; HTTP, DNS, FTP, SMTP. L4 Transport: process-to-process delivery and reliability — port numbers; TCP, UDP.
L3 Network: host-to-host delivery across networks, i.e. routing — IP addresses; IP, ICMP, RIP/OSPF.
L2 Data Link: node-to-node delivery on one link — MAC addresses; Ethernet 802.3, 802.11, ARP. L1 Physical: turning bits into signals on the medium — cabling specs, Manchester encoding (representing 1s and 0s as voltage transitions).

Same seven jobs, two ways to draw them, one PDU per row

Every lower layer grows wider — only L2 adds a trailer, sealed with the FCS

Five names, five devices — one journey, top to bottom

Encapsulation — nesting envelopes, one real example

Sending anything means each layer wraps whatever the layer above handed it with its own header — and, at Layer 2 only, also a trailer: a closing error-check field called the FCS (Frame Check Sequence, built from a CRC — cyclic redundancy check — explained fully in Phase 2), added after the data instead of before it.
Follow one FTP file transfer leaving a device, top to bottom: L7 — FTP header plus your file data ("data"). L4 — a TCP header wraps all of that ("segment"). L3 — an IP header wraps the segment ("packet"). L2 — an 802.3 header goes on the front and the FCS trailer goes on the very end ("frame"). L1 — the whole frame goes out the door as a raw stream of bits on the medium.
The receiver does the exact reverse, peeling off one header at a time as the data climbs back up the stack — that reverse trip is called de-encapsulation.

Three rules that carry through the rest of this course

(1) A frame carries a packet, which carries a segment — never the other way around; the nesting only ever runs in one direction.
(2) Each layer only ever reads its own header — Layer 3 never peeks inside the Layer 4 segment it happens to be carrying, and so on up the stack.
(3) A router unwraps a packet down to Layer 3, decides where it goes next, and then builds an entirely fresh Layer 2 frame around it for the next link — every single hop. Hold onto that third rule; it becomes the star of a much bigger scene in Phase 2.

The CEO never learns which road the courier takes

OSI has 7 layers (a reference thinking-map, published by ISO in 1984); TCP/IP is commonly drawn with 5, collapsing Application/Presentation/Session into one.
The PDU ladder, top to bottom: data → segment (datagram for UDP) → packet → frame → bits.
Encapsulation adds one header per layer (FTP→TCP→IP→802.3), plus a trailer — the FCS — only at Layer 2; de-encapsulation reverses the whole stack.
A router rebuilds a fresh Layer 2 frame at every single hop, right after unwrapping down to Layer 3.

Only the packet survives the whole trip — the frame around it is rebuilt at every hop.

Phase 2 · Ethernet & the link layer

"One Hop at a Time" (Phase 2 · page 1/4)

Every Link Gets Its Own Vehicle; the Cargo Never Changes

Layer 2's one job

Layer 2 (the data link layer) moves a datagram — the IP layer's packet, the parcel L2 is hired to carry for exactly one hop — from one node to the physically adjacent node, over a single link. Not across the world. Just this one hop.
Terminology: hosts and routers are nodes; the channels joining adjacent nodes are links; the L2 packet is a frame, and a frame encapsulates (wraps around) the L3 datagram riding inside it.
One datagram crossing the whole Internet might ride WiFi on the first link, fiber Ethernet on the next, then something else after that — a different link protocol every leg, the way one traveler goes taxi → plane → train on a single trip. Same passenger, new vehicle each leg.

The five things a link can promise

Framing — wrap the datagram in a header and trailer, adding the MAC addresses that name sender and receiver on this one link.
Link access — decide who may transmit when several nodes share one medium (the "MAC protocol" — its own page ahead).
Error detection — notice bits flipped by noise or attenuation (signal weakening over distance); usually just drop the bad frame.
Error correction — some links go further and fix the flipped bit outright, no retransmission needed.
Reliable delivery & flow control — saved for high-error links like wireless; rarely needed on clean wire, since TCP already handles reliability one layer up.

Where Layer 2 actually lives: the NIC

The NIC (network interface card) is where the link layer lives inside your machine — three things working together: hardware (the physical circuitry), firmware (software burned permanently into the card itself), and driver software (the operating system's translator for that specific card).
The NIC implements both the link layer and the physical layer beneath it — framing and addressing happen here, and so does turning bits into electrical signals, light, or radio waves.

LLC vs MAC — the corrected job split

LLC (Logical Link Control, upper half, IEEE 802.2) bridges the networking software above and the hardware below: its job is naming which L3 protocol rode inside the frame, plus offering optional flow/error services upward.
MAC (Media Access Control, lower half, part of IEEE 802.3) actually owns framing, MAC addressing, the FCS/CRC check, and media access — who talks and when.
Heads-up: some slide decks swap this a slide apart, crediting LLC with framing/addressing/CRC. That's backwards — those three belong to MAC; LLC only identifies the protocol and bridges software to hardware.

A datagram's trip: same cargo, a new frame and link protocol every leg

LLC names the protocol; MAC does the framing, addressing, and checking

the five link-layer services, top to bottom

Primer: what does a switch actually do?

A switch is the box a LAN's devices plug into. It learns which MAC address lives on which port by watching frames go by, building a forwarding table as it goes.
Once it knows where a MAC lives, it forwards a frame out only that one port — no shared shouting-medium, no chance of collision.
When it doesn't yet know the destination, or the frame is a broadcast, it floods: copies the frame out every port instead, and lets the right device recognize its own address.

L2 only carries one hop — like a relay runner, not the whole race

L2 moves a datagram exactly one hop, node to adjacent node over a single link — never further.
A frame is L2's packet; it encapsulates the L3 datagram, and each link on a path may use a completely different link protocol.
MAC, not LLC, owns framing, addressing, and the FCS check; LLC only names the L3 protocol and bridges software to hardware.
A switch learns MAC-to-port pairs from frames it observes, and floods only when the destination port isn't yet known.

One frame, one hop — the cargo rides on, the vehicle changes at every link.

"The Flat ID Number" (Phase 2 · page 2/4)

An ID Card Proves Who You Are, Not Where You Live

MAC anatomy — the address split in half

Every interface on a LAN carries a 48-bit MAC address ("physical address"), written as 12 hex digits in pairs, e.g. 6C:F0:49:68:95:68 — two hex digits make one octet, so six groups = six octets = 48 bits.
First 24 bits: the OUI (Organizationally Unique Identifier) — a vendor code assigned by IEEE. AA-00-00 was DEC's; 08-20-00 was Sun's.
Last 24 bits: a serial number the vendor assigns, unique to that one card.

A flat ID card, not a postal address

MAC addresses are flat — they carry zero location information, unlike a postal address that tells you where something currently sits.
The class analogy: a MAC is like a national ID number (unique to you, follows you anywhere); an IP address is like a postal address (says where you currently are).
That flatness is exactly why a MAC alone can never route a packet between networks — a router would have no way to know which direction to send it. Hold that thought; IP exists to fix it (Phase 3).

The I/G rule — the corrected test

Unicast — one specific NIC. Its I/G bit (the least-significant bit of the FIRST octet) is 0 — e.g. 02:00:00:00:00:00 or fe:fe:fe:fe:fe:fe.
Multicast — a group of NICs. I/G bit is 1, meaning the first octet's value is odd — e.g. 01:00:5E:… (IPv4 multicast) or 49:aa:bb:cc:dd:ee.
Broadcast — every NIC on the LAN, all 48 bits set to 1: FF:FF:FF:FF:FF:FF.
Nibble refresher: convert hex to binary one nibble (4 bits) at a time — 4 = 0100, 9 = 1001. So 0x49 = 01001001: last bit 1, odd, multicast — even though it doesn't "begin with" anything special (ignore any slide claiming unicast "begins 00" or broadcast "begins 11"; only the first octet's odd/even value matters).

Static vs. randomized MACs

The overwhelming majority of MAC addresses are static — burned in by the vendor at manufacture, uniqueness guaranteed by its IEEE-assigned OUI.
Dynamic/random assignment exists too: modern phones randomize their MAC address on every WiFi network they join, for privacy, by setting the "locally administered" bit instead of using the burned-in address.

The address splits OUI | Serial; the I/G bit hides in octet 1's last bit

Two worked octets, two different endings: 0xFE unicast, 0x49 multicast

even first octet = one device · odd = a group

Decoding Ethernet's old names

10Base5 = 10 Mbps, Baseband signaling (one signal owns the whole cable at a time — nothing shares its frequency), 500 m of thick coax cable, nicknamed "Thicknet."
10Base2 = thin coax; 10BaseT = twisted-pair copper; 100BaseT and 100BaseFX (fiber) follow the same pattern.
The rule: the prefix number is speed, "Base" always means baseband, and the suffix names the medium.

Ethernet's character

Ethernet is connectionless — no handshake between NICs before a frame goes out — and unreliable: no acknowledgments at Layer 2, so a frame that fails its CRC check is silently dropped, with any recovery left to TCP further up the stack.
Every speed jump — 10 Mbps to 100 Mbps ("Fast") to 1 Gbps to 10/40/100 Gbps — kept the exact same frame format, a big reason Ethernet outlived every rival (Token Ring, FDDI, AppleTalk's LANs).

first half = vendor code, second half = unique serial

A MAC address is 48 bits: 24-bit OUI (vendor) + 24-bit serial number, written as 12 hex digits.
The I/G bit is the least-significant bit of the FIRST octet only — odd value = multicast, even = unicast; all Fs = broadcast.
MAC addresses are flat (no location info), which is exactly why they can't route between networks — that's IP's job.
Ethernet is connectionless and unreliable at L2, but has kept one frame format across every speed from 10 Mbps to 100 Gbps.

An ID card proves who you are, not where to find you — that's the whole reason IP exists.

"The Envelope and the Shared Wire" (Phase 2 · page 3/4)

Every Byte on the Wire Earns Its Place

The frame, byte by byte — sync and addressing

Preamble — 8 bytes of alternating 1010… so sender and receiver clocks lock together; it is not counted as part of the frame's size. (The 802.3 variant splits this as 7 bytes of preamble plus a 1-byte SFD, 10101011, whose final 11 says "the frame starts now.")
Destination / Source MAC — 6 bytes each. A NIC accepts a frame only if the destination matches its own address, a group it joined, or broadcast; otherwise it discards the frame.

The frame, byte by byte — type, data, and the check

Type (Ethernet II, 2 bytes) — names which L3 protocol rides inside: 0x0800 IPv4, 0x0806 ARP, 0x86DD IPv6. Legacy 802.3 framing puts a Length here instead — the trick: values ≤ 1500 are lengths, values ≥ 0x0600 (1536) are types. One field, never both.
Data + padding — 46 to 1500 bytes; under 46, Ethernet pads it up. 1500 is the famous MTU (met again in Phase 3 fragmentation and Phase 4's MSS).
FCS — a 4-byte CRC-32 over the frame. Receiver recomputes it; a mismatch means silent drop, no apology.

Why the 64-byte minimum, exactly

Minimum frame = 6+6+2+46+4 = 64 bytes (preamble not counted).
That minimum is not arbitrary: it guarantees a station is still transmitting when a collision signal from the far end of the cable could arrive back — which is what makes collision detection possible at all. Everything about Ethernet's design traces back to CSMA/CD, below.

CSMA/CD — Ethernet's classic algorithm

CSMA = Carrier Sense Multiple Access: listen before transmitting; channel busy → defer, don't interrupt. /CD = Collision Detection: listen while transmitting too.
Idle → transmit the frame, ears still open. Collision heard mid-transmission → abort immediately (why waste the channel finishing a corpse?) and send a short jam signal so everyone notices.
Wait a random backoff, then retry — binary exponential backoff picks randomly from a window that doubles after each collision, so the network self-calms under load. It must be random, or the same two stations would just collide again on their very next try.

The frame strip: byte counts, and the 64-byte bracket that isn't arbitrary

Sense, transmit, and if collision hits — abort, jam, back off, retry

sense → wait if busy → send → back off randomly on a crash

CSMA/CA — why WiFi must avoid instead of detect

A radio can't hear a whisper of a collision while it's shouting — its own transmission drowns everything out. Worse, the hidden node problem means two senders may not hear each other at all; only the receiver caught between them hears the mess.
So 802.11 switches strategy from detect to avoid: wait when the channel is busy, back off before transmitting, collect link-level ACKs (per-frame "got it" confirmations), and optionally reserve the channel first with a tiny RTS/CTS (request-to-send / clear-to-send) exchange.

CD vs CA, side by side

Strategy — CD detects collisions after they start and aborts fast; CA avoids collisions before they ever happen.
Where — CD is wired, IEEE 802.3 Ethernet (legacy shared media); CA is wireless, IEEE 802.11 WiFi. Why there: on a wire, detection is cheap and reliable; in radio, it is essentially impossible.
Efficiency — CD is higher (recovers quickly); CA is lower, since it pays avoidance overhead on every single transmission.

the envelope: addresses, a "what's inside" tag, and a damage seal

Minimum Ethernet frame = 6+6+2+46+4 = 64 bytes (the 8-byte preamble isn't counted) — small enough that far-end collision news can still arrive while you're transmitting.
Type ≤ 1500 means the field is a Length (legacy 802.3); Type ≥ 0x0600 (1536) means it names the L3 protocol — one field, never both meanings at once.
CSMA/CD aborts the instant a collision is heard, jams the channel, then waits a RANDOM binary-exponential backoff before retrying.
CSMA/CA avoids collisions instead of detecting them, because a radio can't hear anything while transmitting — WiFi backs off first, then confirms delivery with ACKs.

Every byte on the wire earns its place — even the ones that only exist so a collision can still be heard.

"Catching Errors, Finding Neighbors, Crossing Networks" (Phase 2 · page 4/4)

From a Flipped Bit to a Packet's Whole Journey

Parity — detects, but only odd counts

Single-bit parity: append one bit so the total count of 1s is even (even parity) or odd (odd parity). Receiver counts the 1s; a wrong count means an error.
It detects any odd number of flipped bits, and can only detect, never fix — two flips at once slip through invisibly. (Some slides wrongly imply single-bit parity can also correct — that power belongs only to two-D parity, next.)

Two-D parity — the crosshair that fixes

Arrange the data as a grid, and compute a parity bit for every row and every column.
One flipped bit trips exactly one row's parity and one column's parity — their intersection locates the bad bit exactly, so you flip it back: detection and correction, no retransmission needed (worked grid alongside).

Internet checksum — two labeled steps

Used at the transport layer (UDP/TCP) but taught here as technique two: treat the data as a run of 16-bit integers.
Step (a) — add them all up with wraparound carries: any carry out of the top bit gets added back in ("one's-complement addition"). Step (b) — flip every bit of that total ("taking the complement"); the result is the checksum.
Receiver sums everything, checksum included: all 1s means "probably fine." Cheap and software-friendly, but weak — two errors can cancel each other out unnoticed.

CRC — XOR division, the heavyweight

Done in NIC hardware: Cyclic Redundancy Check treats the whole frame as one huge binary number and divides it by an agreed generator (a fixed bit pattern both ends already know) — that "division" is binary XOR division, not school long division — then appends the remainder.
Ethernet's FCS is a CRC-32: far stronger than parity or checksum, exactly why L2, where errors are born, relies on it.

Same flipped bit trips one row AND one column — the crosshair finds it

Frame 1 and Frame 2: MAC columns change, IP rows don't move at all

the golden rule: local MACs swap per hop, global IPs never move

ARP — gluing L3 names to L2 names

Your machine wants to send an IP packet to another address on its own LAN, but the Ethernet frame needs a destination MAC, and IP addresses say nothing about MACs. ARP (Address Resolution Protocol, RFC 826) answers exactly one question: "I know the IP — what's the MAC?"
Every IP node keeps an ARP table (cache) of <IP, MAC, TTL> mappings for nodes on its own subnet; entries expire (typically ~20 minutes) so stale hardware changes age out.
The request is a broadcast (dest FF:FF:FF:FF:FF:FF, Type 0x0806) riding directly inside an Ethernet frame with no IP header at all — a switch floods it out every port and every NIC interrupts its OS to check "is that my IP?" Routers never forward broadcasts: ARP stops dead at the subnet edge.
The reply is unicast straight back to the asker; only the IP's true owner answers, and if nobody does, the packet needing that MAC is simply dropped.

ARP's extra species, and its security hole

Gratuitous ARP announces your own mapping unasked, to detect IP conflicts. Proxy ARP is a router answering on behalf of someone else.
ARP spoofing/poisoning: ARP has zero authentication — anyone can claim "the gateway's IP is at MY MAC," and victims cache the lie and send traffic straight to the attacker (a man-in-the-middle). Mitigation lives in enterprise switches — Dynamic ARP Inspection, IP Source Guard — plus end-to-end encryption so intercepted traffic is useless anyway.

The finale: A → R → B, two networks

Host A already knows B's IP, knows its default gateway is router R (the gateway = the router on your own LAN that handles traffic bound for other networks), and knows R's MAC via ARP.
A addresses the frame not to B's MAC (A cannot ARP across a router) but to the default gateway's MAC, while the IP header keeps B as the true final destination the whole way.
R de-encapsulates to Layer 3, decides the exit interface, ARPs for B on the far side if needed, and re-encapsulates the same untouched packet inside a brand-new frame — see the strip alongside.

one broadcast question, one unicast answer, then remember it

Single-bit parity only detects (never fixes) odd numbers of flipped bits; two-D parity's row-times-column crosshair both detects AND corrects one flipped bit.
The Internet checksum is one's-complement addition (wraparound carries) followed by flipping every bit — cheap, but two errors can cancel out undetected.
CRC divides the frame by XOR (not school long division) against a shared generator; Ethernet's FCS is a CRC-32, the strongest of the three techniques.
ARP's request is a broadcast with no IP header at all (Type 0x0806); its reply is unicast; routers never forward the broadcast, so ARP never crosses a subnet boundary.

MAC addresses change at every hop; IP addresses ride the whole journey unchanged.

Phase 3 · The network layer — six chapters

3.1 · IP & its header

"The Postal Service That Promises Nothing" (3.1 · page 1/2)

MAC finds the wire; IP finds the world.

Why IP exists

A MAC address (the physical address burned into a network card) is a fingerprint: unique and permanent, but blind to location — it says nothing about which network a device sits on, so it is useless for reaching anywhere beyond the local wire.
An IP (Internet Protocol) address is a postal address instead: it has a network part (like a city) and a host part (like a house number on that city's street), and a router only has to read the network part to know which direction to send a packet.
This address is logical (assigned by software, not soldered into a chip) and hierarchical (network, then host) — the opposite of the MAC's flat, one-piece, burned-in identity.
Layer 3, the network layer, exists to solve exactly the problem Layer 2 cannot: moving a packet from one network to a completely different one.

The four jobs of IP

Address — give every end device a logical, hierarchical name it can be found by.
Encapsulate — wrap the Layer 4 segment (handed down from TCP or UDP) inside a packet, adding the IP header the way an envelope wraps a letter.
Route — carry that packet across networks, one hop at a time, until it reaches the right one.
De-encapsulate — at the destination, peel the envelope back off and hand the segment upstairs to the right protocol.

Three adjectives, three exam answers

Connectionless — no call is set up first; every packet is launched on its own and may take its own path to the destination. Why it's a feature: skipping the handshake lets data start moving immediately, with no round trip spent negotiating before the first byte goes anywhere. (Need an actual connection? That's TCP's job, one layer up.)
Best-effort (unreliable) — IP never acknowledges a packet and never retransmits one; when it drops a packet it always has a reason (a failed header checksum, a hop counter hitting zero), then moves on to the next packet, no apology attached. Why it's a feature: that laziness is the whole point — not tracking, confirming, or resending anything keeps IP's own overhead tiny, which is what lets every router on the path forward packets at wire speed.
Media independent — IP does not care whether the link underneath is copper, fiber, or radio; the only rule it must obey is that link's MTU (maximum transmission unit, the biggest frame the link allows — 1,500 bytes on Ethernet). Why it's a feature: one addressing and routing scheme can then ride on top of any physical technology, so the same packet crosses a fiber backbone and a wireless hop without changing shape.

The header drawn as a form — the compute-fields highlighted in yellow

IHL ÷4 mini worked example: two legal headers, one impossible one

A fingerprint identifies; a street address locates — that difference is why Layer 3 exists.

Header tour — the fields exams compute with

IHL (header length), the ÷4 rule. Four bits can only count from 0 to 15 — but that is exactly enough range if each unit stands for 4 bytes, since 15 × 4 = 60, the maximum header size allowed (20 bytes minimum, up to 40 bytes of options). Read the field and multiply by 4: 0101 = 5 → 20 bytes (no options attached). 0110 = 6 → 24 bytes (4 bytes of options). 0100 = 4 → 16 bytes — below the 20-byte minimum, which is impossible, so the packet is corrupt and the router drops it.
Total Length — header plus data together, in bytes. It is only a 16-bit field, so it can count no higher than 65,535 — the hard ceiling on any IPv4 packet's size. Data size works out to Total Length minus (IHL × 4).
TTL (time to live) — despite the name, a plain hop counter: every router that forwards the packet subtracts 1 from it. Hit 0 and the packet is destroyed on the spot, while the router that killed it sends back an ICMP (the network's error-and-echo system, covered fully in 3.4) Time Exceeded message, type 11, so the sender learns what happened. Its whole reason for existing: stop a lost packet from circling the network forever.
Protocol — the "what's inside" pointer that tells the receiving host which upper-layer protocol should get the payload: 6 = TCP, 17 = UDP, 1 = ICMP. It plays the same role at Layer 3 that the EtherType field (Ethernet's own what's-inside label) plays at Layer 2 — every layer needs some way to say what it is carrying.
Header Checksum — a corruption check computed over the header only, never the data. Every router along the path both verifies it and recomputes it from scratch, because the TTL it just decremented changed the header's contents. A mismatch means a silent drop, with no message sent back.
Type of Service, also labeled DSCP — bits that mark priority, giving routers a way to decide which packets deserve better treatment when a link is congested.

IP never retransmits: a dropped packet gets no apology, no resend, just silence.

IHL is stored as header length ÷ 4: 0101 unpacks to 20 bytes, the smallest legal header.
Total Length is only 16 bits wide, so 65,535 bytes is the largest an IPv4 packet can ever be.
Protocol 6 = TCP, 17 = UDP, 1 = ICMP — the field that says what is riding inside, IP's version of EtherType.
IP is connectionless, best-effort, and media independent — three separate design choices that all trade guarantees for speed.

IP drops the packet, offers no apology, and moves on to the next one — the silence is the speed.

"The Couch and the Doorway" (3.1 · page 2/2)

When the packet is bigger than the doorway, you cut it — carefully.

Why packets get cut

Think of a link's MTU (maximum transmission unit) as a doorway: 1,500 bytes is literally the widest thing that can pass through an Ethernet doorway in one trip.
If the couch — the packet — is bigger than the doorway, you do not force it through; you cut it into pieces that each fit, and carry them through one at a time. IPv4 calls this fragmentation.
Any router along the path can fragment a packet if the next link's MTU is smaller than the packet itself.
Each fragment becomes its own independent IP packet with its own full 20-byte header, but every fragment carries marks that let the destination recognize which pieces belong together and put them back in order.

The fragmentation trio

Identification — copied identically onto every fragment cut from the same original packet, the way movers write "crate 482, piece 3 of 5" on furniture, so the destination knows which pieces belong to which packet.
Flags — three bits: the first is reserved and always 0; bit D (don't-fragment) forbids cutting the packet at all; bit M (more-fragments) says there is another piece coming after this one.
Fragment Offset, the ×8 rule. This field is only 13 bits wide, which alone could count no higher than 8,191 — nowhere near enough to point anywhere across a packet as large as 65,535 bytes. So the field secretly counts in units of 8 bytes instead of 1: 8,191 × 8 = 65,528, just enough to reach the far end of the largest legal packet. Multiply the stored number by 8 to get the real byte position.

One packet, cut into three fragments — offsets and M flags labeled

Reading a fragment cold: two questions, two teaser cases

IHL ×4 and Fragment Offset ×8 are the same trick, played twice, matched to field size.

The worked ritual — cutting a 4,020-byte packet

Setup. A 4,020-byte packet (20-byte header plus 4,000 bytes of data) must cross an Ethernet link whose MTU is 1,500 bytes. Maximum data per fragment = 1,500 − 20 = 1,480 bytes (every fragment needs room for its own 20-byte header).
Fragment 1 — carries data bytes 0 to 1,479 (1,480 bytes). Offset = 0 ÷ 8 = 0. M = 1 (more fragments follow).
Fragment 2 — carries data bytes 1,480 to 2,959 (1,480 bytes). Offset = 1,480 ÷ 8 = 185. M = 1 (more fragments follow).
Fragment 3 — carries data bytes 2,960 to 3,999 (1,040 bytes). Offset = 2,960 ÷ 8 = 370. M = 0 — this is the last piece.
All three fragments carry the same Identification number, and each one gets its own complete 20-byte header.

Reading a fragment cold, and where the couch gets rebuilt

A packet with M = 0 and Offset = 0 was never fragmented at all — it is whole, complete in one piece.
A packet with M = 0 and Offset = 5 is the last fragment of a set, and its data begins at byte 5 × 8 = 40 of the original.
Reassembly happens only at the final destination, never partway. Fragments from the same packet may travel different roads through the network and arrive at different routers at different times, so no router in the middle could ever be sure it has seen every piece.
Memory hook: IHL ×4 and Offset ×8 are the same trick played twice — a small field forced to describe a number far bigger than it could count to alone. Match the multiplier to the field's size: the tiny 4-bit IHL gets the small ×4; the bigger 13-bit Offset gets the bigger ×8. (Looking ahead to 3.6: IPv6 routers never fragment at all — the source host must size its packets to fit before sending.)

Same packet, three trips through the doorway — sizes, offsets (×8), and M-flags all labeled.

Every fragment cut from the same packet carries the same Identification number — that is the destination's sorting label.
Fragment Offset counts in units of 8 bytes: multiply the stored value by 8 to get the real byte position.
M = 0 means nothing follows this piece — either it is the last fragment, or the packet was never split in the first place.
Reassembly happens only at the final destination, since fragments may travel different roads and no router in between can be sure it has seen them all.

Cut the couch to fit the doorway, label every piece the same way, and let only the last room put it back together.

3.2 · IPv4 addressing

"Streets and Stencils" (3.2 · page 1/2)

Where the Street Name Ends and the House Number Begins

An address is a street address

An IPv4 address is 32 bits, written as four decimal octets (8-bit groups) separated by dots: 117.149.29.234 = 01110101.10010101.00011101.11101010.
That is 2³² ≈ 4.3 billion possible addresses — it sounded infinite back in 1981 and ran out in our lifetime, which is the whole reason NAT and IPv6 exist.
Every address secretly has two parts: a network portion (which street) and a host portion (which house on that street) — think "24 Elm Street": Elm Street is the network, 24 is the host.
The split point is invisible in the 32 bits themselves — nothing about the address alone says where street ends and house begins. A companion number, the mask, is what declares it.

The mask is a stencil you lay on top

The network mask is 32 bits: a run of 1s then a run of 0s. A 1 means "this bit belongs to the street name," a 0 means "this bit belongs to the house number."
Written two ways: dotted like 255.255.255.0, or as a slash/CIDR prefix like /24 (plain words: "24 ones in a row, then zeros").
To read off the street name, bitwise-AND the address with the mask: 1 AND x = x (the bit survives), 0 AND x = 0 (the bit is wiped). Lay the stencil down, keep whatever shows through its holes, blank out the rest.
Rehearsed twice in the source, same rule on different digits: 192.168.100.23 /24 → 192.168.100.0, and 192.240.33.91 /24 → 192.240.33.0. Both times only the last octet — the house part — got wiped to zero.

The /24 stencil laid over the address: 1-bits let the network octets pass, 0-bits wipe the host octet to zero. Same rule, uglier numbers: 192.240.33.91 /24 → 192.240.33.0.

The four landmarks of 192.168.100.0/24 — the bookends (.0 network, .255 broadcast) are never handed to a device.

Zoom out from octets: the same AND rule works on the address as one 32-bit bar.

Four landmarks every street has

Network address — all house bits = 0. This is the street's own name sign, not a house anyone lives in, so it is never handed to a device.
First usable host = network address + 1 (by convention, often given to the gateway — the router that connects that street to everywhere else).
Last usable host = broadcast address − 1.
Directed broadcast — all house bits = 1. The megaphone address: send to it and every house on that one street hears it at once. Not assignable either.

Why the formula subtracts two

Usable hosts = 2^h − 2, where h = number of host bits. The minus two is not a rounding fudge — it removes exactly the two bookend addresses above: all-zeros (the street sign) and all-ones (the megaphone).
For /24, 8 bits are left for hosts: 2⁸ − 2 = 254 usable addresses. On 192.168.100.0/24 that runs .1 through .254.
Remember the shape of this formula, not just the /24 case — it gets reused constantly once subnetting starts slicing host bits into smaller pieces.

To true scale: the network and broadcast addresses are practically twins with .1 and .254.

192.168.100.23 /24 → AND with the mask → network 192.168.100.0
192.240.33.91 /24 → same stencil, same rule → network 192.240.33.0
Four landmarks per network: network (all-0), first usable (net + 1), last usable (broadcast − 1), directed broadcast (all-1)
Usable hosts = 2^h − 2; for /24, 2⁸ − 2 = 254

A mask does not draw the line between street and house — it just tells you where the line already was.

"Classes, Relics & Reserved Streets" (3.2 · page 2/2)

Old Rules, Lingering Traps, and the Addresses Nobody Should Mix Up

Classful addressing — the history you still need

Before masks were flexible (pre-1993), the first bits of an address hard-wired its class, and the class hard-wired a default mask — no choice, no in-between sizes.
Class A: first octet 1–126, mask 255.0.0.0 = /8. 0 is reserved and all of 127.0.0.0/8 is loopback (this page's next topic), so only 126 networks are truly usable — not 127, not 128.
Class B: first octet 128–191, mask /16, giving 65,534 hosts per network (2¹⁶ − 2).
Class C: first octet 192–223, mask /24, giving 254 hosts per network (2⁸ − 2) — the same 254 from page one.
Class D (224–239) is multicast — group addresses only, no mask, no hosts. Class E (240–255) is reserved/experimental — never assigned to anyone.

Why classful addressing had to die

Picture a company that needs 300 host addresses. Class C only offers 254 — not enough. The next size up on the classful shelf is Class B: 65,534 addresses, whether the company needs 300 or 65,000.
That hands over roughly 65,234 addresses nobody else can ever use, repeated across every company caught between sizes. Multiplied across thousands of companies, the whole address space bleeds out for nothing.
That exact waste is why CIDR (Classless Inter-Domain Routing) replaced fixed classes with masks of any length, sized to what is actually needed instead of a fixed shelf size — the subject of the next section.

Instant recognition, no math required

Read the class straight off the first octet: below 128 → A. 128–191 → B. 192–223 → C. 224–239 → D. 240–255 → E.
Six landmark numbers worth memorizing cold: 126 | 128 | 191 | 192 | 223 | 224 — exactly where each class ends and the next begins (127 sits carved out between A and B, reserved for loopback).
Even faster in binary — count the leading 1-bits before the first 0: none → A (starts 0…), one → B (10…), two → C (110…), three → D (1110…).

Class boundaries by first octet — the six landmarks to memorize: 126 | 128 | 191 | 192 | 223 | 224.

The fixed bits (red) are the class; everything after the first 0 is free (x).

Special addresses, in plain words

127.0.0.1 (really, the whole 127.0.0.0/8 block) is loopback — anything sent there loops straight back inside the machine and never reaches the NIC (network interface card, the physical hardware). It tests the TCP/IP stack — the layered networking software running top to bottom — not the card.
The real NIC test needs two pings: loopback first (if that works, the software stack is healthy), then the machine's own real IP. Loopback succeeding and the real IP failing is the gap that implicates the NIC — that time the packet actually had to go out through the card, and did not come back.
169.254.0.0/16 is APIPA — a host self-assigns an address here only when it asked DHCP for one and got no answer. Seeing 169.254.x.x on a machine translates to one sentence: "my DHCP failed."
RFC 1918 sets aside three private ranges, free for anyone's internal network but not routable on the public Internet: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. The fence on the middle one is narrow — only 172.16 through 172.31; 172.168.x.x looks similar but sits outside the fence and is a public, routable address.

Multicast, broadcast, and who is allowed to send

224.0.0.0–239.255.255.255 (Class D) is multicast — a destination-only address naming a group of listeners, never handed out as one device's own address. Routing protocols lean on them: RIPv2 announces its updates to 224.0.0.9 (a common typo swaps the first digit to 244 — but 244.x is reserved Class E space, not a real multicast address).
255.255.255.255 is the limited broadcast — every host on the local network hears it, and routers never forward it past that network. Contrast with the earlier directed broadcast (host-bits-all-1 for one specific network, like 192.168.100.255): that one is per-network, this one is always local-only.
Three delivery types live at this layer: unicast (one device to one device — can be either a source or destination address), multicast (one device to a group — destination only), broadcast (one device to everyone on the network — destination only). Broadcasts are never routable; they die at the first router, exactly like ARP did at the link layer.

Loopback succeeding but your real IP failing is the one result that points at the NIC — every other outcome points at the stack, or further upstream.

Four shapes worth memorizing cold — mix up the ranges and you'll misdiagnose the network.

Class A usable range is 1–126, not 1–127: 0 is reserved and all of 127.0.0.0/8 is loopback
172.16.0.0–172.31.255.255 is the private range; 172.168.x.x looks similar but is public
RIPv2 announces to 224.0.0.9 (not 244.0.0.9 — that first digit is a common typo)
Loopback tests the stack, not the NIC; loopback working while your own real IP fails is what implicates the NIC

A class used to be an address's destiny — now a mask decides it, house by house.

3.3 · Subnetting, CIDR & VLSM

"Slicing the Cake" (3.3 · page 1/3)

Same Batter, More Slices — One Move Does It All

Why cut the cake at all

A broadcast domain (unpack: the whole set of devices that hear every broadcast any one of them sends) is the cake before it's cut. One flat network of 1,000 machines means every single broadcast — like an ARP request, the "who has this address" shout used to find a MAC address — interrupts all 1,000 of them, whether they care or not.
Routers are the walls between rooms: they never forward broadcasts. Cutting one network into smaller subnets (sub-networks — smaller address blocks carved from one larger block) with a router between each pair shrinks every broadcast domain, which is the performance win.
Smaller rooms also let you group addresses by department, floor, or function (organization), and let you post rules at the doorway between rooms, since a router sitting between two subnets is a natural checkpoint to filter or inspect traffic (security). Right-sized rooms also waste fewer addresses than one giant room built for a headcount nobody has.
None of this is free: the price is that routers now have to do real work — actively routing packets between all the pieces that used to be one piece.

The one move behind every subnet

Every address block already splits into a network portion (fixed, shared by the whole block) and a host portion (free to vary, one value per device). Subnetting is a single trick wearing many costumes: take some bits that used to be free host bits and hand them to the network side instead — in plain words, extend the mask to the right. The borrowed bits get a new name: subnet bits.
Straight from the guide: 192.168.10.0/24 starts with 8 free host bits. Borrow 2 of them and the mask becomes /26 — only 6 host bits remain free, and the 2 borrowed bits are now subnet bits.
Each single borrowed bit does two things at once: it doubles how many pieces (subnets) exist, and halves how many addresses live inside each piece. Borrow 2 bits from that block and you get four subnets of 62 hosts each instead of one network of 254.
The cake never grows. The total number of addresses in the block is exactly the same before and after — subnetting only changes how the existing addresses are grouped, never how many exist.

The two formulas — memorize as a pair

2^b = number of subnets created, where b = bits borrowed. 2^h − 2 = usable hosts per subnet, where h = host bits left after borrowing. The −2 pays for two addresses every single subnet must sacrifice: its own network address and its own broadcast address.
Values worth having cold, since they recur constantly: h=6 → 62 hosts, h=7 → 126 hosts, h=8 → 254 hosts.
Two directions the exam asks from, same machinery either way: "I need N subnets" → borrow the smallest b where 2^b ≥ N. "I need N hosts per subnet" → keep the smallest h where 2^h − 2 ≥ N, then borrowed = (old host bits) − h.

The magic number — subnet math without binary

Once the new mask is chosen, find the interesting octet — the one octet (8-bit group, one of the four dotted numbers) where the mask value is neither 255 nor 0, the octet where the borrowing actually landed.
Magic number = 256 − (mask's value in that interesting octet). That number is also the slice width — the size of every piece. Subnets always start at multiples of it: 0, magic, 2×magic, 3×magic, and so on.
Each subnet's broadcast is always the next subnet's start minus 1 — the last address before the next room begins. Worked check: mask octet 192 (a /26) gives magic = 256 − 192 = 64; starts at .0/.64/.128/.192, broadcasts at .63/.127/.191/.255.
The same landmark octets from earlier keep their old faces but get a new job: 128↔128, 192↔64, 224↔32, 240↔16, 248↔8, 252↔4, 254↔2 (mask octet ↔ magic number).

192.168.10.0 sliced three ways: /24 whole, /25 halved, /26 quartered.

Four /26 rooms on one ruler — starts and broadcasts, no binary required.

Mask octet ↔ magic number — the same seven digits keep recurring.

Cutting the cake shrinks broadcast domains — routers never forward broadcasts.

A broadcast domain is bounded by routers — routers never forward broadcasts, so more subnets means smaller, quieter broadcast domains.
Subnetting is one move: borrow host bits, extend the mask right. The cake (total addresses) never grows — only the cuts change.
2^b = subnets created · 2^h − 2 = usable hosts per subnet — the −2 pays for each subnet's own network and broadcast address.
Magic number = 256 − mask value in the interesting octet. Subnets start at its multiples; each broadcast is the next start minus 1.

A subnet mask never grows the cake — it only decides how many rooms get a slice.

"The Worked Rituals" (3.3 · page 2/3)

The Guide's Own Examples, Rebuilt in Plain Words

Splitting one /24 — first in two, then in four

Split 192.168.10.0/24 into two: borrow 1 bit → /25, mask 255.255.255.128, host bits left h=7 → 2⁷−2=126 hosts each. Interesting octet is the 4th; magic = 256−128=128 → subnets start at .0 and .128. Subnet 1: hosts .1–.126, broadcast .127. Subnet 2: hosts .129–.254, broadcast .255.
Split 192.168.4.0/24 into four: borrow 2 bits → /26, mask 255.255.255.192, h=6 → 62 hosts each. Magic = 256−192=64 → starts at .0/.64/.128/.192, broadcasts at .63/.127/.191/.255.
Spot-check with binary: .63 is 00111111. Read the first 2 bits as subnet bits (00 — the first subnet) and the remaining 6 as host bits (all 1s — exactly the definition of a broadcast: host portion all-ones). The magic-number shortcut and raw binary always agree; the shortcut is just faster.

The dual-constraint problem — satisfy both at once

Straight from the guide: network 192.168.15.0, need at least 50 hosts per subnet AND at least 4 subnets — two separate constraints that the one answer must satisfy simultaneously.
Hosts side: need 2^h−2 ≥ 50. h=5 gives 30 (too small); h=6 gives 62 (enough) — so h=6 is the smallest h that clears the host bar.
Subnets side: borrowing 8−6=2 bits gives 2²=4 subnets — exactly clears the "at least 4" bar too. Both constraints happen to land on the same split here, but always check both sides separately — nothing guarantees they agree on every problem; take whichever h satisfies both.
Answer: mask /26 = 255.255.255.192, four subnets at .0/.64/.128/.192, 62 usable hosts in each.

Subnetting a Class B — when the interesting octet moves

Guide's example: 142.14.0.0/16 needs 16 subnets. Borrow 4 bits → /20 = 255.255.240.0. Host bits left h=12 → 2¹²−2=4,094 hosts each.
Here the interesting octet is the 3rd, not the 4th — a /16 already used the first two whole octets for the network, so this 4-bit borrow lands inside octet 3 instead. Magic = 256−240=16 → subnets start at 142.14.0.0, 142.14.16.0, 142.14.32.0 … up to 142.14.240.0.
Take the second subnet, 142.14.16.0: hosts run 142.14.16.1 all the way to 142.14.31.254, broadcast 142.14.31.255. The range spills entirely across the 4th octet — normal and expected whenever the interesting octet isn't the last one, since the whole 4th octet now sits inside the host portion and just cycles through its full 0–255 range while the 3rd octet climbs from 16 to 31.

Class A at true scale, and the .0 trap

Class A example: 10.0.0.0/8, need 200–225 hosts per subnet. Hosts side: 2^h−2 ≥ 225 needs h=8 (254, enough) → mask = /24 = 255.255.255.0. Borrowed = 24−8=16 bits → 2¹⁶ = 65,536 subnets: 10.0.0.0, 10.0.1.0, 10.0.2.0 … through 10.255.255.0. One private Class A block comfortably numbers a corporation of tens of thousands of LANs.
The .0 trap: 142.14.33.0/20 is a legal, valid host address. The rule people misremember as "addresses ending in .0 are forbidden" is wrong — the real rule is host-portion-all-zeros is forbidden, because that is what makes an address a network/subnet name rather than a device.
With /20 the interesting octet is the 3rd; 32 is a multiple of magic 16, so 142.14.32.0 is a subnet boundary — its entire host portion is zero, illegal as a host. 142.14.33.0 sits one step inside that same subnet: its host portion is not all-zeros, so despite also ending in ".0" in the last octet, it is a perfectly valid host.

The 3rd-octet spillover strip — landmarks of 142.14.16.0/20.

Same last octet, opposite verdicts: boundary (illegal) vs. inside (valid).

Boundary math for one host — .137 sits inside the third /26 block.

Two thresholds, one answer — the host bar and the subnet bar must both pass.

192.168.10.0/24 split in two = /25: .0 and .128, 126 hosts each. Split in four = /26: 62 hosts each, boundaries .0/.64/.128/.192.
.63 in binary is 00111111 — subnet bits 00, host bits all-ones — exactly what a broadcast address is; the shortcut and raw binary always agree.
142.14.0.0/16 borrowed to /20: the interesting octet is the 3rd (not the 4th), magic 16; a host range can legitimately spill across the whole 4th octet.
The real rule is host-portion-all-zeros, never literally "ends in .0" — 142.14.33.0 is a fully valid host even though its last octet is 0.

Ending in .0 was never the crime — an all-zero host portion is.

"Unequal Slices & the Outward Slash" (3.3 · page 3/3)

Custom-Cut Slices, and Turning the Slash the Other Way

Legacy rules vs. modern truth

The deck's own "Rules for subnets" slide claims: subnet count must be a power of 2, every subnet must be equal size, and /30 is supposedly the largest usable mask. Those are the rules of classful FLSM only — Fixed-Length Subnet Masking, where every subnet cut from one parent block is forced to be the same size.
Modern truth, piece by piece: powers of 2 happen automatically the instant you borrow whole bits, so that was never really a separate rule — just arithmetic. Equal sizes are optional, not mandatory: VLSM (this page's main event) makes unequal sizes the entire point, on purpose.
Beyond /30, two more masks exist. /31 (RFC 3021) is the standard mask for a router-to-router link — a point-to-point connection between exactly two interfaces, nobody else. The normal formula gives 2¹−2=0 usable hosts, but RFC 3021 grants a special exception: both addresses are usable, no network or broadcast address reserved, since a link with only two possible members never needs to broadcast to a group.
/32 is a host route: 0 host bits, matching exactly one single address — used when a router must point at one specific device, not a range.

CIDR: one slash, two directions

CIDR — Classless Inter-Domain Routing (1993) — made the prefix length (the slash number) explicit and free to take any value, not locked to a class's fixed default. An ISP can hand out 203.0.113.0/23 (two Class-C-sized blocks fused into one, 510 hosts) with no class implied at all.
Pointed inward (a longer prefix, more 1-bits) is subnetting — cutting one block into smaller pieces. Pointed outward (a shorter prefix, fewer 1-bits) is supernetting, also called route aggregation — gluing several same-sized blocks back into one bigger announcement.
A router advertising 172.16.0.0/16 replaces 256 separate /24 routes with a single line — this is what keeps the Internet's routing tables from growing without bound. One slash, two directions.
Worked example: 8 consecutive /24 blocks, 200.10.0.0/24 through 200.10.7.0/24, aggregate into one /21. The borrow formula runs backward: 8 = 2³, so shorten the prefix by 3 bits (24−3=21) — legal only because of the alignment requirement: a block may only start at an address that is a multiple of its own size, and 200.10.0.0 is a multiple of 8 in the relevant octet.

VLSM's ritual, in strict order

VLSM — Variable-Length Subnet Masking — drops FLSM's equal-sizes straitjacket: carve each department a block sized to what it actually needs, all from the same parent block. The algorithm is rigid on purpose; skipping a step or doing them out of order breaks the result.
Step 1 — sort every demand largest-first. This exists because of the alignment rule above: a block of N addresses may only start at a multiple of N — a /26's 64-address block can only begin at .0, .64, .128, or .192. Plant a small block first and it can land mid-boundary, leaving a gap no big block can legally use afterward.
Step 2 — for each demand, in that sorted order, pick the smallest mask that fits: the smallest h where 2^h−2 ≥ the need. Step 3 — allocate that block starting at the next free boundary, which is always the previous subnet's broadcast address + 1.
Step 4 — repeat for every remaining demand. Whatever addresses are left over at the end become the growth reserve — spare capacity banked for later.

The full worked plan on 192.168.10.0/24

Four demands, already sorted largest-first: Sales 100 hosts, Engineering 50, Operations 25, one WAN link (router-to-router, 2 addresses).
Sales needs 100 → h=7 (126 usable) → /25, placed at 192.168.10.0: hosts .1–.126, broadcast .127. Engineering needs 50 → h=6 (62 usable) → /26, placed at the next free boundary 192.168.10.128: hosts .129–.190, broadcast .191.
Operations needs 25 → h=5 (30 usable) → /27, placed at 192.168.10.192: hosts .193–.222, broadcast .223. WAN link needs 2 → /30, placed at 192.168.10.224: hosts .225–.226, broadcast .227. What remains, .228–.255, is 28 addresses banked in reserve.
FLSM would have forced all four into equal /26 blocks (62 hosts max) — Sales' 100-host need simply does not fit at all, and the WAN link would waste roughly 60 addresses just to connect two router interfaces. VLSM fits every demand exactly and still banks 28 spares.

The VLSM allocation strip — five labeled blocks across 0–255.

The aggregation funnel — eight /24s merge into one /21.

VLSM's four non-negotiable steps, in the order the guide insists on.

Trainer's tip — the three errors that kill VLSM answers

Error 1 — forgetting to sort largest-first: smaller blocks planted early leave misaligned gaps that big blocks can no longer legally use.
Error 2 — starting the next subnet at the previous subnet's last host instead of its broadcast + 1. Those are two different, adjacent addresses, and only one of them is the correct next boundary.
Error 3 — sizing with 2^h instead of 2^h−2: needing 64 hosts actually requires h=7 (126 usable), a /25 — not the tempting h=6 (62 usable, a /26) that "64" seems to suggest at a glance.
Exam writers set these traps on purpose: 50 hosts needs /26 not /27, 100 needs /25 not /26, and 2 (a WAN link) needs /30.

Same slash, opposite moves — shorten it to merge, lengthen it to split.

/31 (RFC 3021) is the standard router-to-router mask — both addresses usable, no network/broadcast reserved; /32 is a host route to one exact address.
CIDR pointed inward = subnetting (longer prefix); pointed outward = supernetting/aggregation (shorter prefix) — 8 consecutive /24s aggregate into one /21.
VLSM's non-negotiable order: sort largest-first (alignment rule), size with 2^h−2 ≥ need, allocate at previous broadcast + 1.
On 192.168.10.0/24: Sales /25 at .0, Engineering /26 at .128, Operations /27 at .192, WAN /30 at .224, 28 addresses spare at .228–.255.

VLSM keeps its promise only in order: sort big-to-small, size to fit, start where the last broadcast left off.

3.4 · ICMP

"The Note That Comes Back" (3.4 · page 1/2)

IP Never Explains Itself — ICMP Is the Only Explanation You Get

Why ICMP has to exist

IP (Internet Protocol, the addressing-and-delivery layer) is deliberately mute: best-effort delivery means that when a packet cannot get through, IP dumps it in a ditch and tells no one — no apology, no explanation.
ICMP (Internet Control Message Protocol) is the voice bolted onto that silence — a reporting-and-diagnostics channel that either explains "your packet died, here's why" or simply asks "are you alive?"
It rides inside IP packets like a letter inside an envelope (IP's Protocol field is set to 1 for ICMP), yet it still counts as its own Layer 3 protocol — the network layer talking about itself, not a passenger riding above it.
Memorize the limit: ICMP only reports. It never repairs. Fixing the problem is the sender's job — usually TCP's, one layer up.

Every message: a Type and a Code

Type answers "which message is this?" — Echo Reply, Destination Unreachable, Time Exceeded, and so on. It is the headline of the complaint letter.
Code answers "which flavor of that message?" — the fine print under the headline (Destination Unreachable's code says whether it was the network, the host, or the port that couldn't be reached).
Everything below sorts into one of two families: query pairs (a question and its answer) or error reports (bad news about a packet that already died).

Two families, one protocol: queries pair a question with an answer; errors report a packet that already died.

Same type (3), three codes — each names how much closer to the destination the packet got before failing.

Same-sounding message, two unrelated numbering systems — always confirm the protocol before the number.

The query family — a question and its answer

Echo Request / Echo Reply — types 8 / 0. "Are you there?" / "Yes." This pair is the entire engine behind ping; memorize 8 and 0 cold.
Timestamp Request / Timestamp Reply — types 13 / 14. Two machines compare clocks and estimate transit time between them.
Router Advertisement / Router Solicitation — in ICMPv4, types 9 / 10: a host broadcasts "any routers here?" (Solicitation, 10) and a router answers "I'm here" (Advertisement, 9) — router discovery with no manual configuration needed.
Exam trap, corrected: a slide swaps these numbers and mislabels the pair as IPv6. The truth: in ICMPv4, Advertisement = 9, Solicitation = 10. IPv6 does router discovery entirely differently, inside Neighbor Discovery, using ICMPv6 (a different protocol, different numbers): Solicitation = 133, Advertisement = 134. If a question asks for RS/RA type numbers, first decide which ICMP — v4 or v6 — it means.

The error family — five ways a packet can die

Destination Unreachable (type 3) — delivery failed outright. Code 0 = network unreachable (a router had no route to the network at all); code 1 = host unreachable (the network was found, but the host stayed silent); code 3 = port unreachable (the host answered, but no process listens on that port) — sent by the destination itself, and the exact signal that tells a Unix traceroute it has arrived.
Source Quench (type 4) — "slow down, I'm congested." Deprecated (RFC 6633): flooding an already-congested network with more packets — the quench messages themselves — only made the congestion worse. TCP's own congestion control does this job now; type 4 is a historical answer only.
Redirect (type 5) — a router's advice, not a command: "there's a better first-hop router for that destination on your own LAN — use it next time." The packet that triggered the advice is still forwarded normally; only the host's future choice changes.
Time Exceeded (type 11) — code 0: the TTL (time to live, a hop counter) hit zero in transit; the router that decremented it to zero discards the packet and mails this back. Code 1: a fragment-reassembly timer expired before all the pieces arrived. Type 11 code 0 is the entire mechanism traceroute is built on.
Parameter Problem (type 12) — a header field was malformed, or a required option was missing: "your packet is broken," with a pointer marking exactly where.

Sanity rules that stop ICMP looping forever

An ICMP error is never generated about another ICMP error — otherwise a lost error report could trigger an error about the error, forever.
Never generated about a packet addressed to a broadcast or multicast destination — one bad multicast packet would otherwise trigger a flood of replies from every member of the group.
Only ever generated about the first fragment of a fragmented packet — later fragments don't carry enough information (no port numbers) to be worth reporting on.
Every error message carries the dead packet's original IP header + first 8 data bytes — exactly enough room to include the source and destination port numbers, so the sender can identify which conversation died.

Four ICMP numbers worth memorizing cold — one type-3 message hides three different codes.

Echo Request / Reply = 8 / 0 — ping's engine, memorize cold.
ICMPv4: Advertisement = 9, Solicitation = 10 (the slide swaps these). ICMPv6 Neighbor Discovery: RS = 133, RA = 134 — a different protocol.
Destination Unreachable code 3 (port unreachable) is sent by the destination itself — the signal that a probe arrived.
Source Quench (type 4) is deprecated (RFC 6633); ICMP always reports, never repairs.

IP buries the packet without a word — ICMP is the only note anyone finds.

"Shouting into Canyons & Engineered Breakdowns" (3.4 · page 2/2)

Ping Times an Echo; traceroute Manufactures a Trail of Confessions

ping — shouting into a canyon, timing the echo

Ping puts the query family to direct use: your machine sends an Echo Request (type 8) out, and if anything is listening, it answers with an Echo Reply (type 0) back — like shouting into a canyon and timing how long the echo takes to return.
RTT (round-trip time) is exactly that timed echo — the delay between the shout and the reply, printed as e.g. time=1.2ms.
Every reply also carries a TTL (hops remaining, not hops traveled). The value it started at is a fingerprint of the sending OS: 64 hints Linux/macOS, 128 hints Windows, 255 hints dedicated network gear (routers, switches) — hints only, since TTL only ever counts down from whatever the OS chose to start with.

Reading a failure message correctly

"Request timed out" means pure silence — nobody answered at all. That could mean a dead host, or (very commonly) a firewall — a rule-based traffic filter — silently eating the ICMP packets while the host itself is fine.
"Destination unreachable" is different, and more informative: some router along the path actively spoke up and said "I have no route to get this there."
The distinction matters on sight: silence tells you nothing about why; an active unreachable message tells you exactly which layer failed, and that a router — not the destination — is where it failed.

Each rung isolates one failure layer — climb until a ping fails, and that rung names the suspect.

Three parcels, three deliberate fuel shortages — the destination is the only stop that answers back with a different message.

Same climb, drawn as an actual ladder — climb until a rung breaks, and that step names the suspect.

The five-rung ladder, one layer at a time

Five pings, in order, each aimed at one specific layer of failure: loopback (127.0.0.1) → your own real IP → the default gateway → a remote IP → a name. A failure at any rung says exactly where to look.
Ping loopback first. It proves only the local TCP/IP stack (the layered networking software) — the packet never actually reaches the NIC (network interface card, the physical hardware), so a reply here says nothing about the cable, driver, or card.
Ping your own real IP next — the first rung that actually forces the packet out through the NIC and back. Loopback replying and this one failing is the exact gap that implicates the NIC (or its driver or cable).
Climbing further: the default gateway proves the LAN is reachable, a remote IP proves routing across networks works, and a name (like www.rit.edu) proves DNS — the name-to-address lookup — works on top of everything else. Each success retires one more suspect.

traceroute — parcels with deliberately tiny fuel tanks

traceroute abuses the TTL field on purpose. Its first probe carries TTL = 1 — a parcel given exactly enough fuel to reach the first town and no further.
The first router decrements that TTL to 0, discards the packet, and mails back a complaint letter: ICMP Time Exceeded (type 11). That letter's source address names the router that killed it — hop one, confessed.
The next probe carries TTL = 2: it survives the first router (TTL drops to 1, still alive) but dies at the second one, which sends its own Time Exceeded reply. TTL = 3 survives two routers and dies at the third. Each probe is built to travel exactly one hop further than the last before running dry.

The finish line — how the trip ends

The destination never discards a probe the way the routers in between do — it answers instead, and a different kind of reply is precisely the "we've arrived, stop" signal.
Unix traceroute sends its probes as UDP aimed at a deliberately absurd port nothing is listening on; the destination finds no process there and replies Destination Unreachable, code 3 — Port Unreachable — the same Family-2 message, now doubling as an arrival signal.
Windows tracert sends its probes as ordinary pings instead, so the destination simply answers with an ordinary Echo Reply (0) — a different tool, the same underlying trick.
Three probes go out per TTL value, giving three RTT samples per hop. * * * means that hop's router ignored the probes entirely and sent no ICMP reply back — normal for routers configured that way, not a sign anything is broken. Rising latency between two specific hops is what localizes exactly where the slowness lives — turning "the Internet is slow" into "hop 3 is slow."

Each probe carries less fuel than the last — the destination is the only stop that answers back differently.

Ping = Echo Request (8) out, Echo Reply (0) back; RTT is the timed round trip.
Starting TTL hints the OS: 64 = Linux/macOS, 128 = Windows, 255 = network gear.
Loopback (127.0.0.1) tests the stack only, never the NIC; loopback succeeding while the real IP fails implicates the NIC.
Unix traceroute finishes on Port Unreachable (type 3, code 3); Windows tracert finishes on Echo Reply (0).

Every dying parcel signs its own confession — traceroute just collects them, one town at a time.

3.5 · Routing

"Signs vs the City Office" (3.5 · page 1/3)

Forwarding obeys the sign; routing decides what the sign says

Two jobs, don't blur them

Forwarding is per-packet and local: a packet arrives, the router looks up its destination in the table, and shoves it out the matching interface. It happens in microseconds, in hardware.
Routing is the slower, global job of building that table in the first place — deciding what the best paths even are.
Analogy: forwarding is a driver obeying the signs at one intersection; routing is the city planning department deciding what all the signs should say.

What's inside a routing table row

Every row pairs a destination prefix with a next hop / exit interface — where anything matching that prefix gets sent.
Each row also carries a metric: the path's cost score. Competing routes to the same destination fight on this number, and lower wins.
Each row remembers its source too — how the router learned it, covered next.

Where a route can come from

Directly connected — the router sees the network sitting right on one of its own interfaces. Automatic, no typing.
Static — an admin typed it in by hand. Zero overhead to run, zero adaptability if anything changes; fine for a stub network or tiny site, unmaintainable once things grow.
Dynamic — a routing protocol learned it, and keeps re-learning it as things change. The rest of this section is about this one.

Longest prefix match — and the route of last resort

Notation recap: /n counts the leading network bits. A bigger n carves out a smaller, more specific block.
Worked 3-way match: a destination matches 10.0.0.0/8, 10.1.0.0/16, and 0.0.0.0/0 all at once. The router always keeps the most specific hit: 10.1.0.0/16 wins.
0.0.0.0/0 is the default route — the zero-length prefix that matches everything, which is exactly why it loses to everything: the "when all else fails" row.
A home router's whole table is basically one line: 0.0.0.0/0 pointing at the ISP.

Longest prefix match: the most specific sign always wins.

The driver obeys; the planning office decides what the signs say.

most specific match always beats the more general ones

a route names where to send, how far, and who told us

Forwarding = per-packet, local, hardware speed; routing = the slow global job of building the table.
Longest prefix match always wins — bigger /n means a smaller, more specific block.
0.0.0.0/0, the default route, matches everything, so it loses to everything.
Static routes: zero overhead, zero adaptability — fine only for stub networks and tiny sites.

A router never guesses — it obeys the most specific sign it can find.

"Everyone Gets the Map" (3.5 · page 2/3)

Link-state routing: flood the topology, then let Dijkstra decide

Link-state: everyone gets the whole map

Every router floods a description of its own links to all routers — flooding means each receiver re-forwards the message onward, so it reaches routers many hops away, not just neighbors.
Once flooding settles, every router holds an identical copy of the same who-connects-to-whom map (the full topology).
From there each router works alone: it privately runs Dijkstra's algorithm to compute its own least-cost paths to everywhere. Global knowledge, local computation.

Dijkstra is just bookkeeping

Keep a settled set. Each round: (1) move the cheapest not-yet-settled node into the settled set — its cost is now final, forever; (2) ask one question only — does going THROUGH the node just settled make any of its neighbors cheaper?
Two exam habits to drill in: settle exactly one node per row (always the minimum), and only re-examine the neighbors of the node you just settled — nothing else changes that round.

The six-node run from u, in plain words

x settles first, at cost 1 — the cheapest link straight out of u.
Through x: w improves from its direct cost of 5 down to min(5, 1+3) = 4, and y appears for the first time at 1+1 = 2 (v could also reach via x at 1+2=3, but that's worse than v's existing direct 2, so v keeps 2,u).
y settles next (tied with v at 2). Through y: w improves again to min(4, 2+1) = 3, and z appears at 2+2 = 4.
The rest fall out in cost order: v settles (2 — going through it improves nothing), then w settles (3), then z settles (4). Everyone is now settled.

Reading the answer off the tree

To build u's forwarding table, walk each node's predecessor chain backward until it hits u, and keep only the first hop you land on.
v's chain leads straight back through its own direct link, (u,v).
Every other chain — x, y, w, z — funnels back through the one cheap link (u,x). One inexpensive link ends up carrying almost all the traffic; that's typical of real networks.

Bold green = the shortest-path tree Dijkstra grows outward from u.

D(w) only ever gets cheaper — each settle re-checks one neighbor link.

settle one node per row · only re-check the just-settled node's links

global knowledge, local computation — the link-state idea

Link-state routers flood their own links to everyone, then each privately runs Dijkstra on the identical resulting map.
Dijkstra settles exactly one node per round — the cheapest unsettled one — and only re-checks that node's neighbors.
In the six-node run from u, the settle order is x(1), y(2), v(2), w(3), z(4).
Walking predecessors back: every node except v reaches u through the single cheap link (u,x).

Dijkstra never guesses ahead — it only asks what the node it just finished can do for its neighbors.

"Gossip, Lies & the Zoo" (3.5 · page 3/3)

Distance-vector routing: neighbors gossip, bad news loops, and the Internet gets carved into countries

Distance-vector, in one sentence

Each router keeps a private vector — its current best-guess distance to every destination — and periodically tells only its neighbors, never the whole network.
The rule (Bellman-Ford): my distance to Y = the best of, over every neighbor, of (cost to reach that neighbor) + (that neighbor's claimed distance to Y).
When an estimate changes, the router re-sends its vector; updates ripple hop by hop until nobody changes anymore — convergence.

Bad news travels slow: the count-to-infinity story

A new cheap link spreads in one wave per hop — good news travels fast. Losing a link is where trouble starts: bad news travels slow, and can loop.
Chain A—B—C, each link cost 1. Steady state: B reaches C at cost 1; A reaches C at cost 2, via B. Then the B–C link dies.
B loses its route to C — but right then A's stale routine advert arrives: "I can reach C at cost 2." A never says through whom. B reasons: "A is 1 away and claims 2 to C, so I can do it in 3 via A" — and installs a route pointing at A, whose route secretly points back at B. A loop is born.
B adverts "3" → A updates to 4 → B to 5 → and on, climbing every round while the two forward packets in a circle.

The two fixes

Poison reverse: precisely because A routes to C through B, A must turn around and tell B "my distance to C is infinity" — killing the lie before B can ever believe it.
RIP's finite infinity: define 16 = unreachable. A runaway count is now guaranteed to terminate instead of climbing forever.
That one constant is also why a RIP network can never be wider than 15 hops end to end.

Why Autonomous Systems exist

No protocol scales to a billion destinations, and none can span networks owned by different organizations with different interests — so the Internet is carved into Autonomous Systems (AS), one per administration: an ISP, a university, a company.
Think countries, not one map: inside an AS an IGP (Interior Gateway Protocol — OSPF, RIP, or EIGRP) optimizes freely; between ASes, policy always outranks cost — "never carry a competitor's traffic" is a rule no metric can express.
Hot potato: when several of your own exits reach the same destination, dump the packet at whichever gateway is nearest to you and let the next AS worry about the rest. Locally selfish, globally good enough.

Bad news loops and climbs until poison reverse breaks the cycle.

IGP keeps order inside each AS; BGP is the only language spoken between them.

tell your next-hop "∞" so it can't loop traffic back through you

The protocol zoo — one-liner per protocol

RIP — distance-vector; metric = hop count (max 15, 16 = unreachable); floods its full table to neighbors every 30 s over UDP port 520 (multicast 224.0.0.9 — the corrected address); a route silent for 180 s is declared dead.
OSPF — link-state; every router runs Dijkstra; metric = cost, proportional to 1/bandwidth; rides directly inside IP protocol 89 (no TCP or UDP port at all); scales through areas with a backbone area 0; supports equal-cost multipath (splits traffic across tied-cost paths).
EIGRP — Cisco's advanced distance-vector; sends partial, triggered updates (only what changed, only when it changes) instead of a periodic full table; its DUAL algorithm precomputes backup routes for near-instant failover.
BGP — path-vector; policy outranks cost every time; runs over TCP port 179; the loop check is simple — if a router sees its own AS number already in the advertised path, it rejects it.

four protocols, four personalities — one column each

Poison reverse forces A to tell B "distance to C = infinity" exactly because A's own route to C runs through B.
RIP defines 16 as unreachable, which caps any RIP network at 15 hops.
UDP 520 = RIP · IP protocol 89 = OSPF (no port at all) · TCP 179 = BGP.
BGP rejects any advertised path that already contains its own AS number — that is its entire loop check.

Distance-vector networks don't stop lying on their own — poison reverse and a hop limit have to make them.

3.6 · IPv6

"The Bigger Phone Book" (3.6 · page 1/2)

More Numbers, Leaner Header

Why the world needed a bigger book

Every IPv4 address is a 32-bit number, so there are only 2³² of them — about 4.3 billion. That sounded infinite once, the way a city planner might assume a phone book would never need more than a few billion numbers. Then every phone, laptop, router and light bulb wanted a number of its own too, and between 2011 and 2019 the regional registries handed out their last free blocks. The book ran out of pages.
NAT (Network Address Translation, the subject of Phase 6) bought the world decades of extra time: it lets thousands of devices share one public address, the way an office building shares one street address and a receptionist sorts the mail to the right desk. It worked, but it breaks end-to-end connectivity (two machines can no longer address each other directly) and forces routers to keep state — memory of who is who — that the network was never designed to carry.
IPv6's answer is brute force, not cleverness: addresses grow from 32 bits to 128 bits. 2¹²⁸ ≈ 3.4 × 10³⁸ possible addresses — enough to give every grain of sand on Earth its own number, with plenty left to spare.

The header goes on a diet

The redesign did not stop at bigger addresses — it used the fresh start to slim the header down. IPv4's header could stretch from 20 to 60 bytes once options were added. IPv6's header is fixed at 40 bytes, always — it never grows.
Where do the 40 bytes go? 8 bytes of small fields (Version, Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit) plus two 16-byte addresses (source, destination) = 40 bytes, fixed. Not 16 bytes — if a slide says the header is "16 bytes", that is a typo, likely confusing "each address is 16 bytes" with the whole header's size; the field list itself proves 40.

What got cut, and why it was safe

Header checksum — gone. Ethernet's own trailer (the FCS, Frame Check Sequence) already guards the whole frame, and TCP/UDP already checksum the payload above. A third checksum at this layer was pure duplicate work — and a wasteful one, since Hop Limit changes at every router, meaning that checksum would need recomputing at every single hop. Dropping it makes every router faster.
Fragmentation fields — gone from the header. IPv6 routers are never allowed to fragment a packet in flight. A too-big packet is dropped, and an ICMPv6 "Packet Too Big" message travels back to the sender; the source — never a router in the middle — discovers the path's MTU (the largest packet the whole path allows) and resizes.
IHL and Options — gone, because there is only one header length left to remember: 40. In their place: a chain of extension headers, each one naming the next link in the chain, so a router only reads what concerns it and lets the rest stream past.

A packet too big for the next link gets dropped, not fragmented — the source hears about it and resizes

Same redesign, drawn as a diet chart — IPv4 can bloat past 60 bytes with options; IPv6 is fixed at 40, and two fields simply got cut.

Same job, honest new name — plus one newcomer

Three fields kept their job and just earned a truer label: TTL → Hop Limit (it always counted hops, never time — the new name stops lying), Protocol → Next Header (names the payload's protocol, or chains to another extension header), and ToS → Traffic Class (the same priority marking, new name).
One field is genuinely new: Flow Label — a tag marking every packet of one stream (say, one video call) so routers can treat them consistently without re-inspecting each one.
Next Header's numbers worth knowing cold: 6 = TCP, 17 = UDP, 58 = ICMPv6.

IPv4's header vs IPv6's fixed 40 bytes — crossed-out fields vanished; curved arrows show renames

Prefixes read like a ruler — the first hex digit or two tell you the address's entire purpose before you parse the rest.

IPv6 header = fixed 40 bytes: 8 bytes of small fields + two 16-byte addresses — never 16 bytes total.
2¹²⁸ ≈ 3.4 × 10³⁸ addresses — 128-bit brute force fixed the 2011–2019 IPv4 shortage.
Checksum, fragmentation fields, IHL and Options all vanished — each replaced by something that does the job better (L2/L4 checksums, source-side path-MTU discovery, extension headers).
Next Header: 6 TCP · 17 UDP · 58 ICMPv6.

When you run out of phone numbers, you don't ration digits — you print a bigger book, and trim the cover while you're at it.

"Writing, Recognizing & Self-Numbering" (3.6 · page 2/2)

Read It, Write It, Let It Write Itself

Eight groups, four hex digits each

128 bits is written as 8 groups of 4 hexadecimal digits (hex = base 16, using 0–9 then a–f), separated by colons — 4 hex digits × 4 bits each = 16 bits per group, and 8 groups × 16 = 128 bits total.
Written out in full that is a long string of 32 hex digits, which is exactly why two legal shortenings exist — nobody writes an address raw if they can help it.

Compress it — two rules, worked

Rule 1 — drop the leading zeros inside each group, but never empty a group completely (leave at least one digit): 2001:0db8:0000:0000:0000:ff00:0042:8329 → 2001:db8:0:0:0:ff00:42:8329.
Rule 2 — replace exactly one run of consecutive all-zero groups with :: — only once per address (a second :: would be ambiguous, since nothing would say how many zeros belong on each side), and when two runs tie for longest, take the leftmost one: 2001:db8:0:0:0:ff00:42:8329 → 2001:db8::ff00:42:8329.
Decompression reverses it: count the groups actually written out, and :: silently stands for 8 minus that count of zero groups. fe80::202:b3ff:fe1e:8329 has 5 groups written, so :: hides 8 − 5 = 3 zero groups: fe80:0000:0000:0000:0202:b3ff:fe1e:8329.

Illegal moves — the common wrong answers

Two :: in one address — illegal. 2001:db8::ff00::8329 cannot be decompressed: nothing says how many zero groups sit on each side of each ::.
Dropping trailing zeros inside a group — illegal. Only leading zeros may go; ff00 can never shorten to ff.
:: can stand for a single all-zero group too — but if an address has two separate zero-runs, only the longer one gets compressed (leftmost if they tie).

A Global Unicast Address splits 48+16+64 — the subnet-ID field is yours to slice, not the interface bits

SLAAC: the router advertises the prefix, the host builds its own address, checks it, and owns it — no server needed

A different shape, same four steps — SLAAC numbers itself from a Router Advertisement, no DHCP required.

The routable and the local

2000::/3 — Global Unicast (GUA): the public, Internet-routable kind, anything starting with 2 or 3. Fixed anatomy: 48-bit global routing prefix (the block an ISP allocates) + 16-bit subnet ID (65,536 internal subnets to slice up) + 64-bit interface ID (the host part) — no borrowed bits, no host-count math, the split is already fixed.
fe80::/10 — Link-Local (LLA): mandatory on every IPv6 interface, generated automatically, valid only on its own link — routers never forward it further. All the neighbor chatter (talking to devices on the same wire: neighbor discovery, routing-protocol hellos, even a default gateway's own address) rides on fe80.
fc00::/7 — Unique Local (ULA): the RFC-1918-of-IPv6, private and not routable on the public Internet. In practice it always shows up as fd00::/8 (the "fd" half, self-assigned with a random 40-bit ID; the "fc" half sits unused).

Group calls, not shouts

ff00::/8 — Multicast: anything starting with ff, one message reaching a whole group at once. Two worth knowing: ff02::1 = all nodes on the link, ff02::2 = all routers on the link.
IPv6 has no broadcast at all. Every IPv4 broadcast habit — ARP asking "who has this address", DHCP's opening blast — is redesigned around multicast instead.
::1 = loopback (the whole of IPv4's 127.0.0.0/8 compressed into a single address); :: = unspecified, "I have no address yet" — the source address a host uses while still in the middle of getting one (IPv6's version of 0.0.0.0).

Every LAN is a /64, and it can number itself

Convention: every LAN is a /64 — half the bits name the network, half name the host. No VLSM agony, no host-count math (2⁶⁴ hosts is effectively infinite); more subnets come from carving the 16-bit subnet-ID field instead.
SLAAC (Stateless Address Autoconfiguration) lets a host number itself in four steps: hear a Router Advertisement (ICMPv6 type 134) carrying the /64 prefix → build the 64-bit interface ID (classically EUI-64 from the MAC address; modern OSes prefer a random privacy ID instead) → verify no one else on the link already has it → done, address owned, no server involved.
DHCPv6 still exists, for shops that want central control instead of self-service.

Living with IPv4 meanwhile

Dual stack — a host runs both IPv4 and IPv6 side by side, at the same time; this is the norm today.
Tunneling — IPv6 packets ride inside IPv4 packets to cross stretches of IPv4-only territory.
Translation (NAT64) — rewrites between the two address families so an IPv6-only host can still reach an IPv4-only one.

The exact worked example from the source — two rules, applied in order, with only one legal shortcut per address.

2001:0db8:0000:0000:0000:ff00:0042:8329 compresses to 2001:db8::ff00:42:8329 — drop leading zeros per group, then swallow the longest all-zero run with one ::.
Only one :: is legal per address, and only leading zeros may ever be dropped — never trailing ones.
Every LAN is a /64; SLAAC builds the address from a Router Advertisement (ICMPv6 type 134) with no DHCP server needed.
IPv6 has no broadcast — ff02::1 (all nodes) and ff02::2 (all routers) do that job by multicast instead.

Two rules to write an address, five prefixes to read one, four steps to hand one to yourself — no server required.

Phase 4 · Transport

"The Apartment Number" (Phase 4 · page 1/3)

Finishing the Address: House, Building, Apartment

Why Layer 4 exists

IP's whole job is getting a packet to the right machine (one computer, named by its IP address) — nothing more.
That machine runs dozens of network programs at once: a browser, a mail client, SSH, a game — all sharing that single IP address.
Something has to say which program the data is for. Layer 4, the transport layer, adds that last piece of addressing: a port number naming the process — a process being one running program, this one copy of your browser, not browsers in general.

Multiplexing and demultiplexing

Multiplexing: several programs on your machine each hand their outgoing data to the transport layer, which merges it all onto the one IP address you own, out the same door.
Demultiplexing: every incoming packet lands at that same IP address; the transport layer reads the port number stamped on it and sorts it into the correct program's inbox.
Same job, opposite directions — out is multiplexing, in is demultiplexing — and the port number is the only reason sorting is possible at all.

The address, finally complete

MAC address (Phase 2): which house on this street — gets a frame across one local link.
IP address (Phase 3): which building, anywhere on Earth — gets a packet to the right machine.
Port number (Phase 4): which apartment inside that building — gets the data to the right running program.
Every packet you send carries all three, nested: the link-layer frame wraps the IP packet, which wraps the transport segment carrying the port.

Port ranges — three neighborhoods, three rules

0 – 1,023, well-known: standard server services live here (HTTP 80, DNS 53...). Binding one — reserving that number with the operating system so nobody else can grab it while listening — needs admin/root privileges (elevated system permission), because these numbers are trusted.
1,024 – 49,151, registered: vendors register their own applications here (e.g. RDP 3389, PostgreSQL 5432) — no special privilege required.
49,152 – 65,535, dynamic/ephemeral: handed to clients (the side that starts a conversation) only for the life of one connection, then recycled — borrowed and returned, never kept.

One IP address, many apartment doors — the port number says which one

Two clients, one port 443, two different 4-tuples — no collision

The building is the IP address; each apartment door is a port number

Socket and connection — naming a conversation

A socket is one end of a conversation: IP address plus port, written 129.21.4.18:443 — precise enough to mean "this machine, this program."
A full connection needs both ends, described as a 4-tuple: (source IP, source port, destination IP, destination port).
That 4-tuple is why one server on port 443 can hold open thousands of client connections at once — the destination port never changes, but every client differs in source IP and/or source port, so every tuple stays unique. (NAT leans on this exact fact in Phase 6.)

The ports worth knowing cold

IANA (the Internet Assigned Numbers Authority — keeper of the internet's number registries) assigns the well-known ones below; they recur constantly across this course.
DNS's dual listing — both UDP and TCP on port 53 — is deliberate, not an error; the reason is settled in Phase 5.

The well-known ports worth knowing cold (dot color = transport: blue TCP, green UDP, purple both)

Three ranges, one number line — well-known, registered, ephemeral

A port is a 16-bit number, 0 – 65,535 — split by IANA into three ranges: well-known, registered, ephemeral.
Socket = IP + port; connection = the 4-tuple (source IP, source port, destination IP, destination port).
Binding a well-known port (0 – 1,023) needs admin/root privilege.
Port 53 (DNS) is the one service that runs on both UDP and TCP.

IP finds the building. The port finds who's home.

"The Careful Manuscript" (Phase 4 · page 2/3)

TCP's Handshake, Byte-Numbered and Exact

TCP's product — what you're buying

TCP (Transmission Control Protocol) sells one product over an unreliable network: a reliable, ordered, full-duplex byte stream.
Reliable: every byte is accounted for, using sequence numbers, acknowledgments, and retransmission to catch anything lost. Ordered: whatever gets scrambled in transit is restored to the original order before your program ever sees it.
Full-duplex: both directions flow at once — client and server can send and receive simultaneously, not take turns. Byte stream: one continuous flow of bytes with no visible message boundaries — TCP doesn't track where "your" messages start or stop, only that bytes arrive in order.
The full promise list: connection first (the handshake below), every byte accounted for, order restored, flow control (never drown the receiver) and congestion control (never drown the network) — both explained on the next page.

The price of that product

None of it is free — TCP spends overhead and time to earn those guarantees.
Overhead: a minimum 20-byte header rides on every segment (a segment = one chunk of the TCP byte stream), on top of the IP header underneath it.
Time: a full round trip (a message there and back) has to complete — the handshake below — before the first byte of real data even arrives.

The six flags, in plain words

Single bits inside the header; each one flips on to declare the segment's purpose: SYN (synchronize — "let's connect," carries the sender's own starting sequence number), ACK (the acknowledgment field is valid — set on almost every segment once a connection is running).
FIN (finished — polite, "I'm done sending"), RST (reset — abort now, "nothing lives on that port").
PSH (push — deliver to the application immediately, don't buffer it first, where buffer means hold in temporary memory), URG (urgent pointer valid — rare in practice).
RST vs. silence matters for troubleshooting: a closed port sends RST back instantly ("nothing lives here"); a firewall that silently drops the attempt gives no answer at all, so the client just waits for a slow timeout. Same failure, different cause — the delay is the tell.

The three-way handshake, with numbers

① Client sends SYN, seq = x — its own random starting sequence number, the ISN (Initial Sequence Number).
② Server replies SYN+ACK, seq = y, ack = x + 1 — proposing its own random ISN while confirming the client's in the same breath.
③ Client sends ACK, ack = y + 1 — and this segment may already carry real data, no fourth trip required.
Why not two messages? Both directions need a starting number, and both need it acknowledged — the middle segment does two jobs at once (its own SYN and the ack of the client's), which is exactly why three suffice and two would leave the server's number unconfirmed.

Two SYNs, two acks, folded into three segments

Bytes are page numbers; the ack names the next page due

Same destination socket, endless different client tuples

Closing — same courtesy, four steps

Closing takes four steps, not three: FIN → ACK one way, then FIN → ACK the other way.
Why four here but three at the start: each direction closes independently. A half-close means "I'm done sending, but I'll still listen for you" — so the two FIN/ACK pairs can't always be folded together the way the two SYNs could.

Sequence and acknowledgment — count bytes, not segments

Think of the byte stream as a manuscript with every byte numbered like a page: the sequence number is the page number of this segment's first byte.
The acknowledgment number always names the NEXT byte expected — not the last one received. Saying "ack 4,501" means "I have everything through 4,500; send 4,501 next."
Worked example: ISN x = 4,000, so the first real data byte is 4,001. Client sends 500 bytes starting at seq 4,001. Server replies ack = 4,501 — confirming receipt through byte 4,500 and asking for 4,501 next.

Two headers taken off the top — MSS is what remains

TCP's product: a reliable, ordered, full-duplex byte stream — priced at a 20-byte-minimum header and one round trip before real data.
The handshake is 3 segments (SYN, SYN+ACK, ACK); closing is 4 (FIN/ACK each way) because each side closes independently.
RST means "nothing listens here," answered instantly; a firewall's silent drop means a slow timeout instead — same failure, different cause.
The ack number always names the next expected byte, never the last one received.

Every byte gets a page number — the ack just names the next one due.

"Recovery, Brakes & the Postcard" (Phase 4 · page 3/3)

How TCP Recovers and Slows Down, and Why UDP Won't Bother

Loss recovery — noticing and fixing gaps

A duplicate ack is TCP's "I'm still waiting" signal: if the server keeps acking 4,501 over and over instead of moving forward, it is naming the same missing byte every time, not a new one.
Three duplicate acks in a row are treated as proof the data is truly lost, not just briefly out of order — triggering fast retransmit, an immediate resend with no timer to wait out.
The fallback: the retransmission timeout. If no ack for the missing data arrives before that timer runs out, the sender just resends starting from the last acknowledged byte.
Nothing magical about any of it — reliability is only numbering (sequence numbers), plus acks, plus timers, working together.

The two brakes: flow control vs. congestion control

Flow control protects the receiver: the Window field advertises how many more bytes the receiver can currently buffer (hold in temporary memory) — the sender may never have more than that amount in flight (sent but not yet acknowledged) at once. Window = 0 means "stop, I'm full."
Congestion control protects the network: TCP cannot see the network directly, so it infers congestion from loss and throttles itself in response.
Slow start is one such algorithm — it ramps the sending rate up gently from a small first burst instead of blasting at full speed immediately. This course only asks that you know it exists, not its internals.
Same shape, different judge: flow control is a number the receiver announces; congestion control is a guess the sender makes from symptoms.

MSS — three layers baked into one number

Ethernet's MTU (maximum transmission unit — the biggest frame the link allows) is 1,500 bytes.
Subtract IP's own header (20 bytes) and TCP's own header (20 bytes): 1,500 − 20 − 20 = MSS 1,460 — the biggest chunk of actual data one segment can carry.
MSS is negotiated in the handshake's options field, so both sides agree on the ceiling before any data flows.

UDP's header — the corrected fact

UDP (User Datagram Protocol) is IP with ports and nothing else: an 8-byte header, four fields — source port, destination port, Length, checksum.
Length is the length of the entire datagram, header plus data — not just the header (a common exam trap). Minimum value is 8, meaning an empty payload.
Worked example: a 100-byte payload makes Length = 108 (8 header bytes + 100 data bytes).

One brake announced by the receiver, one brake guessed by the sender

Same job (get bytes across), opposite bets — fields present vs. fields absent

Fine for some messages, wasteful for others

What UDP refuses — and why that's the product

No connection, no handshake, no acks, no ordering, no retransmission, no flow or congestion control — every guarantee TCP sells, UDP declines to buy.
That's not laziness, it's the product: zero setup latency (the first packet already is data — no round trip first), tiny overhead (8 bytes vs. 20+), no state kept on the server (nothing remembered per client), and no retransmission delay for data that expires anyway.
Postcard vs. registered mail: a postcard (UDP) is dropped in the mail and forgotten; registered mail (TCP) is tracked, signed for, and resent if it goes missing — fine for some messages, wasteful for others.
Late is worthless for some data: VoIP, video, and gaming traffic are forgiving of jitter (uneven timing between packet arrivals, from Phase 1) but not of a resend arriving after the moment has passed — skipping a lost packet beats delaying everything to redeliver it. DNS is a one-shot question-and-answer that doesn't need a handshake to ask one question. DHCP quite literally cannot hold a connection open, because the client has no IP address yet to hold one with. SNMP, TFTP, and RIP make the same trade for the same reason: small, repeated exchanges where UDP's minimalism costs nothing.

QUIC and HTTP/3 — care rebuilt on top of speed

When an application needs reliability but still wants UDP's low-latency start, it can rebuild the missing guarantees itself, or ride on QUIC, which reconstructs TCP-like ordering and reliability on top of UDP instead of inside a TCP connection.
HTTP/3 is built on QUIC — proof that the TCP-or-UDP choice isn't permanently fixed; the guarantees can be re-engineered layer by layer.

Reading netstat — the whole phase in one command

LISTENING means a program sits ready, waiting for someone to connect (e.g. an SSH server on 0.0.0.0:22) — no conversation yet, just an open door.
ESTABLISHED means a real two-way conversation is active right now, tied to one specific 4-tuple (e.g. your machine's 192.168.10.5:52514 talking to 140.82.113.26:443).
UDP rows show no state at all — no LISTENING or ESTABLISHED label — because UDP has no connection to track in the first place; a DHCP client's socket just sits ready to send or receive with no relationship recorded.

Length always means header + data — the classic exam trap

Three duplicate acks trigger fast retransmit; no ack at all before the timer expires triggers a plain timeout retransmission.
Window (flow control) is the receiver's announced free space, a known number; congestion control is the sender's own guess, inferred from loss.
MSS 1,460 = Ethernet MTU 1,500 − IP header 20 − TCP header 20, agreed during the handshake.
UDP's Length field counts header + data (minimum 8); a 100-byte payload makes Length 108 — not the header alone.

Reliable costs time. Fast costs certainty. Pick the one the moment needs.

Phase 5 · DNS & DHCP

"The Phone Book in a Tree" (Phase 5 · page 1/3)

Why one machine can never hold the whole address book

Why we bother with names at all

Nobody can remember 104.18.32.7, and nobody should have to — computers hold numbers easily, people hold names easily.
Addresses move house: a site changes hosting and gets a new number, but its name stays the same — the phone book updates once instead of every visitor re-memorizing digits.
One popular name can point at many servers at once — load balancing, spreading one name's visitors across several machines so no single one drowns.
Every page you open begins with a silent DNS lookup you never see.

Why the world can't share one giant server

Single point of failure — one crash and every name lookup on Earth stops at once.
Impossible traffic — billions of lookups a second cannot funnel through one door.
Distance — one location can never sit physically near every user on the planet.
Maintenance monopoly — whoever ran that one machine would control every name that exists.

Three tiers, read right to left

The fix: a distributed, hierarchical database — no single machine holds it all; each layer only knows a little.
Root ("."): 13 identities labeled a-m, replicated to roughly 1,000 machines; it only knows who runs .edu, never rit.edu's actual records.
TLD servers (Top-Level Domain — the .edu/.com/.ae part) know each domain's authoritative servers, nothing more.
Authoritative server actually owns a domain's real records. Read www.rit.edu right to left: .edu (which TLD?) → rit.edu (which domain?) → www (which host?).

Each server hands back a referral until the authoritative server hands back the actual answer.

Eight record types, eight jobs — the whole database is just rows of these.

DNS answers a name the same way you'd read it — one label at a time, right to left.

Address and alias records

A — name → IPv4 address; the workhorse behind almost every ordinary lookup.
AAAA — "quad-A" — name → IPv6 address; the name puns on IPv6 having 4× the bits of an A record.
CNAME — alias → canonical name (e.g. www.shop.com → shop.hosting.net); the resolver restarts the whole lookup on the target name.

Records with special jobs

MX — domain → mail server, each with a preference number where the lowest wins. NS — domain → its authoritative name servers, the glue behind every referral.
PTR — IP → name, a reverse lookup living in DNS's dedicated in-addr.arpa zone; it's what ping -a consults.
SOA — a zone's ID card (a zone = one managed slice of the namespace, e.g. rit.edu and below): primary server, admin email, a serial version number, and a refresh timer for secondaries.
TXT — name → arbitrary text; today mostly SPF/DKIM mail policy (anti-forgery proof a message really came from the domain) and ownership proofs.

Four reasons the whole Internet needs many DNS servers, never just one.

Root servers (13 identities, a-m, ~1000 replicas worldwide) know who runs each TLD — never a domain's actual records.
Read a name right to left: www.rit.edu = .edu → rit.edu → www.
CNAME restarts the lookup on its canonical target; MX carries a preference number where the lowest wins.
PTR (reverse lookup) records live in the special in-addr.arpa zone, not inside a normal domain.

Nobody owns the whole phone book — every server just knows who to ask next.

"Room Service & Milk Cartons" (Phase 5 · page 2/3)

One question in, several referrals out, and a clock ticking on every answer

One question, many hops

Your computer's stub resolver (the tiny DNS client built into the OS) never talks to the wider Internet itself — it asks its recursive resolver (ISP, campus, or 8.8.8.8) exactly one question and means it literally: "bring me the final answer," like ordering room service instead of walking to the kitchen.
The recursive resolver then does the legwork iteratively: ask root → "ask the .edu TLD servers" → ask TLD → "ask rit.edu's servers" → ask authoritative → answer. Think of an info desk that never fetches the item itself, only points you down the right hallway each time.
Recursive = "give me the final answer" (the one leg between you and your resolver). Iterative = "tell me who to ask next" (every leg your resolver walks after that).
Root and TLD servers refuse recursive work — if they chased down every answer themselves instead of just referring, the handful of them would melt under the world's traffic.

Why the second lookup is free

Every answer a server hands back wears a TTL (Time To Live) — like the date stamped on a milk carton, telling your resolver exactly how long the answer stays good.
Your resolver caches the answer; look up the same name again before the TTL expires and the reply comes back in microseconds, with zero packets sent anywhere.
The tradeoff: when a site actually moves, everyone still holding an unexpired, now-stale "carton" keeps getting the old address until it expires — exactly why DNS changes are said to "take time to propagate."

Postcards vs the moving truck

Ordinary DNS questions ride UDP port 53 — a single postcard out, a single postcard back; a full handshake would triple the cost for one tiny question.
TCP port 53 is the moving truck: reserved for a zone transfer (AXFR), where a secondary DNS server copies an entire zone's records from the primary and needs guaranteed, ordered delivery.
TCP also rescues an oversized single answer: past the classic 512-byte limit, the server sets a truncated flag and the client simply retries the same question over TCP.

Tools that ask DNS directly

nslookup www.rit.edu — simple: hand it a name, get back an address.
dig www.rit.edu A +short — surgical: ask for exactly one record type.
dig @8.8.8.8 rit.edu MX — aim the question at a specific server, ask for mail routes.
dig -x 129.21.4.18 — reverse lookup: address in, name out.

Recursive = one question, one final answer. Iterative = the resolver's own walk, hop by hop.

Every answer expires on schedule — only the clock resets, not the truth, until you ask again past expiry.

Four commands that skip the browser and ask DNS directly.

Tiny questions ride UDP's postcard; zone transfers need TCP's moving truck.

Your stub resolver asks one recursive question; its resolver then works iteratively, hopping root → TLD → authoritative.
Root and TLD servers refuse recursive work — they only refer, or the handful of them would melt under global traffic.
Ordinary DNS queries ride UDP 53; zone transfers (AXFR) and oversized, truncated answers fall back to TCP 53.
Every answer carries a TTL; a stale cached answer after a site moves is exactly why DNS changes take time to propagate.

The resolver never rests — it just remembers what it already learned, until the milk goes bad.

"The Front Desk (DHCP)" (Phase 5 · page 3/3)

Plug in, and the network hands you everything you need to belong to it

Why DHCP exists

Typing IP settings by hand on every device is a typo factory — duplicate addresses, wrong masks, forgotten gateways, multiplied by every laptop that changes buildings twice a day.
DHCP (Dynamic Host Configuration Protocol) centralizes it: a server leases each arriving client everything it needs at once — IP address, subnet mask, default gateway, DNS servers, and a lease duration.
A lease is temporary on purpose: when it lapses, the address returns to the pool — a small pool can still serve a large, rotating crowd of devices.

DORA, hop by hop

DISCOVER — the client has no address at all, so it broadcasts from 0.0.0.0:68 to 255.255.255.255:67: a nobody shouting to everybody, since it doesn't even know its own room number yet.
OFFER — a DHCP server replies with a candidate address, its settings, and a lease time.
REQUEST — the client broadcasts again, still sourced from 0.0.0.0: nothing is actually its own yet; broadcasting this also politely tells every other offering server to reclaim its offer.
ACK — the chosen server confirms; the lease timer starts now, and the interface configures itself.

Staying leased, and staying reliable

At roughly 50% of the lease, the client renews with a unicast REQUEST straight to its server — sourced this time from its own leased IP, since it now actually owns it.
An unanswered unicast renewal falls back to a broadcast REQUEST, and if that also fails, a completely fresh DORA.
DHCP rides UDP, which is unreliable alone, so it protects itself two ways: the UDP checksum guards integrity, and clients retransmit with randomized timers — randomized so a building full of rebooting PCs doesn't stampede the server at once.

Past one LAN, and the two attacks

Broadcasts die at routers, so plain DHCP reaches only one LAN. A router instead runs a relay agent (Cisco: ip helper-address) that repackages the broadcast as unicast to a central server, which tells subnets apart by the relay's own stamped-in gateway address.
Starvation: a flood of fake DISCOVERs from one attacker drains the whole address pool, leaving nothing for real users.
Rogue server: an attacker answers DISCOVERs before the real server can, handing out itself as gateway and DNS — instant man-in-the-middle.
Defense: DHCP snooping on switches — only specifically sanctioned ports may send server-side DHCP messages.

DISCOVER and REQUEST both start from address zero; only the ACK actually makes an address yours.

Whoever answers first wins the client — even if the honest server was only a heartbeat behind.

One relay agent turns a dead-on-arrival broadcast into a routable unicast.

The lease doesn't end at the ACK — it quietly renews, or escalates, on a schedule.

A DHCP lease bundles IP address, subnet mask, default gateway, and DNS servers, all with an expiration; the address returns to the pool afterward.
DISCOVER and the initial REQUEST both broadcast from 0.0.0.0 — an address becomes the client's own only at the ACK.
Renewal at about 50% of the lease is a unicast REQUEST sent from the client's own leased IP, straight to its server.
Rogue DHCP servers win by answering first, handing out themselves as gateway and DNS; DHCP snooping on switches is the defense.

In DHCP, the first answer wins the client — which is exactly the vulnerability, and exactly the fix.

Phase 6 · NAT — the finale

"The Receptionist's Call Log" (Phase 6 · page 1/2)

Free inside, frozen outside — until a router starts keeping notes.

Free indoors, frozen at the border

Millions of homes and offices reuse the exact same private street names — 10/8, 172.16/12, 192.168/16 — because those ranges are free to hand out and feel infinite.
Free only inside the building. Step onto the real Internet and any Internet router drops these addresses on sight — they are unroutable, meaning no outside router has a path to them or would even try.
So a laptop sitting at 192.168.10.5 should be a dead end for the whole outside world. Something at the edge has to swap that address for a real one before the packet leaves — every single time.

The trick: rewrite it in flight, and remember

A NAT router (Network Address Translation) sits at the border — the seam where the private network meets the Internet — holding one or a few real, public addresses.
Outbound, it rewrites the source address in the packet header mid-flight, private to public. Inbound, it rewrites the reply back. The data inside never changes — only the address on the envelope.
It can only reverse a rewrite because it keeps a translation table, a running log of every conversation it has opened, built the moment each one starts.
Cisco's two words for the two faces: inside local = the address as seen on the LAN-side face of the router (the private one) · inside global = the same host's address as seen on the world-side face (the public one).

Four types, easiest to hardest

Static NAT — one private address tied to one public address, fixed forever. Use it for a server the outside world must reach reliably, like mail or web: 10.1.1.10 ↔ 203.0.113.10, unchanging, both directions.
Dynamic NAT — still one private ↔ one public, but the public one comes from a shared pool, first-come-first-served. A 10-address pool serves ten hosts at once; the eleventh simultaneous host simply waits. A stepping stone, rarely used today.
PAT / NAT overload — many private addresses share one public address, told apart by port number. This is the default sitting inside almost every home router.
Overlapping NAT — translates both source and destination address, for when two merged or VPN-linked sites happen to have picked the same private range. It also explains something odd: a host there never even tries to send to the router, because its subnet mask says the far address is local — so the packet never leaves the building until both sides are given fake stand-in ranges to dial instead.

PAT walkthrough: the collision at port 1050

Host A opens a browser tab to a web server: source 10.100.100.3:1050. NAT rewrites the source to 200.1.1.1:1050 and records the mapping before forwarding.
Host B, moments later, happens to grab the very same ephemeral port (the random temporary source port an OS picks per connection) for its own tab: source 10.100.100.50:1050. But 200.1.1.1:1050 is already taken, so NAT assigns the next free port instead: 200.1.1.1:1051.
Both replies come back addressed to the one public IP — one to :1050, one to :1051. NAT looks each up in its table and un-rewrites it: :1050 heads back to A, :1051 heads back to B, both restored to their original private addresses, untouched.
Every rewrite forces a recount: both checksums are recomputed, the IP header's and the TCP one — because the Layer-4 checksum is calculated over a pseudo-header (a scratch header, never actually transmitted, that includes the IP addresses), so changing the address invalidates the old checksum.

Outbound: two private hosts, one public face, told apart by port

Inbound: the table lookup un-does the rewrite

Free to reuse indoors — meaningless the moment it steps outside

A conversation is bigger than an address

What actually identifies a conversation is a 4-tuple: source IP, source port, destination IP, destination port — not just an address. That is the whole reason PAT works at all.
Because ports add roughly 64,000 possibilities, one public IP address can juggle ~64k simultaneous flows per destination before it runs out of room.
This one trick — many private hosts hiding behind a handful of public addresses — is credited with deferring global IPv4 address exhaustion by roughly 25 years.

Four ways to share a public address, from a fixed pair to a full rewrite

Private ranges 10/8, 172.16/12, and 192.168/16 are unroutable on the real Internet — any Internet router drops them on sight.
A conversation is identified by a 4-tuple (source IP, source port, destination IP, destination port), so one public address can hold about 64,000 simultaneous flows per destination.
Every NAT rewrite recomputes both checksums — the IP header's and the TCP/UDP one — because the Layer-4 checksum covers a pseudo-header containing the IP addresses.
PAT (NAT overload) is credited with deferring global IPv4 address exhaustion by roughly 25 years.

One face for the whole crowd — and a ledger that never forgets who is who.

"No Cold Calls, and the Honest Bill" (Phase 6 · page 2/2)

What a receptionist can't do for you, and what it quietly costs everyone.

No cold calls

The log only ever gets written when someone inside dials out first. An outsider who calls in cold, with no prior outbound call, finds no entry — there is nothing to route the call to, so it is simply dropped.
That is why a friend's home-hosted game server can run perfectly and still be unreachable from outside: the very first packet in is an inbound SYN, and no table entry exists yet to receive it.
It looks like a security feature — no unsolicited inbound connections — but it is really an accident of bookkeeping, not a deliberate lock. More on that below.

Writing the line by hand

Port forwarding fixes it by creating that missing log entry manually, once, ahead of time: public :25565 → 192.168.10.5:25565 — written by a person, not by a live connection.
The blunt version is a DMZ host (named after a military demilitarized zone): forward every port to one chosen PC. Simple to set up —
— but that PC then loses NAT's incidental shelter entirely. It sits as exposed to the Internet as if it held a public address directly, table entry or not.

The honest cost sheet, part 1

Breaks end-to-end connectivity — two hosts talking directly with their own real, unaltered addresses. Peer-to-peer apps (two ordinary computers dialing each other directly) and some VoIP calls need traversal tricks to work around it, such as STUN (a protocol letting a device behind NAT discover its own public address) and its relatives.
Protocols that write addresses inside the payload break — classic FTP, and SIP (the protocol that sets up voice and video calls), both write IP addresses into the message body itself. NAT only rewrites headers, so it never sees them.
The fix is a protocol-aware helper called an ALG (Application Layer Gateway) — software that unseals the envelope, finds the addresses hidden in the letter, and patches those too.

The honest cost sheet, part 2

State is fragility. The router must hold a live table in memory to make any of this work. Reboot it, and the table is gone — every open session dies at once, with no way to recover it.
A layer violation. Routers are only supposed to read Layer-3 addresses and leave everything else alone. NAT reads and rewrites both the Layer-3 address and the Layer-4 port — purists call this exactly what it is.
A curtain is not a lock. NAT is not security by itself — it only hides structure. A firewall is still a separate job, even though the "no unsolicited inbound" side effect resembles one.
IPv6's actual answer to address scarcity was blunter than any of this: enough addresses that no host ever needs to share one — so no NAT at all.

The same stranger, before and after one hand-written rule

Classic FTP and SIP write IPs into the body — plain NAT can't reach them

The Cisco verbs this phase ends on

show ip nat translations — the live table itself, the PAT rows from the walkthrough, for real, right now.
show ip nat statistics — totals: pool usage, hit and miss counts.
clear ip nat translation * — flush the whole table; sessions simply re-create themselves on the next packet.
debug ip nat — watch every rewrite happen live — lab only, it is extremely chatty in production.

One keystroke, every phase, one round trip

Click a link at 192.168.10.5. DNS resolves the name first (Phase 5, UDP port 53) — no address, no journey — then the TCP handshake begins (Phase 4).
The first packet gets an IP header with your address as source, the server as destination (Phase 3). Your subnet mask checks the destination and says "not my network," so the packet goes to the default gateway instead of straight out.
ARP finds that gateway's MAC address, and a frame is built around the packet (Phase 2) just to cross the first wire.
At the border the router de-frames the packet, NAT rewrites the source to a public IP and port and logs the mapping (Phase 6), and routers beyond forward it hop by hop by longest-prefix match, TTL ticking down at each one (Phases 3.5 and 3.1) so a lost packet cannot loop forever. The server answers to that public socket; NAT un-rewrites it, wraps it in a fresh frame addressed to your MAC, and the browser paints the page.

Seven stations, one round trip — every phase of the guide, once each

What NAT quietly costs, beyond the ALG problem

An inbound-first connection has no table entry and is dropped by default — why unmodified home NAT blocks incoming game or server traffic.
Port forwarding is a manual, permanent translation entry (for example public :25565 → 192.168.10.5:25565); a DMZ host forwards every port to one PC and strips away all of NAT's incidental shelter.
NAT is a deliberate layer violation: it reads and rewrites both the Layer-3 address and the Layer-4 port, something a router is otherwise not supposed to touch.
IPv6 solves address scarcity with enough addresses for every device — its answer to the problem NAT was invented for is simply no NAT at all.

A curtain hides the room. It does not lock the door.