Networking from zero,
in the order your brain wants it.

Write the weights 128 64 32 16 8 4 2 1 over the bits and add the weights that sit under a 1: the 1s fall on 128, 32, 16 and 4 → 128 + 32 + 16 + 4 = 180.

A (45) is incorrect — that's what you get by reading the octet right-to-left (00101101); bit weights always run 128 → 1 left-to-right. B (75) is incorrect — it sums the weights under the zeros (64+8+2+1). C (164) is incorrect — it drops the 16 from the sum; sanity-check by converting back and it fails.

Reference: Phase 0 — Number systems · s2 30–31 · s6 23–27

Subtract the biggest weight that fits, left to right: 128 fits (203−128=75) → 1. 64 fits (75−64=11) → 1. 32 no → 0. 16 no → 0. 8 fits (11−8=3) → 1. 4 no → 0. 2 fits (3−2=1) → 1. 1 fits → 1. Result 11001011; check back: 128+64+8+2+1 = 203 ✓.

A is incorrect — 10101011 = 171. B is incorrect — 11001010 = 202; it forgets the final 1-bit (203 is odd, so bit 0 must be 1 — a ten-second parity check that catches this instantly). D is incorrect — 11010011 = 211; the 16-weight bit is set instead of the 8.

Reference: Phase 0 — Number systems · s6 23–27

Two routes, same answer. Direct: each hex position weighs a power of 16, and B = 11, so 11×16 + 2 = 178. Via binary (the safe route): B = 1011, 2 = 0010 → 10110010 = 128+32+16+2 = 178 ✓.

A (162) is incorrect — that's 0xA2; it treats B as 10, but A=10 and B=11. B (176) is incorrect — that's 0xB0; it drops the low nibble's 2. D (194) is incorrect — that's 0xC2 (C=12).

Reference: Phase 0 — Number systems, hex section · s6 26

Mask 1s always fill in from the left, so five 1s is 11111000 = 128+64+32+16+8 = 248. Learn the ladder cold — each step adds the next weight: 128 (one 1), 192, 224, 240, 248, 252, 254, 255 (eight 1s).

B (252) is incorrect — 11111100 has six 1s. C (240) is incorrect — 11110000 has four. D (224) is incorrect — 11100000 has three. Counting 1s in a mask octet is exactly how you'll count borrowed bits in Phase 3.3, so drill it now.

Reference: Phase 0 — Trainer's tip, landmark octets · s6 42

The five components are message, sender, receiver, transmission medium, and protocol. Topology is the geometric arrangement of links and nodes — a property of how a network is laid out, not a component of a communication system.

A is incorrect as an answer because protocol is a component — the rule set; without it devices are connected but not communicating. B is incorrect because the medium is a component — the physical path (twisted pair, coax, fiber, radio). D is incorrect because the receiver is a component — the device the message is delivered to.

Reference: Phase 1 — What is data communication? · s1

Jitter is variation in packet arrival time. Audio and video need packets at an even rhythm; when spacing varies, playback stutters even though the average speed is fine — exactly this scenario.

A (Delivery) is incorrect — delivery means data reaches the correct destination; here it does. B (Accuracy) is incorrect — accuracy means the data arrives unaltered; nothing was corrupted. C (Timeliness) is the trap — timeliness is about data arriving on time overall (late video is useless video); this stream is on time on average — it's the variation that hurts, and that is jitter by definition.

Reference: Phase 1 — What is data communication? · s1

Half-duplex = both directions possible, one at a time — the single-lane bridge. Whoever transmits gets the whole channel capacity; the other must wait.

A (Simplex) is incorrect — simplex is one direction ever (keyboard → computer, computer → monitor); here both sides can talk. C (Full-duplex) is incorrect — full-duplex is both directions simultaneously (a phone call, modern switched Ethernet); walkie-talkies can't do that. D (Multipoint) is incorrect — that's a connection type (more than two devices sharing one link), not a data-flow mode at all.

Reference: Phase 1 — Data flow · s1

Goodput is throughput counting only useful application data — headers and retransmitted bytes removed. The chain always orders itself bandwidth ≥ throughput ≥ goodput: 100 ≥ 74 ≥ 68 here.

A (Bandwidth) is incorrect — bandwidth is the 100 Mbps: the theoretical capacity, the width of the pipe. B (Throughput) is incorrect — throughput is the 74 Mbps: bits that actually crossed, useful or not. D (Latency) is incorrect — latency is a time (how long data takes to arrive), not a data rate; it isn't any of these numbers.

Reference: Phase 1 — Performance · s1 29

Pushing more traffic into a network (chasing throughput) fills queues in every device along the path, and queues are exactly where delay grows. High throughput and low latency fight each other under load.

A is incorrect — bandwidth and goodput are just refinements of the same "how much data" axis; they rise and fall together. C is incorrect — reliability and security are two of the three network evaluation criteria (with performance), not the contradictory performance pair. D is incorrect — accuracy and jitter are effectiveness characteristics of a transmission, not the trade-off in question. Note: your s1 slide 29 says "two metrics" then lists four — the intended pair is exactly throughput vs delay (see Appendix A).

Reference: Phase 1 — Performance · Appendix A · s1 29

Full mesh needs n(n−1)/2 links: 10×9/2 = 45, and every router needs n−1 = 9 ports. This cabling/port explosion is why full mesh survives only in small backbones.

B (90) is incorrect — that's n(n−1) without the ÷2; it counts each link twice, once from each end. C (100) is incorrect — that's n², which would even include a device linked to itself. D (9) is incorrect — that's the number of ports per device (n−1), not the number of links.

Reference: Phase 1 — Topologies, worked example · s1 43

A is correct — the center (today, a switch) is the star's single point of failure: it dies, everything dies. B is correct — one link and one port per device is exactly why star is cheap and easy to install and reconfigure, and why it's today's LAN standard.

C is incorrect — in a star, one broken cable disconnects only that node; killing the whole segment with one break is bus behavior (and the break also reflects noise both ways there). D is incorrect — dedicated links between every pair describes mesh, with its n(n−1)/2 link cost.

Reference: Phase 1 — Topologies table · s1

Syntax is the structure or format of the data — the order and size of fields. "First 8 bits = sender address" is purely about where a field sits, i.e. format.

B (Semantics) is incorrect — semantics is what a field means and what action follows (is that address the next hop or the final destination?). The rule quoted doesn't interpret the address, it just positions it. C (Timing) is incorrect — timing covers when to send and how fast (a 100 Mbps sender drowning a 1 Mbps receiver is a timing failure). D is incorrect — standardization is how protocols get agreed and published, not one of the three protocol elements (syntax, semantics, timing).

Reference: Phase 1 — Protocols and standards · s1 · s2

De jure ("by law") standards are ratified by a recognized standards body — ISO, ITU-T, ANSI, IEEE, EIA. Once IEEE blessed it as 802.3, Ethernet's spec became de jure.

A (De facto) is incorrect as the answer but describes Ethernet's earlier life: "in fact" standards win through widespread use without official approval — that was DIX Ethernet before ratification. C (Internet Draft) is incorrect — that's an IETF working document with a six-month lifetime, not an IEEE ratification. D (RFC) is incorrect — RFCs are the published documents of Internet standards (like RFC 791 for IP); IEEE LAN standards don't go through the RFC track.

Reference: Phase 1 — Protocols and standards · s1

The TCP/IP model folds OSI's top three — Application (7), Presentation (6), Session (5) — into one Application layer, because in practice applications (HTTP, DNS, SMTP…) handle their own formatting, encryption and dialog management. The remaining four layers line up one-to-one: Transport, Network/Internet, Data Link, Physical.

D (Transport) is incorrect — transport survives intact in both models; it's where TCP/UDP and port numbers live. E (Network) is incorrect — it maps to the TCP/IP Internet layer (IP, ICMP), it isn't absorbed into Application.

Reference: Phase 1 — Layering, the two stacks side by side · s2

Routers are Layer-3 devices: at each hop they de-encapsulate the incoming frame, read the IP header of the packet to choose the next hop, then wrap the packet in a fresh L2 frame for the outgoing link. That's why MAC addresses change hop-by-hop while IP addresses survive end-to-end. PDU ladder to memorize: data → segment → packet → frame → bits.

A (Bits) is incorrect — bits are the L1 PDU; hubs and repeaters live there and understand nothing. B (Frame) is incorrect — the frame is what the router removes and rebuilds; forwarding on frames/MACs is a switch's job. D (Segment) is incorrect — segments (TCP/UDP, L4) are only opened by the end hosts; a router doesn't need ports to route.

Reference: Phase 1 — PDU column · Encapsulation · s2 43

A MAN (metropolitan area network) spans a town or city — and the telco network delivering DSL across a city is the textbook example.

A (LAN) is incorrect — a LAN is privately owned and spans an office, building or campus, a few kilometers at most. C (WAN) is incorrect — WANs are long-haul: country, continent, world. D (Internetwork) is incorrect — an internetwork ("internet" with a small i) is what you get when you connect two or more networks; it describes composition, not geographic size. And the capital-I Internet is the famous global internetwork glued together by tiered ISPs.

Reference: Phase 1 — LAN, MAN, WAN · s1

L2's one job is the single hop: node to adjacent node over one link. A datagram crossing the Internet may ride a different L2 protocol on every link — WiFi, then fiber Ethernet, then something else — like a traveler using taxi → plane → train on one trip.

A is incorrect — host-to-host delivery across networks is Layer 3's job (routing). C is incorrect — process-to-process delivery with ports is Layer 4 (Phase 4). D is incorrect — turning bits into signals is Layer 1; the NIC implements both L1 and L2, but the link layer's defined services are framing, link access, error detection/correction and (on lossy links) reliable delivery.

Reference: Phase 2 — The link layer's one job · s3-p1

The lower sublayer, MAC, owns data encapsulation (framing), MAC addressing, the FCS/CRC check, and media access — who talks and when.

A is incorrect — LLC (IEEE 802.2), the upper sublayer, is the bridge between networking software and hardware: it identifies which L3 protocol is inside the frame and can offer optional services upward. Watch this one: your s3-p2 slide 8 wrongly gives framing/addressing/CRC to LLC, then slide 9 correctly gives them to MAC — answer with slide 9's version (see Appendix A). B is incorrect — that's below L2 entirely. D is incorrect — the driver is implementation plumbing, not an IEEE sublayer.

Reference: Phase 2 — LLC and MAC · Appendix A · s3-p2 8–9

A 48-bit MAC splits in half: the first 24 bits are the OUI (Organizationally Unique Identifier) — the manufacturer's code assigned by IEEE (AA-00-00 was DEC, 08-20-00 was Sun) — and the last 24 bits are a vendor-assigned serial number.

B is incorrect — the serial number is the last 24 bits (68:95:68). C is incorrect and is the trap: MAC addresses are flat — no part of them carries location or network information, which is exactly why MAC alone can't route between networks and why IP exists. D is incorrect — multicast is signaled by the I/G bit (LSB of the first octet), not by the OUI field; 6C is even, so this address is unicast anyway.

Reference: Phase 2 — MAC addresses · s2 32 · s3-p2

The rule is the I/G bit — the least-significant bit of the first octet: 0 → unicast, 1 → multicast/group. Fast test: is the first octet's value odd? 3B = 00111011 — odd → multicast.

A is incorrect — 02 is even → unicast (the 02 sets the locally administered bit, which is how phones randomize their MAC for privacy — still unicast). B is incorrect — FE = 11111110, even → unicast, despite "looking" special. C is incorrect — A4 is even → unicast. Beware the slide shortcut "unicast begins with 00 / broadcast begins with 11" — it's muddled (Appendix A); the LSB rule is the real one, and broadcast is simply all Fs: FF:FF:FF:FF:FF:FF.

Reference: Phase 2 — Three kinds of destination MAC · Appendix A · s2 34 · s3-p2 16

Decode the name as prefix–Base–suffix: 10 = 10 Mbps, Base = baseband signaling, 5 = 500 m of thick coax ("Thicknet"). Likewise 10Base2 = thin coax, 10BaseT/100BaseT = twisted pair, 100BaseFX = fiber.

A is incorrect — the speed is the prefix (10), not the suffix. B is incorrect — "Cat 5" is a cable grade for twisted pair; the T suffix denotes twisted pair, and 10Base5 predates it. D is incorrect — nothing in the identifier counts pairs. Bonus fact: every speed generation from 10 Mbps to 100 Gbps kept the same frame format — a big reason Ethernet won the LAN wars.

Reference: Phase 2 — Ethernet: the LAN that won · s3-p2

Ethernet is connectionless (no handshake between NICs) and unreliable (no L2 ACKs or NAKs): a frame that fails the FCS is dropped, no apology. If the data mattered, end-to-end recovery is TCP's problem (Phase 4).

A is incorrect — there is no NAK/retransmission machinery in Ethernet; that's a feature, not a bug (clean wired links rarely need it). C is incorrect — Ethernet's CRC-32 is used to detect errors; the receiver doesn't attempt correction, it discards. D is incorrect — corrupted frames never go upward; the whole point of checking at L2, where errors are born, is to kill them there.

Reference: Phase 2 — Ethernet character sheet · FCS · s3-p2

In Ethernet II that field is the Type (EtherType), used to hand the payload to the right L3 protocol: 0x0800 = IPv4, 0x0806 = ARP, 0x86DD = IPv6. Memorize all three — they're free marks.

B and C are incorrect — wrong EtherType values (0x0806 and 0x86DD respectively). D is the clever trap: legacy 802.3 puts a Length in this field instead, and 0x0800 is 2048 in decimal — but the disambiguation rule kills it: values ≤ 1500 are lengths, values ≥ 0x0600 (1536) are types. 2048 can't be a length anyway, since Ethernet's data field maxes out at the 1500-byte MTU.

Reference: Phase 2 — The Ethernet frame, byte by byte · s3-p2 · s2 49–56

CSMA/CD only works if the sender is still sending when news of a collision gets back to it — otherwise it would finish, hear silence, and wrongly assume success. The 64-byte minimum (6+6+2+46+4, preamble not counted) keeps the transmission long enough to cover the worst-case round trip on the maximum cable. Everything in Ethernet's design traces back to CSMA/CD.

A is incorrect — clock sync is the 8-byte preamble's job, separate from the minimum. B is incorrect — CRC-32 works over any length. C is incorrect — there's no such IP minimum driving this; the 46-byte floor is Ethernet's own, and short payloads are simply padded up.

Reference: Phase 2 — Trainer's tip under the frame table · s3-p1

TDMA pre-slices time into rounds of N fixed slots, one per station — your slot, your turn, even if everyone else is silent. A lone busy station still gets only R/N = 60/6 = 10 Mbps; the other five slots tick by empty and wasted.

A is incorrect — idle slots are not reusable in TDMA; that inflexibility is its defining weakness at low load (and exactly what random access fixes: a lone CSMA station gets the full R). C is incorrect — R/2 corresponds to nothing here. D is incorrect — the station transmits fine in its own slots; it's capped, not blocked.

Reference: Phase 2 — MAC protocol families, channel partitioning · s3-p1

The CD recipe: abort at once (why waste the channel finishing a corpse?), jam so every station notices, then draw a random delay from a window that doubles after each successive collision (binary exponential backoff) — the network self-calms under load.

A is incorrect twice over — finishing the ruined frame wastes channel time, and a fixed delay would make the same two stations collide again forever; randomness is what breaks the tie. C is incorrect — tokens belong to the "taking turns" family (Token Ring/FDDI), not CSMA/CD. D is incorrect — frequency slicing is FDMA, a channel-partitioning strategy, not Ethernet's.

Reference: Phase 2 — CSMA/CD · s3-p1

Two radio realities kill detection: a transmitting radio drowns out everything else (it can't hear a whisper of a collision while shouting), and the hidden node problem — two senders out of each other's range collide at the receiver between them without ever hearing one another. So 802.11 avoids up front: sense, back off before transmitting, confirm with link-level ACKs, optionally reserve the channel with RTS/CTS.

B is incorrect — collisions absolutely happen in radio; they're just undetectable by the sender. C is incorrect — frame size isn't the issue (that's the CD minimum-frame story on wires, Q8). D is incorrect — no tokens in 802.11. Cost of avoidance: CA pays its overhead on every frame, so it's less efficient than CD, which recovers only when something actually goes wrong.

Reference: Phase 2 — CSMA/CA, and the CD-vs-CA table · s3-p1

Arrange the data in a grid with parity per row and per column: one flipped bit trips exactly one row parity and one column parity, and their intersection locates the bad bit — flip it back. Detection and correction, no retransmission.

A is incorrect — single-bit parity detects any odd number of flips but can never say which bit; and two flips pass invisibly. (Your s3-p1 slide 13's layout makes "detect and correct" look like single-parity's property — it belongs to 2-D only; Appendix A.) C is incorrect — the checksum is a cheap 16-bit one's-complement sum; it detects weakly (two errors can cancel) and corrects nothing. D is incorrect as used — CRC-32 is by far the strongest detector here, but the Ethernet receiver responds to a failed FCS by discarding, not repairing (Q6).

Reference: Phase 2 — Error detection, 2-D parity worked example · Appendix A · s3-p1 13

The sender sums the data as 16-bit integers in one's-complement arithmetic (any carry out of the top wraps around and is added back), then transmits the complement of that sum. Adding data + complement at the receiver therefore yields all 1s when nothing changed — "probably fine."

A is incorrect — all 0s is the expected result in ordinary two's-complement schemes, but the Internet checksum's wraparound arithmetic lands on all 1s; this exact distinction is a favorite trick option. C is incorrect — remainders of a generator polynomial are CRC mechanics, not checksum. D is incorrect — counting 1s is parity. Remember the placement too: checksum lives at the transport layer (UDP/TCP), software-cheap but weak; CRC guards L2 in NIC hardware.

Reference: Phase 2 — Internet checksum · s3-p1

A is correct — "Who has 137.196.7.14?" must reach everyone, so the request goes to all Fs; the switch floods it and every NIC interrupts its OS to check. C is correct — ARP is its own EtherType (0x0806); there is no IP header on an ARP packet.

B is incorrect — the reply is unicast straight back to the asker; only the owner of the target IP answers, and the asker caches <IP, MAC, TTL> (entries age out in ~20 minutes). D is incorrect — ARP requests are L2 broadcasts and routers do not forward broadcasts: ARP stops at the subnet edge. That's precisely why a host ARPs for its default gateway when the destination is remote (Q16).

Reference: Phase 2 — ARP · s4 47–55

ARP spoofing/poisoning works because ARP has zero authentication — anyone can shout a false mapping and hosts will happily cache it, handing the attacker a man-in-the-middle position. Mitigations live in enterprise switches — Dynamic ARP Inspection, IP Source Guard — plus end-to-end encryption so intercepted traffic is useless.

A is incorrect — MAC flooding overwhelms a switch's address table to force it to flood traffic; no lying about gateways. B is incorrect — DHCP starvation exhausts a DHCP server's address pool (Phase 5 territory). D is incorrect — a Smurf attack abuses ICMP echo and broadcast amplification at Layer 3 (you'll meet ICMP in Phase 3.4).

Reference: Phase 2 — ARP security note · s4

The golden rule: L2 addresses change at every hop; L3 addresses stay the same end-to-end. A frames the packet to its gateway's MAC (learned via ARP) while the IP header carries the true final destination, B. R strips the frame, routes on the IP header, ARPs for B on the far side if needed, and re-encapsulates the untouched packet in a brand-new frame. Across two routers you'd see three frames, one unchanged packet.

A is incorrect — A cannot use B's MAC: ARP doesn't cross routers (Q14), so A can never learn it. B is incorrect — sending to R's IP would deliver the packet to R and stop; R's MAC is the courier's address, B's IP is the letter's address. D is incorrect — data frames are unicast to the gateway; only the ARP request was broadcast. (One exception changes IPs mid-path — NAT, Phase 6.)

Reference: Phase 2 — The finale: one packet, two networks · s3-p2 22–27 · s4 2–13

Best effort = unreliable by design: IP drops packets for a reason (checksum failure, TTL expiry), tells no one by itself, and moves on. Low overhead is the whole point — reliability is sold one layer up, by TCP.

A is incorrect — IP never retransmits; retransmission is TCP's job (Phase 4). B is incorrect — packets travel independently and may arrive out of order; re-ordering is also TCP's job. C is incorrect — that describes a connection-oriented protocol; IP is connectionless: no call setup, no handshake, every packet launched independently. Third adjective for the exam: media independent — IP only respects each link's MTU.

Reference: 3.1 — The Internet Protocol · s4 14–32

The ÷4 rule: four bits can only count to 15, but headers run 20–60 bytes, so IHL stores length ÷ 4. Here 4 × 4 = 16 bytes — impossible (minimum is 20 = IHL 0101), so the packet is malformed: drop it. This is the exact answer to your s4 slide-30 "why did the router drop it?" exercise.

A is incorrect — no legal IPv4 header is under 20 bytes (the fixed fields alone need 20). B is incorrect — routers validate, they don't repair. D is incorrect — Source Quench (type 4) was about congestion and is deprecated anyway (Q16 territory). Companion facts: IHL 0110 = 24 bytes → 4 bytes of options; data size = Total Length − IHL×4.

Reference: 3.1 — the ÷4 rule · s4 29–30

Max data per fragment = 1500 − 20 = 1,480 bytes. Fragment 1 carries data bytes 0–1479; fragment 2 begins at byte 1480. The offset field stores position ÷ 8: 1480 ÷ 8 = 185. (Flags: fragments 1 and 2 have M = 1; the last has M = 0.)

B (92) is incorrect — that would be ÷16; the magic multipliers are IHL ×4, Offset ×8, memorized as a pair. C (1480) is incorrect — that's the raw byte position, before the ÷8 encoding. D (1500) is incorrect — the MTU includes the header; data starts counting at 0. Two more freebies: all fragments share the same Identification, and reassembly happens only at the final destination — and in IPv6, routers never fragment at all.

Reference: 3.1 — fragmentation worked example · s4 24–26

First octet 129 sits in 128–191 → Class B, default mask 255.255.0.0 = /16. In binary the first bits are 10… — count leading 1s before the first 0: one → B. Landmarks to recognize instantly: A = 1–126, B = 128–191, C = 192–223, D (multicast) = 224–239.

A is incorrect — Class A is first octet 1–126 (not 1–127: network 0 is reserved and all of 127/8 is loopback — your decks disagree with themselves here; 1–126 is the safe exam answer, Appendix A). C is incorrect — right class, wrong mask; /24 is Class C's default. D is incorrect — Class C starts at 192.

Reference: 3.2 — classful chart · Appendix A · s6 29 · s4 40

169.254.0.0/16 is APIPA: a host that asks DHCP and hears nothing self-assigns here. Seeing 169.254.x.x is a diagnosis in itself — "my DHCP failed" — so you check the DHCP server and the path to it, not the laptop.

A is incorrect — a DHCP server hands out addresses from its configured pool; 169.254 appearing means the client gave up waiting. B is incorrect — the RFC 1918 private blocks are 10/8, 172.16/12 and 192.168/16; 169.254 isn't one of them (it's link-local). D is incorrect — IPv4 multicast is 224–239 in the first octet, and hosts don't self-number from it.

Reference: 3.2 — special and reserved addresses · s2 · s4 45

Packets to 127.0.0.1 are looped inside the OS: they exercise the TCP/IP software stack only and never touch the NIC, cable or network. That's the first rung of the diagnostic ladder: loopback → own IP → gateway → remote IP → name.

A is incorrect and is the slide trap (s2/41, s4/45 say loopback "tests the NIC" — it does not; Appendix A). The NIC is implicated only when loopback works but pinging your own real IP fails — that difference is the NIC test. C is incorrect — the gateway is two rungs later on the ladder. D is incorrect — no name was resolved; pinging a name is the DNS rung.

Reference: 3.2 — special addresses · 3.4 — the ping ladder · Appendix A

The three private blocks: 10.0.0.0/8 (anything starting 10), 172.16.0.0/12 (172.16 through 172.31 only), and 192.168.0.0/16. A is inside 10/8 ✓; C is inside 192.168/16 ✓.

B (172.32.1.1) is incorrect — one past the fence: the /12 ends at 172.31.255.255, so 172.32 is public. D (172.168.1.1) is incorrect and is the deck's own trap — it looks like a mash-up of the two private ranges, but only the second octets 16–31 are private; your s6 practice uses this address as if it were private and it is not (Appendix A). E (224.0.0.9) is incorrect — that's a Class-D multicast group (RIPv2's, in fact), not host space at all.

Reference: 3.2 — special and reserved addresses · Appendix A · s6

Work both constraints: hosts need 2^h−2 ≥ 50 → h = 6 (62 ✓; h=5 gives only 30). Host bits 6 → borrowed = 8−6 = 2 → 2² = 4 subnets ✓. Both land on /26 = 255.255.255.192: subnets at .0/.64/.128/.192, 62 usable hosts each.

A (/25) is incorrect — 126 hosts ✓ but only 2¹ = 2 subnets ✗. C (/27) is incorrect — 8 subnets ✓ but 2⁵−2 = 30 hosts ✗. D (/28) is incorrect — 14 hosts, worse still. Exam method: always convert each requirement to a bit count first, then check the other constraint.

Reference: 3.3 — the s6 48–49 worked example · s6

/20 = 255.255.240.0 → the interesting octet is the third. Magic number = 256 − 240 = 16, so subnets start at 142.14.0.0, 142.14.16.0, 142.14.32.0… The broadcast of a subnet is the next subnet's start − 1: 142.14.32.0 − 1 = 142.14.31.255. Hosts run 142.14.16.1 – 142.14.31.254 (2¹²−2 = 4,094 of them).

A is incorrect — it assumes the subnet ends inside the third octet's .16 value; the host range spills across the fourth octet, which is normal whenever the interesting octet isn't the last. C is incorrect — 142.14.32.x already belongs to the next subnet. D is incorrect — that's the broadcast of the whole unsubnetted /16.

Reference: 3.3 — Class B worked example · s6

/26 → mask octet 192 → magic = 64 → boundaries .0, .64, .128, .192. Take the largest multiple of 64 that is ≤ 137: 128. So the network is 192.168.4.128, the next subnet starts at .192, and the broadcast is .192 − 1 = .191. Usable hosts: .129–.190.

B is incorrect — 137 > 127, so it's past the .64 block entirely. C is incorrect — .255 is the broadcast of the .192 subnet (and of the whole /24), not of .128/26. D is incorrect — .192 is the next boundary; 137 < 192 so the host isn't in it. Binary check if unsure: 137 = 10001001 — subnet bits 10 → third block. The magic method and binary always agree.

Reference: 3.3 — magic number · s6

VLSM algorithm, in order: sort largest-first, size each with 2^h−2 ≥ need, allocate at the next free boundary (previous broadcast + 1). Sales 100 → /25 → .0 (.1–.126, bc .127). Engineering 50 → 2⁶−2 = 62 ≥ 50 → /26, starting at .127 + 1 = .128 (.129–.190, bc .191). Then Operations /27 at .192, WAN /30 at .224.

A is incorrect — .0/25 is Sales's block; placing Engineering there ignores the sort. B is incorrect — .64/26 sits inside Sales's /25 (.0–.127): overlap, the classic error of not allocating from the previous broadcast + 1. D is incorrect — /25 (126 hosts) is wastefully large for 50 and would leave no room for the rest; VLSM's point is the smallest mask that fits.

Reference: 3.3 — the rebuilt VLSM example (s6 70–83)

The trap is the −2. A /26 leaves h = 6 host bits → 2⁶ = 64 addresses, but two are reserved (all-zeros = network, all-ones = broadcast), so only 62 usable — one short. You must go to h = 7: /25 → 2⁷−2 = 126 usable. Exam writers set 64, 100 and 2 as requirements precisely because they straddle these boundaries (100 needs /25 not /26; 2 needs /30).

B is incorrect twice — a /26 does not have 64 usable hosts (62), and even its raw 64 addresses can't serve 64 hosts. C is incorrect — /27 has 30 usable, and "32" forgets the −2 as well. D works but wastes half the space — and its "256" also forgot the −2 (254). When two options fit, the smallest that fits is the answer.

Reference: 3.3 — trainer's tip: the three errors that kill VLSM answers · s6

Eight consecutive /24s = 2³ blocks → shorten the prefix by 3 bits: 24 − 3 = /21. Check the alignment: /21 in the third octet has magic number 8, and the range 0–7 sits exactly on one /21 block starting at 0. This is CIDR pointed outward — supernetting/route aggregation, the mechanism that keeps Internet routing tables survivable.

A (/23) is incorrect — covers only 2 of the /24s (0–1). B (/22) is incorrect — covers 4 (0–3). C (/20) is incorrect — covers 16 (0–15): it includes the eight but over-claims eight more networks the ISP may not own; aggregation must match exactly what you're entitled to advertise.

Reference: 3.3 — CIDR, the same slash pointed outward · s6

Every router decrements TTL by 1 first; at 0 the packet is destroyed and Time Exceeded, type 11 code 0 goes back to the source, carrying the dead packet's IP header + first 8 data bytes so the sender knows which conversation died. TTL exists so lost packets can't loop forever — and traceroute weaponizes exactly this behavior.

A is incorrect — a router never forwards a packet whose TTL it just reduced to 0. B is incorrect — IP is mute, but this is precisely what ICMP exists to report. D is incorrect — type 3 means delivery failed for reachability reasons (no route = code 0, no host = code 1, no listening port = code 3); TTL expiry has its own message.

Reference: 3.4 — error family · traceroute · s5 1–14 · s4 (TTL)

Routers along the path each answer the TTL-limited probes with type 11 — that's the chorus that names them. The destination host is different: the probe actually arrives, no process listens on that absurd UDP port, so the destination itself sends type 3 / code 3 — Port Unreachable. A different message type = "we've arrived."

A is incorrect — type 11 is what every intermediate router sends; it can't distinguish the final hop. B is incorrect for Unix traceroute — Echo Reply ends Windows tracert, which sends pings instead of UDP. C is incorrect — Redirect just tells a host about a better first-hop router on its own LAN. Bonus: * * * lines are hops that ignore ICMP — normal, not broken.

Reference: 3.4 — traceroute worked example · s5

ICMPv4 router discovery: routers announce with Advertisement = 9; hosts ask with Solicitation = 10. Your s5 slide 3 prints them swapped and tags them "(IPv6)" — two errors in one line (Appendix A).

B is incorrect — that's the slide's swap; don't copy it into an exam. C is incorrect for ICMPv4 — 133 (RS) / 134 (RA) are ICMPv6 Neighbor Discovery types, a different protocol with different numbers; SLAAC in 3.6 listens for type-134 RAs. Always check which ICMP the question means. D is incorrect — 8/0 are Echo Request/Reply, the ping pair, worth memorizing cold for a different question.

Reference: 3.4 — query family · Appendix A · s5 3

Longest prefix match wins, always — the most specific route is used: /24 beats /16 beats /8 beats /0. That single rule is the whole of forwarding-table lookup logic.

A and B are incorrect — both match, both lose to the more specific /24. C is incorrect and backwards — 0.0.0.0/0 has prefix length zero, so it matches everything and loses to everything; it's the "when all else fails" row (your home router's table is basically this one line pointing at the ISP). Keep the two jobs distinct too: this per-packet lookup is forwarding; routing is the slower global job of building the table.

Reference: 3.5 — the table being fought over · s9

This is count-to-infinity, DV's classic failure: A advertised "I can reach C at cost 2" without saying via whom (via B!). Poison reverse kills the lie at the source: if A routes to C through B, A must tell B "my distance to C is ∞". B then can't fall for it. The second bandage is a finite infinity — RIP defines 16 = unreachable, which both terminates the count-up and caps RIP networks at 15 hops.

A is incorrect — hot potato is inter-AS behavior: dump the packet at the nearest gateway and let the next AS worry. C is incorrect — ECMP is OSPF load-sharing across equal-cost paths. D is incorrect — aggregation shrinks route advertisements (Q13); it doesn't address loops. Remember the asymmetry: in DV, good news travels fast, bad news travels slow.

Reference: 3.5 — count-to-infinity worked example · s9

OSPF is its own transport: IP protocol 89, no ports. Its signature set: link-state, floods LSAs, every router runs Dijkstra, cost ∝ 1/bandwidth, authenticates messages, supports equal-cost multipath, scales via areas (backbone = area 0). The enterprise default.

A is incorrect — RIP runs over UDP 520, full table to neighbors every 30 s (multicast 224.0.0.9 — note your slide's "244.0.0.9" is a typo), max 15 hops, route dead after 180 s of silence. B is incorrect — BGP runs over TCP 179: path-vector, policy over cost, the inter-AS glue. D is incorrect — EIGRP is Cisco's advanced DV with partial triggered updates and DUAL backup routes; it also isn't protocol 89. The one-liner to memorize: UDP 520 = RIP · IP 89 = OSPF · TCP 179 = BGP.

Reference: 3.5 — the protocol zoo · Appendix A · s9

The checksum is gone: Ethernet's FCS already guards the frame and TCP/UDP checksum the payload, so recomputing a third checksum at every hop (TTL changes each hop, forcing recalculation!) was pure waste — removing it makes routers faster. Also gone: the fragmentation trio (IPv6 routers never fragment; sources do path-MTU discovery via ICMPv6 Packet Too Big), IHL (header is a fixed 40 bytes — not 16, whatever s10 slide 7 says; Appendix A), and Options (replaced by the Next-Header extension chain).

A is incorrect — Flow Label is the genuinely new field, tagging packets of one stream. C is incorrect — Hop Limit is TTL renamed (honestly: it counts hops, not time). D is incorrect — Traffic Class is ToS renamed. Renames survive; the checksum died.

Reference: 3.6 — the header diet · Appendix A · s10 7

Rule 1: drop leading zeros per group → 2001:db8:0:0:0:ff00:42:8329. Rule 2: replace one run of consecutive all-zero groups with :: (longest run; leftmost on a tie) → 2001:db8::ff00:42:8329.

A is incorrect — two :: in one address is illegal (ambiguous: you couldn't tell how many zero groups each hides). C is incorrect — it turned ff00 into ff, dropping trailing zeros inside a group; only leading zeros may go. D is incorrect as "fully compressed" — it's a legal address but keeps 0db8's leading zero, 0042's, and spells out the zero run instead of using ::. Decompression tip: count the groups present; :: stands for 8 − that count.

Reference: 3.6 — the two compression rules · s10

fe80::/10 = link-local: mandatory on every IPv6 interface, auto-generated, and confined to its own link — all the neighbor plumbing (ND, routing-protocol hellos, your default gateway's address) runs on it. This host can talk to its router on the link, but cannot browse the IPv6 Internet until it gains a global address (via SLAAC — hearing an ICMPv6 type-134 RA — or DHCPv6).

A is incorrect — global unicast is 2000::/3 (starts with 2 or 3). B is incorrect — multicast is ff00::/8; all-nodes is ff02::1 (and remember: IPv6 has no broadcast at all — multicast took over the job). C is incorrect — unique local is fc00::/7, in practice fd00::/8. Sight-recognition list: 2/3 → GUA · fe8 → link-local · fd → ULA · ff → multicast · ::1 → loopback.

Reference: 3.6 — address types · s10

The four operations are addressing end devices, encapsulation, routing, and de-encapsulation at the destination. Guarantees are deliberately absent — IP is best effort: no ACKs, no retransmission, ever.

A, B and C are all incorrect as answers because each is one of the four (the fourth being de-encapsulation, the mirror of B). If a question pairs "IP" with any reliability verb — acknowledge, retransmit, guarantee, order — the pairing is wrong; those verbs belong to TCP, one layer up.

Reference: 3.1 — Why IP exists · s4 14–17

Connectionless = no setup, no state, no promises: every packet is an independent event, routed on its own, possibly along different paths as tables change — which is also why arrival order isn't guaranteed.

B is incorrect — virtual circuits are the connection-oriented model (think old telephone networks), the opposite design. C is incorrect — the famous handshake (SYN, SYN-ACK, ACK) is TCP's, at Layer 4; nothing at the IP layer shakes hands. D is incorrect — same-path and in-order are exactly the guarantees connectionless service refuses to make.

Reference: 3.1 — IP's personality · s4 18–20

The MTU — the largest packet the link will carry (1,500 bytes on Ethernet) — is the single constraint L2 imposes upward. A packet bigger than the next link's MTU must be fragmented (IPv4, Q9–12) or, in IPv6, dropped so the source can resize.

A is incorrect — encoding is Layer 1's private business; IP never sees it. B is incorrect — duplex is a link-operation detail handled entirely at L1/L2. D is incorrect — MAC formats matter to the frame, and the whole point of Phase 2's finale is that the frame is rebuilt per hop while the packet rides along unchanged.

Reference: 3.1 — IP's personality · s4 21–23

Header = IHL × 4 = 7 × 4 = 28 bytes (so 28 − 20 = 8 bytes of options). Total Length counts header plus data, so data = 100 − 28 = 72 bytes. This is the exact exercise in your s4 slide-29 speaker notes.

A (80) is incorrect — it subtracts the 20-byte minimum header, forgetting that IHL = 7 means options are present. C (100) is incorrect — Total Length is never pure data; it always includes the header. D (64) is incorrect — no rule produces it; if you got 64, you likely subtracted IHL×4 twice. Anchors to memorize: IHL 0101 = 20 B (no options), 0110 = 24 B, maximum 1111 = 60 B.

Reference: 3.1 — the ÷4 rule · s4 29

16 bits count from 0 to 2¹⁶ − 1 = 65,535. That's the ceiling on an entire IPv4 packet — though anything near it will be fragmented mercilessly on real links.

A (1,500) is incorrect — that's Ethernet's MTU, a property of one link type, not of IP itself; the exam loves testing whether you separate the two ceilings. B (65,536) is incorrect — off by one: 2¹⁶ is the number of values, and counting starts at 0. C (4,096) is incorrect — that's 2¹², an unrelated landmark from your powers-of-2 table.

Reference: 3.1 — field notes · Appendix B formulas · s4 28

TTL is a hop counter wearing a time-based name: each router decrements it; the router that reaches 0 destroys the packet and reports back with ICMP Time Exceeded (type 11). Without it, a routing loop would circulate packets eternally. IPv6 fixes the dishonest name: the same field is called Hop Limit.

A is incorrect — no clock is involved; "time" is historical wording. C is incorrect — fragmentation is governed by the Identification/Flags/Offset trio, not TTL. D is incorrect — priority hints live in the Type of Service / DSCP field. Practical bonus: received-TTL values near 64/128/255 hint at the sender's OS (Linux/Windows/network gear).

Reference: 3.1 — field notes · 3.4 — Time Exceeded · s4 27

The Protocol field is L3's "what's inside" pointer — the same idea as Ethernet's EtherType, one layer up. The trio to know cold: 1 = ICMP, 6 = TCP, 17 = UDP (and 89 = OSPF for Phase 3.5).

A is incorrect — TCP is protocol 6. B is incorrect — ICMP is protocol 1 (and remember, ICMP rides inside IP yet counts as an L3 protocol — the network layer talking about itself). D is incorrect — OSPF is 89, the "no TCP, no UDP" routing protocol from the zoo table. Every layer needs this pointer: EtherType at L2, Protocol at L3, port numbers at L4.

Reference: 3.1 — field notes · Appendix B protocol numbers · s4 27

The three flag bits: bit 0 reserved (always 0), bit 1 = Don't-fragment, bit 2 = More-fragments-follow. M = 1 says exactly what it names: at least one more fragment of this packet is behind this one. D = 0 simply means fragmenting was permitted.

A is incorrect — the last fragment is the one with M = 0 and a non-zero offset (Q11). C is incorrect — "never fragmented" is M = 0 and Offset = 0 (Q10); an M of 1 proves fragmentation happened. D is incorrect — nothing here is malformed; corruption verdicts come from the checksum or an impossible IHL, not from the flags.

Reference: 3.1 — field notes, Flags · s4 24–26

Each fragment gets its own 20-byte header, so max data per fragment = 1500 − 20 = 1,480. Split 4,000 bytes: 1,480 + 1,480 + 1,040 → three fragments (offsets 0, 185, 370; M = 1, 1, 0). All three carry the same Identification so the destination can group them.

A (2) is incorrect — 4020 ÷ 1500 ≈ 2.7 tempts a floor to 2, but two fragments carry at most 2,960 data bytes: not enough. The correct mental step is ⌈4000 ÷ 1480⌉ = 3. C (4) is incorrect — three suffice; a fourth would carry nothing. D is incorrect — 4,020 is far below the 65,535 ceiling (Q5); the MTU is a per-link limit, not a validity limit.

Reference: 3.1 — fragmentation worked example · s4 24–25

Read the two fields together: Offset = 0 → "my data starts at byte 0" (the beginning); M = 0 → "nothing follows me". Starts at the start and nothing follows = the entire original packet. This is the normal state of most traffic.

A is incorrect — a true first fragment has Offset = 0 but M = 1 (more behind it). B is incorrect — a last fragment has M = 0 but a non-zero offset (its data starts deep in the payload). D is incorrect — the combination is not only legal, it's the default for unfragmented packets. This exact teaser is on your s4 slide 26.

Reference: 3.1 — reading practice · s4 26

Two decodes: M = 0 with a non-zero offset → last fragment. Offset stores position ÷ 8, so the data starts at 5 × 8 = byte 40. (This also tells you the fragments before it carried exactly 40 data bytes total.)

B is incorrect — it forgets the ×8: the field's value is never the raw byte position; a 13-bit field couldn't span 65,535 bytes otherwise. That's also why every fragment except the last must carry a multiple of 8 data bytes. C is incorrect — first fragments have Offset = 0. D is incorrect — a middle fragment would have M = 1. Keep the pair straight: IHL ×4, Offset ×8.

Reference: 3.1 — fragmentation worked example · trainer's tip · s4 26

IPv4 reassembly happens once, at the final destination, which collects fragments by their shared Identification and stitches them with the offsets. Routers never reassemble — they'd need to buffer and wait for stragglers that might take other paths entirely (IP is connectionless, Q2).

A is incorrect — hop-by-hop reassembly would destroy the performance IP exists to provide, and fragments may not even share a path. B is incorrect — the sender may never learn fragmentation occurred (with D = 0 it isn't told). C is incorrect — a router with a roomy link just forwards the fragments as-is; nothing merges them mid-path. Contrast for 3.6: IPv6 removes router fragmentation altogether — the source sizes packets via path-MTU discovery.

Reference: 3.1 — fragmentation worked example · 3.6 — the header diet · s4 24–26

Network = address AND mask. Because 1 AND x = x and 0 AND x = 0, the mask's 1s let network bits survive while its 0s zero out the host bits: 192.240.33.91 AND 255.255.255.0 = 192.240.33.0 (your s6 slide-36 rep exactly).

B is incorrect — an address with a non-zero host portion names a host, never the network itself. C is incorrect — OR with the mask would force all network bits to 1: nonsense. D is incorrect — ANDing with the inverted mask extracts the host portion; and .255 here is the broadcast, obtained by setting host bits to 1, not by that operation on the network bits.

Reference: 3.2 — the mask and the AND operation · s6 35–36

The four landmarks: network (host bits all 0 → .0), first usable (.1), last usable (.254 = broadcast − 1), directed broadcast (host bits all 1 → .255). The all-ones pattern means "every host here at once", so no single host may own it — it's one of the two addresses the −2 in 2^h−2 pays for.

A is incorrect — all-zeros is the network address, the other reserved landmark. B is incorrect — .1 is fully assignable; giving it to the gateway is convention, not reservation. C is incorrect — .254 is the last usable host, one below the broadcast.

Reference: 3.2 — the four landmarks · s6

Every network burns exactly two patterns: all-zeros names the network itself, all-ones is its directed broadcast. Everything between is assignable. That's why /24 gives 2⁸−2 = 254 and why "need 64 hosts" forces /25, not /26 (62).

A is incorrect — gateways and DNS servers use ordinary usable addresses; .1 for the gateway is mere convention. C is incorrect — first and last usable are exactly that: usable. D is incorrect — loopback (127/8) and APIPA (169.254/16) are global special blocks, not per-subnet reservations.

Reference: 3.2 — the formula of the course · s6

First octet 200 sits in 192–223 → Class C (default /24). Binary shortcut: count leading 1s before the first 0 — 200 = 11001000, two leading 1s → C.

A is incorrect — 88 < 128 → Class A (leading bit 0). B is incorrect — 129 is in 128–191 → Class B (leading bits 10). D is incorrect — 230 is in 224–239 → Class D multicast: not host space at all, no mask, no hosts. The instant-recognition landmarks: 126 | 128 | 191 | 192 | 223 | 224.

Reference: 3.2 — classful chart · trainer's tip · s6 29–31

Class A uses 7 network bits → 2⁷ = 128 defined networks, but two are lost: network 0 is reserved, and the entire 127.0.0.0/8 block is loopback. Usable first octets run 1–126.

A is incorrect — 254 is the hosts in a /24, a different formula entirely. B is incorrect — 127 counts 1–127, but 127 itself is loopback, not assignable network space. C is incorrect — 128 is the theoretical 2⁷ before reservations. Your decks disagree with themselves here (s2/37 and s4/40 say "1–127", s6/29 says "1–126") — 1–126 is the safe exam answer (Appendix A).

Reference: 3.2 — classful chart · Appendix A · s6 29

Class B's default mask is /16 → 16 host bits → 2¹⁶ − 2 = 65,534. Companion number: there are 2¹⁴ = 16,384 Class B networks (two leading bits fixed at 10, fourteen free).

A is incorrect — 16,382 misuses the network exponent (2¹⁴−2); the −2 applies to hosts, and 14 bits was the network count anyway. B is incorrect — 65,536 forgets the −2 (network + broadcast). D is incorrect — 2¹⁸−2 corresponds to no classful boundary. Watch the superscript damage in your extracted notes: "2¹⁶" flattened to "216" — re-insert the power whenever a bare number looks absurd (Appendix A).

Reference: 3.2 — classful chart · s6

Classful offered only three sizes: 254, 65,534, or 16,777,214 usable hosts. 300 > 254, so the company takes a whole Class B and strands ~65,000 addresses. That systemic waste is precisely why CIDR (1993) made the prefix free-moving — today an ISP could hand over a /23 (510 hosts) and be done.

A is incorrect — Class C tops out at 2⁸−2 = 254 usable: 300 doesn't fit. B is incorrect for the era — a /23 is the right modern answer, but supernetting two Cs is CIDR thinking; in the classful world masks were fixed by class. C is incorrect — no such reservation existed; Class A went to giant early adopters.

Reference: 3.2 — classful history · 3.3 — CIDR · s6

Directed broadcast = host-bits-all-1 of a named network — it addresses every host of that particular network. Limited broadcast = all 32 bits set — "everyone on this wire", used when a host doesn't even know what network it's on (DHCP discovery will use it in Phase 5). Routers never forward the limited broadcast, and as your slides put it: IP broadcasts die at the router, same as ARP.

A is incorrect — one names a specific network's hosts, the other is network-agnostic and purely local. C is incorrect and backwards-dangerous — 255.255.255.255 is never forwarded anywhere. D is incorrect — both are L3 addresses; the L2 broadcast is FF:FF:FF:FF:FF:FF (a frame that often carries these packets, but a different layer's concept).

Reference: 3.2 — special addresses · delivery types · s4 44–46

Class D (first octet 224–239, leading bits 1110) is multicast: destination-only group addresses — no masks, no hosts, never a source. RIPv2's group is 224.0.0.9; routing protocols love these well-known groups.

A is incorrect — 224.0.0.5 (with .6) belongs to OSPF. B is incorrect and is your s2 slide-40 typo immortalized: "244.0.0.9" — 244 falls in Class E (240–255, reserved/experimental, never assigned); the real first octet is 224 (Appendix A). D is incorrect — 239 is Class D territory, but the label "Class C" is wrong and the address isn't RIP's.

Reference: 3.2 — special addresses · 3.5 — RIP · Appendix A · s2 40

A packet is always from exactly one interface, so only a unicast address can be a source. Multicast (one-to-group) and broadcast (one-to-all) are destination-only concepts — "from everyone" is meaningless.

B and C are incorrect — a multicast source would claim the packet came from a whole group at once; receivers reply to groups' traffic via the sender's unicast address. D is incorrect — a broadcast source is equally impossible (and is a classic signature of forged/malformed traffic; recall the Smurf-style abuse pattern from the Layer 2 set). Same asymmetry you learned for MACs in Phase 2 — the rule survives the layer change.

Reference: 3.2 — the three delivery types · s4 44

Loopback proves the software stack works (it never touches hardware). The next rung — your own real IP — is the first test that involves the interface. Stack ✓ + interface ✗ = the fault lives in the NIC/driver/cable zone. This difference between two pings is the real "NIC test" your slides mislabeled loopback as (Appendix A).

A is incorrect — a broken stack would fail the loopback ping too. B is incorrect — DHCP problems announce themselves as a 169.254.x.x address, and a missing lease wouldn't make your own-IP ping fail this way. C is incorrect — the gateway isn't consulted until you ping off-subnet; both of these pings stay local. Full ladder: loopback → own IP → gateway → remote IP → name.

Reference: 3.2 — loopback trap · 3.4 — the ping ladder · Appendix A

10.0.0.0/8 is one of the three RFC 1918 private blocks (with 172.16.0.0/12 and 192.168.0.0/16) — free for anyone's internal use, and by agreement not routable on the public Internet. Since everyone may be using 10.0.5.9 internally, no public router can know whose it is. The way out is NAT (Phase 6), translating private ↔ public at the edge — private space is NAT's raw material.

A is incorrect — multicast is 224–239 in the first octet. B is incorrect — public Class A space routes fine; it's this specific block, not the class, that's private. D is incorrect — APIPA is 169.254.0.0/16, a different diagnosis entirely.

Reference: 3.2 — special addresses · s6 · Phase 6 (NAT)

Subnetting never adds addresses — it costs them: every subnet you create burns two more (its own network + broadcast), and it adds the price of routers between the pieces. You subnet despite that, for the other three reasons.

A is incorrect as an answer because it's the headline benefit — one flat network means every ARP request interrupts every host; 1,000 machines hear 1,000 machines' broadcasts. B is incorrect — organizational grouping is a core motive. C is incorrect — routers between subnets are natural places to apply rules; that's the security motive.

Reference: 3.3 — why subnet at all · s6

/24 → /27 borrows 3 bits: 2³ = 8 subnets. Host bits left h = 5: 2⁵ − 2 = 30 usable each. Mask 255.255.255.224, magic 32 → subnets at .0, .32, .64 … .224.

A is incorrect — that's /26 (borrow 2). B is incorrect — 32 forgets the −2; each subnet still pays its network and broadcast. D is incorrect — "6" subtracts 2 from the subnet count; the −2 applies to hosts only (the old "subtract 2 subnets" rule belongs to a pre-CIDR convention your course doesn't use — the deck's own examples count all 2^b).

Reference: 3.3 — the one move behind everything · s6

/28 = four bits borrowed past /24 → mask octet 240 (11110000). Magic number = 256 − 240 = 16: subnets start at .0, .16, .32 … Each block spans 16 addresses, of which 14 are usable (2⁴−2).

A is incorrect — 224 is /27 (blocks of 32). B is incorrect — 248 is /29 (blocks of 8). C is the subtle trap — 14 is the usable-host count, not the block size; boundaries step by the full 16. Mixing those two numbers up misplaces every boundary that follows.

Reference: 3.3 — the magic number · s6

/22 = 255.255.252.0 → interesting octet is the third. Magic = 256 − 252 = 4: boundaries at 0, 4, 8, 12, 16, 20… Largest multiple of 4 ≤ 19 is 16 → network 172.16.16.0. Next subnet starts at 172.16.20.0, so broadcast = 172.16.19.255. Hosts: 172.16.16.1 – 172.16.19.254 (1,022 of them).

B is incorrect — it treats the address's own third octet as a boundary; 19 is not a multiple of 4. C is incorrect — the range spills across third-octet values 16–19; ending it at .16.255 forgets the spillover. D is incorrect — that's the next block (20–23); our host's 19 is below it.

Reference: 3.3 — Class B worked example · s6

With /20 the boundaries fall at third-octet multiples of 16: …16.0, 32.0, 48.0… 142.14.33.0 is inside the 32.0 subnet, and its 12-bit host portion (third-octet remainder 1 + fourth octet 0) is not all zeros → a perfectly legal host. The rule is "host portion all-zeros forbidden," not "fourth octet zero forbidden."

A is incorrect — that folk rule only holds when the mask is exactly /24. C is incorrect — the network address here would be 142.14.32.0; one octet-value later is inside the block. D is incorrect — this subnet's broadcast is 142.14.47.255 (next boundary − 1). This exact bait-and-switch is in your s6 check-yourself — exam writers love it.

Reference: 3.3 — check yourself, the boundary trick · s6

Smallest b with 2^b ≥ 6 → b = 3 (2² = 4 is short, 2³ = 8 covers it). That yields /27: h = 5 → 2⁵−2 = 30 usable hosts per subnet, boundaries every 32. You get 8 subnets; the 2 spare are free growth.

A is incorrect — 4 < 6; the requirement isn't met. C is incorrect — 32 is the block size; usable hosts are 32 − 2 = 30. D is incorrect — 64 subnets vastly overshoots and shrinks every subnet to /30-size for no reason; borrow the smallest b that satisfies the constraint.

Reference: 3.3 — two directions the exam asks from · s6

2^h−2 ≥ 500 → h = 9 (2⁹−2 = 510 ✓; h = 8 gives 254 ✗). Mask = 32 − 9 = /23 = 255.255.254.0 — magic 2 in the third octet: subnets at 172.16.0.0, 172.16.2.0, 172.16.4.0… That's 2⁷ = 128 subnets of 510 hosts.

A is incorrect — /22 (1,022 hosts) works but wastes double the space; when multiple masks fit, take the longest that satisfies the need. B is incorrect — /24 gives 254 < 500. D is incorrect — /25 gives 126, worse still. The reflex: convert the host requirement to h first, then subtract from 32.

Reference: 3.3 — "I need N hosts" · s6

Hosts first: 2^h−2 ≥ 1000 → h = 10 (1,022). Mask = /22, so borrowed = 22 − 16 = 6 → 2⁶ = 64 subnets (magic 4: 172.16.0.0, 172.16.4.0, 172.16.8.0…). This is the s6 check-yourself item worked to its second half.

A is incorrect — 4 would mean borrowing 2 bits → /18 → 16,382 hosts each: legal but not what the arithmetic yields, and the question asks what results from the tightest fit. B is incorrect — 16 = 2⁴ assumes /20, whose 4,094 hosts overshoot the need by 4×. D is incorrect — 1,024 confuses 2¹⁰ (the host-side power) with the subnet count; the two exponents always split the 16 available bits: 6 + 10.

Reference: 3.3 — check yourself · s6

Beyond /30 the modern world has /31 (RFC 3021 — standard on router-to-router links: 2 addresses, both usable, no network/broadcast reserved) and /32 (a host route naming exactly one address). Your s6 slide 44 also declares "all subnets must be equal size" — which the deck's own VLSM section then breaks on purpose (Appendix A). Know which world a question lives in: classful questions get classful answers.

A is incorrect as an answer — bit-borrowing is the mechanism in every era. C is incorrect — 2^b growth is arithmetic, not policy. D is incorrect — unequal sizes are VLSM's entire point, and modern practice.

Reference: 3.3 — the legacy-rules trap · Appendix A · s6 44

A /30 block spans 4 addresses; minus network and broadcast leaves exactly 2 usable — one per router interface. /31 drops the two reservations for point-to-point links, so its 2 addresses are both assignable: zero waste. (In your VLSM allocations, links sized "2 hosts" take /30 — that's what the course expects.)

B is incorrect — nothing requires /29's 6 usable for a two-interface link; VLSM's ethos is the smallest fit. C is incorrect — /30's usable count is 2, not 4; the 4 is raw block size. D is incorrect — /32 is a host route to a single address; two routers on one subnet can't share a /32.

Reference: 3.3 — legacy-rules trap · VLSM example · s6

Run the algorithm: sort largest-first, size each, allocate at broadcast + 1. A: 60 → /26 at .0 (bc .63). B: 28 → /27 at .64 (bc .95). C: 12 → 2⁴−2 = 14 ≥ 12 → /28 at .96 (hosts .97–.110, bc .111). Then the links: /30 at .112 and /30 at .116. Free: .120–.255.

A is incorrect — .64/27 is B's block. C is incorrect — right address, wrong mask: /27 (30 hosts) over-serves 12 when /28 (14) fits; VLSM takes the smallest fit. D is incorrect — .112 is where the first WAN /30 lands after C is placed; giving it to C skips the .96 boundary for no reason.

Reference: 3.3 — VLSM worked example & check yourself · s6 70–83 (rebuilt)

Two rules broken at once. First, the next block starts at the previous subnet's broadcast + 1 — .127 still belongs to Sales. Second, every subnet must start on a multiple of its own size: a /26 (64 addresses) can only begin at .0, .64, .128, .192 — and .127 is none of them. The correct allocation is 192.168.10.128/26.

A is incorrect — .127 is inside Sales's block, not free. B is incorrect and is the guide's flagged classic error #2 — starting at the previous last host double-books two addresses. C is incorrect — smaller-after-larger is exactly how VLSM works; size ordering matters only for choosing placement, and largest-first was respected here.

Reference: 3.3 — trainer's tip: the three errors that kill VLSM answers · s6

/23 leaves h = 9 host bits → 2⁹ − 2 = 510. This is CIDR pointed inward-from-outside: two Class-C-sized blocks fused (third octets 112 and 113 — magic number 2, so /23s start on even third octets), one prefix, no class implied. The slash says everything the first octet used to.

A is incorrect — 254 reads the address classfully as a /24; CIDR's whole point is that the class chart no longer dictates the mask. C is incorrect — 512 is the raw block size before paying the −2. D is incorrect — 1,022 is a /22. Alignment habit worth keeping: a /23 anchored at an odd third octet (say ".113.0/23") is invalid — every prefix must start on a multiple of its own block size, a detail exam writers probe.

Reference: 3.3 — CIDR · s6

Four /24s = 2² blocks → shorten by 2 bits: /22. Alignment check: /22 blocks start at third-octet multiples of 4, and 4 is one → 172.20.4.0/22 spans exactly 4.0 – 7.255. One route replaces four — supernetting, the mechanism that keeps Internet tables survivable.

B is incorrect — 172.20.0.0/22 covers 0–3, the previous block; right mask, wrong anchor. C is incorrect — a /23 covers only two of the four (4–5). D is incorrect — a /21 covers eight (0–7 — note it must anchor at 0): it includes the four but over-claims four more networks you may not own. Aggregate exactly what you're entitled to advertise.

Reference: 3.3 — CIDR, supernetting · Appendix E Q13 · s6

ICMP is the odd one: it rides inside IP yet counts as Layer 3 — the network layer talking about itself. And its powers stop at speech: it reports ("your packet died, here's why") and answers ("yes, I'm alive"); recovery is the sender's problem, usually TCP's, one layer up.

A is incorrect — encapsulation position doesn't set the layer; ICMP serves the network layer's needs, not process-to-process delivery. C is incorrect — nothing at L3 retransmits; IP stays best-effort even with ICMP bolted on. D is incorrect — ARP is the L2/L3 glue with its own EtherType; ICMP lives a layer above it, inside IP.

Reference: 3.4 — why ICMP exists · s5 1–3

Ping sends Echo Request, type 8; the target answers Echo Reply, type 0. Memorize the direction cold — "8 out, 0 back" — because option A's swap is the standard trick.

A is incorrect — exactly backwards. B is incorrect — 13/14 are the timestamp pair, for clock-difference probing, not ping. C is incorrect — 9/10 are router discovery (and note they're a different question's trap: your slide swaps them). Bonus reading skill: the reply's TTL hints at the answering OS — starting values ≈ 64 (Linux), 128 (Windows), 255 (network gear).

Reference: 3.4 — query family · ping · s5 3–5

Type 3's codes tell you how far the packet got: code 0 = a router had no route (network not found) · code 1 = network found, host silent — our case · code 3 = host reached, but no process listens on that port. The failure climbed one level deeper each time.

A is incorrect — routing succeeded here; the network was reached. B is incorrect — code 3 requires the host to be alive and answering; here it never responded at all (and code 3 is sent by the destination itself). D is incorrect — type 11 is about TTL/reassembly timers, not reachability.

Reference: 3.4 — error family table · s5 6–8

Port unreachable means the packet completed its entire network journey — every router forwarded it, the destination received it — and only then failed, because no process listens on that port. Only the destination host can know that, so only it sends 3/3. That's exactly why Unix traceroute treats 3/3 as "we've arrived."

A is incorrect — routers know about networks and hosts (codes 0 and 1); they never see ports, which are L4 information beyond their job. C is incorrect — the gateway is just the first of those routers. D is incorrect — DNS translates names before any of this; it plays no role in delivery errors.

Reference: 3.4 — error family · traceroute · s5

Source Quench is the syllabus's fossil: sending extra packets into a congested network to fight congestion made things worse, so RFC 6633 retired it — routers must not send type 4 and hosts ignore it. Senders discover congestion implicitly (loss, delay) and TCP backs off. On a purely historical exam question, describe type 4 — then note it's retired.

A is incorrect for the modern world — that's the deprecated behavior. B is incorrect — Redirect optimizes a host's first-hop choice on its own LAN; nothing to do with congestion. D is incorrect — type 12 reports a malformed header, not an overloaded queue.

Reference: 3.4 — error family table · s5 7

Redirect is advice, not rejection: R1 still forwards the current packet (no data is lost), and separately tells H "there's a better first-hop router for that destination on your own LAN — use R2." H updates its choice for subsequent packets.

B is incorrect — dropping would punish H for R1's superior knowledge; the packet is deliverable and gets delivered. C is incorrect — R1 does relay this packet onward, but the point of type 5 is to stop being the middleman; staying silent would leave H dog-legging traffic forever. D is incorrect — nothing is unreachable; R1 has a perfectly good route, just not the best first hop for H.

Reference: 3.4 — error family table, Redirect · s5

Type 11 has two flavors of "time ran out": code 0 — TTL hit zero in transit (a router's message, traceroute's engine) · code 1 — the fragment-reassembly timer expired at the destination, which then discards the partial packet and reports. Incomplete puzzles don't wait forever.

A is incorrect — code 0 belongs to routers decrementing TTL; this packet arrived, in pieces. B is incorrect — ports were never consulted; reassembly failed below that. C is incorrect — no header field is malformed; a piece is simply missing. Tie-in to 3.1: reassembly happens only at the destination — which is exactly why this timer lives there.

Reference: 3.4 — error family table · 3.1 — fragmentation · s5

These rules exist to stop error avalanches. A: an error about an error about an error… would loop forever, so ICMP errors are never generated about ICMP errors. C: one broadcast triggering an error from every receiver would amplify a single packet into a storm, so broadcast/multicast destinations never spawn errors. Third rule in the same family: only the first fragment of a fragmented packet can trigger an error.

B is incorrect as an answer — TTL expiry is precisely when Time Exceeded (11/0) is sent. D is incorrect — a dead UDP port is exactly when Port Unreachable (3/3) is sent.

Reference: 3.4 — sanity rules kfact · s5

Header + first 8 payload bytes is a forensic fingerprint: the IP header names source, destination and protocol, and the first 8 bytes of a TCP/UDP segment contain the port numbers — together, exactly enough for the sending host to match the corpse to the connection that produced it.

B is incorrect — carrying whole packets would make error traffic as heavy as the failure it reports; and retransmission is the sender's decision, not the router's service. C is incorrect — with no quoted content, the sender couldn't tell which of its packets died. D is incorrect — the first 8 bytes are the useful ones (ports live there); the last bytes identify nothing.

Reference: 3.4 — sanity rules kfact · s5

The two failures differ in who spoke. Timed out = total silence — the echo request (or its reply) vanished; causes range from a dead host to a firewall silently discarding ICMP, which is common and why "no ping" never proves "no host." Destination unreachable = a voice answered — a router sent type 3 saying it had nowhere to forward the packet. Silence vs. an explicit "no."

A is incorrect — one is absence of evidence, the other is evidence of a routing gap. B is incorrect — exactly reversed. C is incorrect — slow responses show up as high time= values (RTT), not as unreachable errors.

Reference: 3.4 — ping · s5

Each hop gets three probes (three RTT samples); * * * means all three went unanswered. But hops 4+ did answer — and their probes passed through hop 3 — so hop 3 is forwarding perfectly and merely declines to send Time Exceeded messages (many routers deprioritize or suppress ICMP generation). Diagnosis skill: rising latency between two answering hops localizes where slowness lives — that's how "the Internet is slow" becomes "hop 3 is slow."

A is incorrect — a dead hop 3 would strand every later probe too. B is incorrect — loops show as repeating router addresses, not stars. D is incorrect — MTU problems affect large packets, and would not selectively mute one hop's ICMP.

Reference: 3.4 — traceroute worked example · s5

Both tools share the TTL trick — probes with TTL 1, 2, 3… force each router in turn to confess via Time Exceeded (11). They differ only in the probe: tracert sends pings, so the destination (which doesn't discard — it answers) returns Echo Reply, type 0. Unix traceroute sends UDP to an absurd port, so its finish line is Port Unreachable, 3/3. Either way, a different message type = "we've arrived, stop."

B is incorrect — 3/3 requires a UDP probe to a dead port; pings never produce it. C is incorrect — classic tracert doesn't use TCP. D is incorrect — ARP is confined to the local subnet; it can't probe across routers at all (Phase 2).

Reference: 3.4 — traceroute, step 3 · Appendix E Q15 · s5

The analogy from your deck: forwarding is a driver obeying the signs at one intersection; routing is the city planning department deciding what all the signs should say. Blurring these two costs marks — exam questions often hinge on which job is being described.

A is incorrect — one is per-packet and local, the other global and comparatively slow. B is incorrect — exactly swapped. D is incorrect — every packet is forwarded the same way regardless of how its route entered the table; static vs dynamic describes table-building methods only.

Reference: 3.5 — two jobs, don't blur them · s9

The three sources, in the order you meet them: directly connected — the router sees the network on its own interface, automatic, no configuration; static — an admin typed it (zero overhead, zero adaptability — fine for stub networks and tiny sites, unmaintainable at scale); dynamic — a routing protocol learned it and keeps re-learning it.

A is incorrect — nothing was typed; the interface's existence creates the route. C is incorrect — no protocol was needed to discover a wire the router is plugged into. D is incorrect — the default route is the specific prefix 0.0.0.0/0, the matches-everything, loses-to-everything fallback row.

Reference: 3.5 — the table being fought over · s9

The relax step after settling node n: for each neighbor, D(candidate) = min( current D, D(n) + c(n → candidate) ). Through x: 1 + 3 = 4 < 5, so D(w) improves to 4, p(w) = x — and in the next steps it improves again to 3 via y before settling. The two exam habits: settle exactly one node per row (the cheapest unsettled), and re-examine only the neighbors of the node just settled.

B is incorrect — improving neighbors' estimates is the entire point of settling a node. C is incorrect — link cost alone ignores the cost of reaching x first (D(x) = 1 must be added). D is incorrect — estimates only ever tighten; they never reset.

Reference: 3.5 — the full Dijkstra table, step 0→1 · s9 8–15

The forwarding table stores only the first hop: walk the predecessor chain backwards — z ← y ← x ← u — and keep the link leaving u: (u, x). In this graph every destination except v funnels through x; one cheap link carrying almost everything is typical.

A is incorrect — v is the first hop only for traffic to v (its chain is v ← u directly). B is incorrect — the direct u–w link costs 5 and lost to the u–x–y–w path (cost 3); "direct" is not "shortest." D is incorrect — z settled at cost 4 (2 to y via x, +2 to z); everything is reachable here.

Reference: 3.5 — reading u's forwarding table off the predecessors · s9

D_x(N) = min over each neighbor v of [ c(x,v) + D_v(N) ] — "the best of (cost to reach a neighbor + that neighbor's claim)". Here: via v1 = 2 + 3 = 5; via v2 = 1 + 3 = 4. x keeps 4 and, because its estimate changed, sends its updated vector to its own neighbors — that ripple is how DV converges.

A is incorrect — 3 is the neighbors' claim; x still has to reach a neighbor, so the link cost always adds. C is incorrect — 5 is the losing candidate; min() keeps the best. D is incorrect — paths compete, they never add. Note what x does not know: the map. DV routers know only claims — which is exactly the weakness Q7 exploits.

Reference: 3.5 — Bellman-Ford kfact · s9

RIP is the simple, chatty one: gossip the whole table every 30 seconds (≤ 25 routes per message), count hops, declare anything beyond 15 unreachable, declare a neighbor's route dead after 180 silent seconds. Small networks only — but its numbers are exam gold.

A is incorrect — that's OSPF's row of the zoo table. B is incorrect — that's EIGRP. C is incorrect — that's BGP. One more RIP detail worth a mark: the multicast group is 224.0.0.9 — your slide's "244.0.0.9" is a typo (Appendix A).

Reference: 3.5 — the protocol zoo · Appendix A · s9

RIP defines a finite infinity: 16 = unreachable. It exists to terminate count-to-infinity — when the A–B count-up starts after a link failure, it at least stops at 16 instead of running forever. The same constant is also poison reverse's vocabulary ("my distance to N is ∞") and the reason a RIP network can span at most 15 hops.

A is incorrect — 15 is the last reachable hop count; 16 crossed the line by definition. B is incorrect — lower metrics win in RIP; 16 is the worst possible news. D is incorrect — metric 16 is a perfectly valid message with a defined meaning: forget that route.

Reference: 3.5 — count-to-infinity bandages · s9

A is correct — that's the link-state recipe: global knowledge, local computation. C is correct — cost ∝ 1/bandwidth means fast links attract traffic. The rest of OSPF's signature: rides directly in IP (protocol 89, no ports), authenticates its messages, supports equal-cost multipath, and scales via areas (Q9). The enterprise standard.

B is incorrect — periodic full-table dumps are RIP's habit; OSPF floods small LSAs when things change. D is incorrect — TCP 179 is BGP's; OSPF needs no transport protocol at all. Keep the one-liner straight: UDP 520 = RIP · IP 89 = OSPF · TCP 179 = BGP.

Reference: 3.5 — the two great families · the zoo · s9

OSPF scales through a two-level hierarchy: every non-backbone area connects to area 0, and inter-area traffic transits it. The payoff is containment — flooding and Dijkstra recomputation stay mostly inside an area instead of shaking the whole enterprise on every link flap.

A is incorrect — area 1 is just an ordinary area number. B is incorrect — the backbone is defined by its number, not its size. C is incorrect — a DMZ is a security-zone concept from firewall design, not an OSPF construct. Why hierarchy at all? The same reason ASes exist (Q11): neither flooding nor gossip survives unbounded scale.

Reference: 3.5 — the zoo, OSPF row · s9

EIGRP (Cisco's, proprietary until 2013) is "advanced DV" — the "hybrid" of your slides: it speaks only when something changes (partial, triggered updates instead of periodic full tables), and its DUAL algorithm holds pre-computed loop-free backup routes, so failover doesn't wait for re-convergence.

A is incorrect — abolishing the 30-second full-table habit is precisely the upgrade. C is incorrect — EIGRP routers still learn from neighbors' claims, not from a flooded map; "advanced DV," not LS. D is incorrect — its metric is a composite of bandwidth + delay, one reason it out-chooses hop-count RIP on unequal links.

Reference: 3.5 — the protocol zoo, EIGRP row · s9

Two forces split the world into ASes (regions under one administration — an ISP, a university, a corporation). Scale: flooding a map of a billion destinations, or gossiping tables of them, collapses. Politics: "never carry competitor traffic" and "prefer the cheap link" are business rules no cost metric expresses — so inter-AS routing (BGP, path-vector) makes policy the primary decider, while each AS optimizes freely inside with its own IGP (OSPF/RIP/EIGRP).

A is incorrect — OSPF is an open standard; EIGRP was Cisco's. C is incorrect — BGP is famously slow and deliberate, by design. D is incorrect — Dijkstra handles cyclic graphs fine; loops in the graph aren't loops in the tree it computes.

Reference: 3.5 — scale forces hierarchy · s9

Hot potato = get it off my network as cheaply as possible: choose the exit with the least intra-AS cost, regardless of what happens beyond the border. Locally selfish, globally good enough — and it means two hosts in the same AS may exit through different gateways for the same destination.

A is incorrect — the AS doesn't know (or pay for) distances beyond its border; it optimizes its own leg only. B is incorrect — no rotation; the choice is deterministic per router. D is incorrect — longer AS paths are worse in BGP's eyes, and path length is a tie-breaker among policy-acceptable routes, not an attraction.

Reference: 3.5 — scale forces hierarchy, hot potato · s9

BGP is path-vector: every advertisement carries the entire sequence of ASes the route has traversed. If a router finds its own AS number already in that list, accepting the route would send traffic in a circle — so it rejects it. The full path is also what policy engines read ("never route via AS X").

A is incorrect — TTL kills looping packets (data plane); this is about looping routes (control plane). B is incorrect — split-horizon-style tricks are DV bandages (poison reverse's family) for neighbor-scale loops; BGP's explicit path makes loops visible outright. C is incorrect — timers slow the spread of bad news; they don't detect anything.

Reference: 3.5 — the protocol zoo, BGP row · s9

IPv4's 2³² ≈ 4.3 billion addresses ran out in our lifetime. NAT bought decades by hiding thousands of hosts behind one public address — at the cost of broken end-to-end connectivity and state everywhere. IPv6's answer: 2¹²⁸ ≈ 3.4 × 10³⁸ addresses — enough for every grain of sand with room to spare.

A is incorrect as primary — the faster, fixed 40-byte header is a genuine benefit, but it's what the designers did with the opportunity, not the reason for it. C is incorrect — IPsec matured alongside IPv6 but encryption is not mandatory per packet, and it wasn't the driver. D is incorrect — IPv4 runs over WiFi every day; media independence was never the problem.

Reference: 3.6 — why IPv6 exists · s10

Count it from the field list: Version + Traffic Class + Flow Label + Payload Length + Next Header + Hop Limit = 8 bytes of small fields, plus two 16-byte addresses = 40 bytes, always. No IHL needed (nothing varies), no options block (extension headers replaced it).

A is incorrect and is your s10 slide 7's error — "16 bytes" is likely a mangling of "16 bytes per address"; writing 16 on the exam loses a mark the header diagram hands you (Appendix A). B is incorrect — 20–60 variable is IPv4's header, the thing IPv6 deliberately abolished. D is incorrect — 60 is IPv4's maximum, not IPv6's size.

Reference: 3.6 — 8 fields, 40 bytes · Appendix A · s10 7

Same jobs, honest labels: TTL → Hop Limit (it always counted hops, never time), Protocol → Next Header (it names what follows — payload protocol or an extension header), ToS → Traffic Class. Instant exam marks.

B, C and D are incorrect — each slips Flow Label into the rename list, and Flow Label is the one genuinely new field: it tags packets belonging to one stream so routers can treat them consistently. It renames nothing; it had no IPv4 ancestor. If a question asks "which field is new," Flow Label is the answer; if it asks "what was renamed," Flow Label is the trap.

Reference: 3.6 — the renames · s10

IPv6's Payload Length counts the data only — the 40-byte base header is not included: 1000 + 40 = 1,040. Compare the two protocols' philosophies: IPv4's Total Length includes its (variable) header, so you must subtract IHL×4 to find the data; IPv6's fixed header needs no such arithmetic — you only ever add 40.

A is incorrect — it forgets the header entirely. B is incorrect — 20 is IPv4's minimum header; IPv6's is 40. D is incorrect — there is no IHL in IPv6; that field died with the variable header. (Extension headers, when present, are counted inside Payload Length.)

Reference: 3.6 — header table · 3.1 — Total Length · s10

IPv6 routers never fragment. The oversized packet is dropped and the source is told why; the source then performs path-MTU discovery and sends packets that fit end-to-end (a rare fragment-at-source case uses an extension header). Routers shed the buffering, slicing, and bookkeeping — one of the reasons the fragmentation trio vanished from the header.

A is incorrect — in-network fragmentation is precisely the IPv4 behavior IPv6 abolished. B is incorrect — silence would leave the source retransmitting doomed packets forever; the ICMPv6 report is the mechanism's other half. C is incorrect — no link forwards frames beyond its MTU; that's what MTU means.

Reference: 3.6 — the header diet · 3.1 — fragmentation · s10

Next Header's values to know: 6 = TCP, 17 = UDP (unchanged from IPv4's Protocol field), and 58 = ICMPv6 — a different number from ICMPv4's protocol 1, because it's a different protocol (the one carrying Packet Too Big, and Neighbor Discovery's 133/134). Next Header can also chain to an extension header, which names the next link in turn — RFC 2460's order: hop-by-hop → routing → fragment → authentication/ESP → destination options → payload. Routers parse only what concerns them.

A and B are incorrect — their values are 6 and 17. C is incorrect — OSPF keeps protocol 89 in either IP version.

Reference: 3.6 — extension headers · s10

Decompression is counting: groups present are 2001, db8, 0, a3, 57ab = 5, so :: stands for 8 − 5 = 3 zero groups. Expanded: 2001:0db8:0000:00a3:0000:0000:0000:57ab (re-pad each group to 4 digits). Note the standalone 0 group stays written out — the :: was spent on the longer run, per the tie-break rules.

A and C are incorrect — miscounts; always count what's present and subtract from 8. D is incorrect but contains the right idea in the wrong place: a single :: is never ambiguous (the count is forced); it's two :: that would be — which is exactly why two are illegal.

Reference: 3.6 — compression rules, decompression · s10

Multicast took broadcast's job: ff02::1 reaches all nodes on the link, ff02::2 all routers. Every IPv4 broadcast habit was redesigned around multicast in v6 — ARP's broadcast became Neighbor Discovery's solicited-node multicast, DHCP discovery became a multicast to ff02-scoped groups. Targeted groups beat "interrupt absolutely everyone."

B is incorrect — that's an IPv4 address; it doesn't exist in the IPv6 address space at all. C is incorrect — invented; fe80::/10 is ordinary link-local unicast space. D is incorrect — the all-ones "directed broadcast" concept was deliberately not carried over; a /64's highest address is just another assignable unicast address.

Reference: 3.6 — the missing one (kfact) · s10

Your ISP allocation is the 48-bit global routing prefix; you carve internal networks in the 16-bit subnet ID — that's 65,536 subnets without touching a calculator; hosts live in the 64-bit interface ID. This is why v6 has no VLSM agony: the convention every LAN = /64 makes host-count math irrelevant (2⁶⁴ per subnet is effectively infinite), and all subnetting happens in the 16-bit field.

A, B and D are incorrect — wrong splits; the memorable check is that the interface ID is always the right-hand 64 (half the address), and 48 + 16 fills the left half. GUA space itself is 2000::/3 — anything starting 2 or 3.

Reference: 3.6 — address types · subnets · s10

Unique Local Addresses live in fc00::/7: private, not Internet-routable, free for internal use. The /7 spans fc00…fdff, but only the fd half (locally assigned, with a random 40-bit ID) is defined for use — so real ULAs start fd. Slide fix: s10's "fc00::/7 to fdff::/7" is malformed — fc00::/7 is a single block that spans fc00 through fdff (Appendix A).

A is incorrect — fe80::/10 is link-local: mandatory, auto-generated, and confined to one link; private-but-routable-internally is a different job. C is incorrect — ff00::/8 is multicast. D is incorrect — 2000::/3 is the public global unicast space, the opposite of private.

Reference: 3.6 — address types · Appendix A · s10

Stateless Address Autoconfiguration: the router advertises the prefix (RA, type 134 — the ICMPv6 number from 3.4's trap), the host supplies its own right-hand 64 bits — classically EUI-64 derived from the MAC, on modern OSes a random/privacy ID — checks no one else has it, done. No server, no lease, no state. (DHCPv6 still exists for shops that want central control.)

A is incorrect — that's DHCPv4's opening move (and v6 has no broadcast to send it to). C is incorrect — invented; nothing derives from the router's own address. D is incorrect — DNS maps names to addresses; it doesn't allocate them.

Reference: 3.6 — subnets and self-configuration · 3.4 — RA/RS · s10

The transition triad, by job: dual stack — run both protocols side by side (the norm, but our host is v6-only, so it's off the table); tunneling — carry v6 packets inside v4 across v4-only territory, which still requires v6 at both ends; translation — NAT64 rewrites v6 conversations into v4 and back, the only option when the two endpoints will never speak the same protocol.

B is incorrect — the premise says v6-only; adding a v4 stack changes the host, not the mechanism question. C is incorrect — a tunnel delivers a v6 packet to a v6 endpoint; the v4-only server couldn't read what comes out. D is incorrect — SLAAC assigns addresses; it doesn't bridge protocols.

Reference: 3.6 — living with IPv4 meanwhile · s10

A machine runs dozens of network programs at once — browser, mail, SSH, a game. The port is the last addressing step, naming the process. Sending side merges many conversations onto one IP address (multiplexing); receiving side sorts arrivals to the right program (demultiplexing). The completed analogy: MAC = which house on this street · IP = which building in the world · port = which apartment.

A is incorrect — routers never look at L4 (recall Appendix E Q15: they forward on packets). C is incorrect — no second IP exists; the port extends the address downward into the machine. D is incorrect — encryption is an application/presentation concern (TLS), not base transport.

Reference: Phase 4 — why a transport layer · s8

Clients borrow an ephemeral port (49,152–65,535) for the duration of a connection, then recycle it. So the conversation is something like 52514 → 80: ephemeral source, well-known destination.

A is incorrect — 0–1,023 is for standard server services (HTTP 80, DNS 53…), and binding one needs admin/root privileges — a client asking for one would be both wrong and blocked. B is incorrect — registered ports are for vendor applications acting as servers (3389 RDP, 5432 PostgreSQL). D is incorrect — 80 is the destination; if the source were also 80, only one browser connection per machine could exist.

Reference: Phase 4 — ports and sockets · s8

IP + port = a socket (one end, e.g. 129.21.4.18:443); a TCP connection is the 4-tuple of both ends. Two clients — or two tabs on one client — differ in source IP or source port, so their tuples differ, and the server demultiplexes perfectly while listening on a single port. (File this fact: it's exactly what NAT exploits in Phase 6.)

B is incorrect — a common myth; the server port stays 443 for the whole connection. C is incorrect — MACs died at the last router hop (Phase 2's golden rule); the server may never see them. D is incorrect — cookies are HTTP, an application-layer notion.

Reference: Phase 4 — ports and sockets · s8

SSH = TCP 22 ✓ and SNMP = UDP 161 ✓. The rest of the must-know table: FTP 20/21, Telnet 23, SMTP TCP 25, DNS 53 (UDP + TCP — the dual listing is deliberate, settled in Phase 5), DHCP UDP 67/68, TFTP UDP 69, HTTP 80, POP3 110, IMAP 143, HTTPS 443 — plus RIP UDP 520 and BGP TCP 179 from earlier phases.

B is incorrect — SMTP runs over TCP; mail must arrive intact and ordered. D is incorrect — HTTP's well-known port is 80; 8080 is a common alternate, not the standard. E is incorrect — TFTP is the UDP file-mover ("trivial" = no TCP machinery); its reliability tricks live in the application.

Reference: Phase 4 — the well-known table · Appendix B · s8

TCP sells exactly one product: every byte accounted for (sequence numbers + acks + retransmission), order restored, flow control (never drown the receiver), congestion control (never drown the network) — over a connection established first. The bill: a 20-byte-minimum header and the handshake's round trip.

B is incorrect — TCP trades latency away for reliability; latency-first is UDP's pitch. C is incorrect — encryption is TLS's job, layered on top. D is incorrect — TCP is all about state (sequence numbers, windows, timers per connection); statelessness is UDP's virtue.

Reference: Phase 4 — TCP, the careful transport · s8

RST = abort now / "nothing listens here." The instant, active refusal is itself diagnostic: compare a firewall silently dropping your SYN, which produces a slow timeout instead. Fast refusal → host up, port closed; silence → filtered or dead.

A is incorrect — FIN is the polite "I'm finished sending" of a connection that exists; no connection was ever established here. C is incorrect — URG only marks the urgent-pointer field valid, and it's rare in practice. D is incorrect — PSH means "deliver to the app immediately, don't buffer"; it refuses nothing. The six flags: SYN · ACK · FIN · RST · PSH · URG.

Reference: Phase 4 — the six classic flags · s8

Segment ② does double duty: it acknowledges the client's ISN (ack = 812 + 1 = 813, "I have your byte 812; next I expect 813") and proposes the server's own starting number, seq = y. Segment ③ completes it: ACK, ack = y + 1 — and may already carry data.

A is incorrect twice — the ack must be 813 (next expected, not last received), and without a SYN the server's direction would never get its own numbering established. B is incorrect — the server doesn't continue the client's sequence; each direction numbers its own bytes from its own random ISN. C is incorrect — ack = y + 1 is segment ③, the client's reply.

Reference: Phase 4 — the three-way handshake · s8

TCP is full-duplex: each direction is an independently numbered byte stream, so each side's ISN needs an explicit acknowledgment. That's 2 SYNs + 2 ACKs = four jobs, folded into three segments because SYN+ACK combines two of them. Closing, by contrast, takes four steps (FIN → ACK, FIN → ACK) because each direction closes independently — half-close: "I'm done sending, I'll still listen" — so the pairs can't always fold.

B is incorrect — no security check lives in the base handshake (options like MSS ride along, but that's negotiation, not screening). C is incorrect — routers don't participate; MSS is negotiated end-to-end in the SYN options. D is incorrect — with two segments the client's direction would run unacknowledged.

Reference: Phase 4 — why not two messages? · s8

TCP counts bytes, not segments. The segment covers bytes 9,001 through 9,001 + 1,460 − 1 = 10,460, so the ack names the next expected byte: 10,461. Every TCP arithmetic question reduces to this one rule.

A is incorrect — "last byte received" is the classic off-by-one; acks always point one past it. B is incorrect — echoing the seq would confirm nothing about how much data arrived. D is incorrect — one past the next expected is two past the data; no rule produces it. Related signal: receiving the same ack repeatedly (duplicate acks) means bytes after that point are arriving but the named byte is missing — see Q10.

Reference: Phase 4 — sequence & acknowledgment worked example · s8

A duplicate ack is the receiver saying "I'm still waiting for 4,501" — later data is landing, but that byte is missing. Three duplicates in a row is strong evidence of a lost segment, so TCP resends it immediately: fast retransmit. Reliability's whole toolkit is just numbering + acks + timers.

A is incorrect — the RTO is the fallback when no duplicate-ack evidence arrives (e.g., the very last segment of a burst is lost); waiting when you already have proof wastes time. C is incorrect — nothing is broken enough for a reset; one segment needs resending. D is incorrect — window 0 is the receiver's flow-control brake, and the problem here isn't a full buffer.

Reference: Phase 4 — worked example, steps 3–4 · s8

The Window field is flow control: the receiver advertises how many more bytes it can buffer, and the sender may never have more than that unacknowledged in flight. Window 0 = "I'm full; hold on." Keep the two throttles distinct: flow control protects the receiver and is explicitly advertised; congestion control protects the network and is inferred from loss (slow start and friends — know it exists).

A is incorrect — congestion is never announced in the Window field; TCP deduces it from drops. B is incorrect — closing is FIN's job. D is incorrect — retransmission strategy is a different machine entirely; a zero window pauses even a perfectly loss-free transfer.

Reference: Phase 4 — two throttles · s8

The Maximum Segment Size is what's left of the link's MTU after the two headers that must fit inside it: 1500 − 20 − 20 = 1460 data bytes per segment. Each side states its MSS in the SYN's options field (which is why the TCP header has a variable length and an Offset field, ÷4 like IHL). One formula, three layers tied together — it's on the Appendix B card.

A is incorrect — it's derived, not decreed; a different MTU gives a different MSS. B is incorrect — 1,518 counts Ethernet's own framing (MACs + FCS), which never eats into the MTU's 1,500. C is incorrect — UDP's 8-byte header is irrelevant to a TCP segment size.

Reference: Phase 4 — the sizing fact · Appendix B formulas · s8

UDP is "IP with ports — nothing else": 8 bytes, four 16-bit fields — source port · destination port · length · checksum. No sequence numbers (nothing is ordered), no acks (nothing is confirmed), no window (nothing is throttled), no flags (there's no connection to manage).

B is incorrect — that's TCP's 20-byte header inventory. C is incorrect — a sequence number would imply ordering machinery UDP deliberately lacks. D is incorrect — no 12-byte variant, no flags. The emptiness is the product: compare 8 bytes against TCP's 20–60.

Reference: Phase 4 — UDP, the minimal transport · s8

UDP's Length covers the entire datagram: header + data = 8 + 100 = 108. Minimum possible value: 8 (an empty payload). Reverse direction: Length 512 → 512 − 8 = 504 data bytes.

B is incorrect and is your s8 slide-31 error immortalized — the slide defines Length as "the length of the UDP header," which is wrong on both readings: it's not the header alone (that's always 8) and not the data alone (Appendix A). A is incorrect — 8 would mean no payload. D is incorrect — nothing rounds to powers of two here. One-mark gift if you know the fix; guaranteed loss if you learned the slide.

Reference: Phase 4 — the UDP Length trap · Appendix A · s8 31

A TCP connection is named by its 4-tuple — and a booting DHCP client has no IP address to put in it. UDP's connectionless sends need no established endpoints, so the client can shout from address-nowhere (ports 67/68) and get an answer. The same logic sells UDP to DNS (one-question-one-answer beats a handshake), VoIP/video/gaming (a late packet is worthless — skip it), SNMP, TFTP, RIP.

A is incorrect — DHCP messages are small; size is no obstacle. C is incorrect — neither transport offers security; that's not the axis of choice. D is incorrect twice — UDP provides no ordering, and DHCP's few-message exchange doesn't need any.

Reference: Phase 4 — who buys UDP · s8

(a) TCP — every byte matters, delay doesn't; a firmware image with one flipped byte is a brick. (b) UDP — timeliness beats completeness: a retransmitted audio packet arrives too late to play; skip it and move on. (c) UDP — one tiny question, one tiny answer; a handshake would triple the cost (DNS falls back to TCP only for the big/zone cases — Phase 5).

B is incorrect — TCP's retransmissions add exactly the jitter a call can't absorb. C is incorrect on both ends — an unreliable firmware download is unacceptable, and routine DNS over TCP wastes round trips. D is incorrect on (c). Modern footnote: QUIC rebuilds TCP's guarantees over UDP — that's HTTP/3 — proving the layer split is a design choice, not a law.

Reference: Phase 4 — TCP vs UDP table · check yourself · s8

Your s7 deck lists exactly these four failures of the one-phone-book-for-Earth idea: single point of failure (it dies, the Internet forgets every name), impossible traffic volume, distance (one location can't be close to everyone), and a maintenance monopoly (every update funnels through one operator). Distribution solves all four at once.

A is incorrect — latency is one of the four, not the whole story. B is incorrect — memory was never the binding constraint; failure, load, distance and administration are. D is incorrect — addressing a server was never the issue.

Reference: Phase 5 — DNS, why names · s7

Read the name right to left down the tree: the root ("." — 13 lettered identities, ~1,000 mirrors) knows who runs each TLD; the .edu TLD servers know each domain's name servers; and rit.edu's authoritative server holds the actual records. Everything above it serves referrals, not answers.

A and B are incorrect — root and TLD servers reply "ask them next, here's where" (Q7); they store the map of the map, not the destination data. C is incorrect — the stub resolver on your machine stores nothing authoritative; it just asks (and caches what comes back).

Reference: Phase 5 — the hierarchy figure · s7

MX maps a domain to its mail server's name, each with a preference number — lowest wins, higher numbers are backups. (Think "priority 1 beats priority 10.")

A is incorrect — direction flipped; that's the classic MX trick option. C is incorrect — CNAME aliases one name to a canonical name (www.shop.com → shop.hosting.net; the lookup then restarts on the target) and has nothing to do with mail selection. D is incorrect — TXT carries policy text like SPF/DKIM, which authenticates mail; it doesn't route it.

Reference: Phase 5 — resource records table · s7 13 (rebuilt)

A ✓ — "quad-A": 4 × 32 bits = 128, cute and mnemonic. C ✓ — and after following a CNAME, the lookup restarts on the canonical target.

B is incorrect — arbitrary text is TXT; PTR is the reverse map (IP → name, living under in-addr.arpa). D is incorrect — NS maps a domain to its authoritative name servers; it's the glue that builds the hierarchy's referrals. E is incorrect — SOA is zone metadata (primary server, admin email, serial and refresh timers); mail is MX's job (Q3). Full table to memorize: A · AAAA · CNAME · MX · NS · PTR · SOA · TXT.

Reference: Phase 5 — resource records table · s7

Reverse DNS inverts the question: PTR records live under the special in-addr.arpa domain (the IP's octets reversed form the name), and tools like ping -a and dig -x consult them. Forward (A) and reverse (PTR) records are maintained separately — one existing never guarantees the other.

B is incorrect — A records only run name → IPv4; there is no "backwards read" of the forward tree, which is indexed by names. C is incorrect — NS records delegate zones; they don't answer ownership. D is incorrect — SOA describes the zone itself, not any single address.

Reference: Phase 5 — resource records · dig examples · s7

The hybrid is the reality: your stub resolver asks its configured recursive resolver (ISP, campus, 8.8.8.8) one recursive question, and that resolver then walks the tree iteratively, following referrals. Root and TLD servers refuse recursion by design — serving referrals only is what keeps them alive under world-scale load.

A is incorrect — if every server recursed, the root would carry the whole Internet's lookup labor. B is incorrect — your OS's stub is deliberately dumb; it delegates the walking. D is incorrect — the split is by role in the chain, never by TLD. Exam phrasing: if asked "fully recursive vs iterative," describe both models, then note reality is this hybrid.

Reference: Phase 5 — how a lookup travels · kfact · s7

Referrals, not delegation-of-labor: each tier hands back the next rung down. Root → "here are the .edu servers"; TLD → "here are rit.edu's authoritative servers"; authoritative → the actual answer. The NS records (Q4) are exactly what these referrals are made of.

A is incorrect — TLD servers don't hold leaf records; only rit.edu's authoritative server does (Q2). C is incorrect — referrals only ever point down the tree, toward the answer. D is incorrect — TLD servers answer any resolver; what they refuse is recursion, not queries.

Reference: Phase 5 — how a lookup travels · s7

Caching is what makes DNS fast — a second lookup of google.com costs microseconds and zero packets — and the TTL is its price: after a move, stale cached answers linger anywhere below you in the chain (your OS, your resolver) for up to a full TTL. That lag is "propagation." Ops trick implied: drop the TTL before a planned move.

A is incorrect — zone transfers sync the domain's own servers; they aren't what delays the world's caches. B is incorrect — the root never held the A record at all (Q2). C is incorrect — the record was already changed at the authoritative server; the delay lives downstream.

Reference: Phase 5 — caching & TTL · s7

Both of your slides were right — about different jobs. Ordinary queries ride UDP 53: one tiny packet each way; a handshake would triple the cost. TCP 53 carries the bulk and the oversized: a secondary server copying an entire zone (AXFR) needs reliable, ordered delivery; and a response beyond the classic 512-byte datagram limit comes back flagged truncated, telling the client to retry over TCP. Exam phrasing: "UDP for queries, TCP for zone transfers."

A is incorrect — the dual listing is deliberate. B is incorrect — that would forfeit UDP's one-exchange economy for millions of tiny lookups. D is incorrect — PTR queries are ordinary queries; they ride UDP like the rest.

Reference: Phase 5 — the UDP/TCP trap, resolved · Phase 4 · s7 · s8

DHCP exists to kill the manual-typo factory (duplicate addresses, wrong masks, forgotten gateways), so it leases the whole kit: IP + mask + default gateway + DNS servers + lease time. Addresses return to the pool when leases lapse — one small pool can serve a rotating crowd of laptops.

B is incorrect — an IP without mask and gateway can't even leave its subnet; half-configuration would defeat the purpose. C is incorrect — MACs are burned into (or randomized by) the interface at L2; DHCP never assigns them (it uses them to identify clients). D is incorrect — hosts discover neighbors via ARP/ND when needed, not from DHCP.

Reference: Phase 5 — why DHCP · s7

DORA: the client broadcasts Discover ("any DHCP server out there?"), servers answer with an Offer (address + mask + gateway + DNS + lease), the client broadcasts a Request accepting one offer, and the winning server's Ack starts the lease timer. Only after the Ack does the client configure its interface.

B and D are incorrect — you can't request or be offered before asking; the mnemonic locks the order. C is incorrect — DHCP cannot use TCP: the client has no IP address yet, so no connection is possible (the Phase 4 fact). It protects itself instead with UDP checksums and randomized retransmission timers.

Reference: Phase 5 — the DORA figure · Phase 4 — why DHCP is UDP · s7

The client has nothing: source 0.0.0.0 ("I have no address" — the unspecified address), destination 255.255.255.255 (limited broadcast — it doesn't even know what network it's on, so this is the only address that works). Ports: client = 68, server = 67.

A is incorrect — ports swapped; "server 67 / client 68" is the pairing to memorize. C is incorrect — APIPA (169.254) is what a host self-assigns after DHCP fails; during the attempt it sources 0.0.0.0. D is incorrect — there is no leased IP yet, and the server's address is unknown until an Offer arrives.

Reference: Phase 5 — DORA figure, step ① · 3.2 — limited broadcast · s7

Two different moments your s7 slide 30 fused into one error (it claims the initial REQUEST sources "the new client address" — RFC 2131 says no). During initial DORA the client still sources 0.0.0.0: nothing is its own until the server's ACK lands. At renewal (~50% of lease) the client very much has an address — it unicasts a REQUEST from its own IP straight to its server, falling back to broadcast, then a fresh DORA, if renewals go unanswered.

A is incorrect — that's the slide's error verbatim (Appendix A). B is incorrect — a renewing client isn't addressless. D is incorrect — 255.255.255.255 is only ever a destination; no packet legally sources the broadcast address (Appendix G Q10's rule).

Reference: Phase 5 — the REQUEST trap · Appendix A · s7 30

Several servers may answer one DISCOVER with offers, each tentatively reserving an address. The broadcast REQUEST names the chosen server — and doubles as a polite mass-decline: everyone else releases their reserved offer back to the pool. One packet, two jobs.

A is incorrect — the Offer arrived in a frame; the client saw the server's MAC. C is incorrect — no such prohibition; renewals are unicast (Q13). D is incorrect — a relay forwards whatever the exchange needs; it isn't the reason for this design choice.

Reference: Phase 5 — DORA figure caption · s7

The relay agent is the standard fix: it catches the local broadcast, stamps in its own interface address (the gateway field), and unicasts the message across any number of hops to the server. That stamp is also how the server knows which subnet's pool to draw from — twenty subnets, one server, one lease database.

A is incorrect — DHCPv4 has no multicast mode; that thinking belongs to v6's redesign. B is incorrect — avoiding server-per-subnet is exactly what relays are for. C is incorrect — globally forwarding broadcasts would resurrect every broadcast-storm and ARP-noise problem subnetting exists to kill (3.3's whole motivation).

Reference: Phase 5 — practicalities, scope · 3.3 — why subnet · s7

DHCP trusts everyone — that's the flaw. A rogue server on the local LAN answers DISCOVERs faster than the relayed real server (clients accept the first OFFER to arrive) and hands out itself as gateway/DNS: instant man-in-the-middle. DHCP snooping marks which switch ports may originate server messages; rogue OFFERs from user ports are dropped.

A is incorrect — starvation is the other DHCP attack: flooding fake DISCOVERs to drain the pool so real users get nothing (denial of service, not interception). B is incorrect — ARP spoofing achieves a similar MITM but by poisoning ARP caches after addressing is done (Appendix D Q15); here the lie arrived inside the lease itself. D is incorrect — no DNS cache was touched; the attacker didn't need to when it could be the configured DNS.

Reference: Phase 5 — security practicalities · Phase 2 — ARP security · s7

The border router holds one (or a few) public addresses and performs live header surgery both ways, with the translation table as its memory. Thousands of hosts, one public IP — the single trick that deferred IPv4 exhaustion by ~25 years, and the reason 3.2's private ranges are useful at all.

A is incorrect — DNS maps names to addresses (Phase 5); it never touches packets in flight. C is incorrect — Internet routers drop RFC 1918 sources regardless of what they carry; the private address genuinely never leaves your site. D is incorrect — no default VPN exists; and a VPN would still need valid public addresses at its ends.

Reference: Phase 6 — why NAT exists · 3.2 — private ranges · s5 15–17

Decode the terms literally: inside = it names an inside host; local = the value used on the local (private) side; global = the value shown to the global Internet. So the same inside machine has an inside local face (10.100.100.3) and an inside global face (200.1.1.1).

A is incorrect — the swap; if the labels ever confuse you, "local = LAN-side value" breaks the tie. B is incorrect — outside terms describe the remote server's addresses, not your host's. C is incorrect — the pair coexists; the translation table's rows are exactly inside-local ↔ inside-global mappings.

Reference: Phase 6 — vocabulary · s5

Static NAT nails 10.1.1.10 ↔ 203.0.113.10 permanently, in both directions — so unsolicited inbound connections (which mail delivery is!) always find their way, no pre-existing table entry needed. The mapping is the table entry, forever.