Project 20: Complete Home Network Stack (Capstone)

An integrated home/office network stack that includes routing, NAT, DHCP, DNS, firewall, monitoring, and documentation.

Quick Reference

Attribute Value
Difficulty Level 4: Expert
Time Estimate 4-6 weeks
Main Programming Language Mixed
Alternative Programming Languages N/A
Coolness Level Level 5: Pure Magic
Business Potential 4. The “Open Core” Infrastructure
Prerequisites See concepts below
Key Topics Layering and Encapsulation, Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching), IP Addressing, Subnetting, and Routing (Including NAT), Transport and Ports (TCP and UDP), Naming and Configuration Services (DNS, DHCP, mDNS), Operations, Diagnostics, and Security

1. Learning Objectives

  1. Build and validate: An integrated home/office network stack that includes routing, NAT, DHCP, DNS, firewall, monitoring, and documentation..
  2. Explain protocol behavior and verify it with a capture or trace.
  3. Handle edge cases and produce reproducible results.

2. All Theory Needed (Per-Concept Breakdown)

Layering and Encapsulation

Fundamentals Layering is the core mental model of networking. Each layer wraps the data from the layer above with its own header, creating a structure that can be forwarded and understood without needing to interpret higher-level meaning. This is called encapsulation. At the sender, application data becomes a transport segment, then an IP packet, then a link-layer frame, and finally a stream of bits. At the receiver, the process runs in reverse. Layering matters because it limits complexity: you can troubleshoot and replace one layer without rewriting the others. It also shapes failure modes. A broken DNS resolver looks different from a broken Wi-Fi link even though both present as “the internet is down.” Understanding the boundaries and contracts between layers is the prerequisite for every project in this guide.

Deep Dive Layering is both a conceptual tool and a real architectural boundary. The OSI model is useful vocabulary, while the TCP/IP model represents how systems are actually built. Each layer provides a service to the layer above and consumes a service from the layer below. The practical consequence is that the same application can run over different link types (Ethernet or Wi-Fi) without changing application logic, because the transport and network layers abstract away those differences. Encapsulation is the mechanism that makes this abstraction possible. The application emits bytes; the transport layer adds source and destination ports and reliability metadata; the network layer adds source and destination IP addresses and routing-related fields; the link layer adds source and destination MAC addresses and a frame check sequence. Each hop strips and rewrites only the link-layer envelope while leaving higher layers untouched. This design creates stability but also creates overhead and limits.

The concept of a “layer” is not just a teaching device. It defines the fields you see on the wire and what devices are allowed to change. Switches operate at Layer 2 and rewrite nothing above it. Routers operate at Layer 3 and do not (in principle) modify transport payloads. However, real networks introduce cross-layer devices like NATs, firewalls, and proxies, which inspect or alter information above their nominal layer. This is why you can have a perfectly valid TCP segment that never reaches its destination: the middleboxes change or block it. Learning to see this boundary between ideal layering and real-world layering is essential for debugging home networks.

Layering also explains why maximum transmission unit (MTU) problems are so confusing. The link layer has a maximum frame size (for Ethernet, this is typically 1500 bytes of payload). The IP layer can either fragment larger packets or rely on Path MTU Discovery to avoid fragmentation. Transport protocols like TCP negotiate a maximum segment size (MSS) that fits within the path MTU. If an intermediate device drops ICMP “fragmentation needed” messages, Path MTU Discovery breaks and connections appear to hang only for large transfers. This failure is a cross-layer interaction: a link-layer size limit, an IP-layer fragmentation mechanism, and a transport-layer path discovery algorithm. Layering gives you a vocabulary to explain it, but you must be able to test it with real captures and commands.

Layering is also a performance story. Each layer adds overhead. A tiny application payload can become a much larger frame once transport, network, and link headers are applied. On Wi-Fi, retries and contention can further increase airtime. On a busy home network, that overhead matters. It also affects security: a link-layer encryption protocol like WPA3 protects the frame, but not necessarily the application data once it leaves the Wi-Fi link. Understanding which layer provides confidentiality, integrity, and authentication is a prerequisite for designing secure systems.

Finally, layering shapes how you design tools. A packet sniffer observes data across layers and therefore must decode multiple headers. A port scanner uses the transport layer to infer service behavior. A DNS resolver is an application-layer tool that relies on transport and network layers to function. Each project in this guide is an experiment that isolates and stresses a specific layer contract. The result is a mental model where failures become testable hypotheses rather than mysteries.

How this fit on projects You will repeatedly build tools that operate at specific layers (ARP at link, ping at network, DNS at application). This concept helps you decide which headers to read and which variables to control.

Definitions & key terms

  • Layer: A conceptual boundary that provides a service to the layer above.
  • Encapsulation: Wrapping data with headers as it moves down the stack.
  • Decapsulation: Stripping headers as data moves up the stack.
  • MTU: Maximum payload size at the link layer.
  • MSS: Maximum TCP payload size negotiated by endpoints.

Mental model diagram

APP DATA
  |
  v
[ TCP hdr | APP DATA ]
  |
  v
[ IP hdr | TCP hdr | APP DATA ]
  |
  v
[ ETH hdr | IP hdr | TCP hdr | APP DATA | FCS ]
  |
  v
BITS ON THE WIRE

How it works

  1. Application produces bytes.
  2. Transport adds ports and reliability metadata.
  3. Network adds IP addressing and TTL.
  4. Link adds MAC addresses and integrity checks.
  5. Each hop rewrites the link header, not the IP header. Invariants: Higher layers should not depend on link type. Failure modes: MTU mismatch, middlebox interference, incorrect assumptions about which layer provides security.

Minimal concrete example

Encapsulation trace (sizes):
APP payload: 120 bytes
TCP header: 20 bytes
IP header: 20 bytes
Ethernet header + FCS: 18 bytes
Total on wire: 178 bytes

Common misconceptions

  • “A router forwards frames.” It forwards packets; frames are link-local.
  • “NAT is security.” NAT is address translation, not a security control.

Check-your-understanding questions

  1. Which layer is responsible for port numbers?
  2. Why does a packet get a new MAC destination at every hop?

Check-your-understanding answers

  1. Transport layer.
  2. MAC addresses are only meaningful within a local link.

Real-world applications

  • Debugging MTU black holes.
  • Explaining why Wi-Fi encryption does not secure end-to-end traffic.

Where you will apply it

  • Projects 1-4, 9, 11, 14, 17

References

  • “Computer Networks” by Tanenbaum and Wetherall - Ch. 1
  • “TCP/IP Illustrated, Vol 1” by Stevens - Ch. 1-2

Key insights Encapsulation is the reason you can diagnose failures by layer instead of guessing.

Summary Layering reduces complexity, but real networks leak across layers. You must know both the ideal model and the messy reality.

Homework/Exercises to practice the concept

  1. Draw the encapsulation stack for a DNS query over UDP.
  2. Identify which headers change at each hop in a traceroute.

Solutions to the homework/exercises

  1. APP -> UDP -> IP -> Ethernet, with UDP ports 53.
  2. Link-layer headers change every hop; IP header TTL changes each hop.

Fundamentals The link layer is the realm of MAC addresses, frames, and local delivery. It is responsible for getting data from one device to another device on the same local network segment. Ethernet and Wi-Fi are the most common link layers in home and office networks. Ethernet uses switches that learn where MAC addresses live and forward frames to the correct port. Wi-Fi is a shared medium where devices contend for airtime and associate with an access point, which then bridges traffic to the wired LAN. ARP (Address Resolution Protocol) is the bridge between IP and MAC addresses, allowing an IP address to be mapped to a link-layer destination. The link layer defines the boundaries of broadcast domains, which strongly influences performance and security.

Deep Dive The link layer is the place where “local” really means local. A switch builds a table of MAC address to port mappings by observing the source MAC of incoming frames. When it sees a destination MAC it does not know, it floods the frame out all ports (except the one it arrived on). Over time, this learning behavior makes forwarding efficient, but it also creates risks like MAC table overflow or broadcast storms if the network is poorly segmented. Unlike routers, switches do not understand IP addresses; they only see MACs and EtherType values. This is why ARP is necessary. When a host wants to send to an IP on the same subnet, it broadcasts an ARP request asking who owns that IP, and the owner replies with its MAC. That reply is cached for a limited time. If the cache is stale, ARP traffic increases and devices appear to “mysteriously” fail or slow down.

Wi-Fi adds complexity because the medium is shared and half-duplex. Devices must contend for airtime, and interference or poor signal quality can cause retransmissions that look like packet loss at higher layers. An access point is effectively a bridge between the Wi-Fi link and the wired Ethernet LAN. When you see a device “connected” but unable to reach the internet, the cause could be at the association layer (link) rather than at IP or DNS. Another subtlety is that Wi-Fi uses different frame formats and encryption (WPA2/WPA3) to protect frames on the air. This encryption is per-link, not end-to-end. Once a frame leaves the access point and enters the wired LAN, that Wi-Fi encryption no longer applies.

VLANs are a link-layer technique for segmentation. They allow multiple logical networks to share the same physical switch by tagging frames. In a home/office setting, VLANs are used to separate guest networks or IoT devices from trusted devices. This is a key security and performance tool, but it requires that all participating switches and access points handle VLAN tags correctly. Misconfigured VLAN tagging leads to symptoms like DHCP working on one SSID but not another, or devices that can access the router but not other devices.

Understanding link-layer behavior is essential for building scanners and sniffers. A packet sniffer on a wired switch port sees only the frames destined for that port unless you use port mirroring. On Wi-Fi, you might need monitor mode to see frames not destined for your device. This is a practical limitation that affects how you validate your tools. It is also why many network tools appear to “miss” traffic when run on the wrong interface or in the wrong capture mode.

Finally, link-layer security is not the same as network-layer security. ARP has no authentication, which is why ARP spoofing is possible. Wi-Fi encryption does not prevent a malicious device from joining the network if the passphrase is weak. If you understand the link layer, you can explain and detect these risks with concrete evidence, such as duplicate IP address warnings or sudden changes in ARP cache entries.

How this fit on projects Projects 1, 4, 12, 15, and 18 force you to understand ARP, frames, and capture limitations.

Definitions & key terms

  • MAC address: A link-layer identifier used for local delivery.
  • Frame: The unit of data at the link layer.
  • ARP: Protocol that maps IP addresses to MAC addresses on a LAN.
  • Broadcast domain: The scope of a link-layer broadcast.
  • VLAN: A logical segmentation of a link layer.

Mental model diagram

Device A        Switch          Device B
AA:AA           CAM Table       BB:BB
  |                |              |
  | ARP who-has?   | flood        |
  |--------------->|------------->|
  |                | ARP reply    |
  |<---------------|<-------------|
  | data frame     | unicast      |

How it works

  1. Host wants to send to IP in same subnet.
  2. Host broadcasts ARP request for target IP.
  3. Target replies with its MAC address.
  4. Host caches mapping and sends frames directly. Invariants: ARP traffic does not cross routers. Failure modes: ARP cache poisoning, switch flooding, weak Wi-Fi encryption.

Minimal concrete example

ARP exchange (text):
Request: Who has 192.168.1.50? Tell 192.168.1.10
Reply: 192.168.1.50 is at 00:11:22:33:44:55

Common misconceptions

  • “Switches block broadcasts.” Switches forward broadcasts to all ports.
  • “Wi-Fi is just wireless Ethernet.” The medium behavior and security differ.

Check-your-understanding questions

  1. Why does ARP not work across subnets?
  2. What does a switch do with an unknown destination MAC?

Check-your-understanding answers

  1. ARP requests are link-local broadcasts; routers do not forward them.
  2. It floods the frame out all ports except the ingress port.

Real-world applications

  • Diagnosing why a device is visible but not reachable.
  • Segmenting IoT devices with VLANs and guest Wi-Fi.

Where you will apply it

  • Projects 1, 4, 12, 15, 18

References

  • “TCP/IP Illustrated, Vol 1” by Stevens - Ch. 2, 4
  • RFC 826 (ARP)

Key insights The link layer is the truth of local delivery; everything else is built on it.

Summary Mastering ARP, MACs, and switching gives you real control over your LAN behavior.

Homework/Exercises to practice the concept

  1. Map your own ARP cache and identify every device.
  2. Draw your network and mark the broadcast domain boundaries.

Solutions to the homework/exercises

  1. Use arp -a and compare with your router client list.
  2. Each router boundary separates a broadcast domain.

IP Addressing, Subnetting, and Routing (Including NAT)

Fundamentals IP is the addressing and routing system of the internet. IPv4 uses 32-bit addresses and relies on subnet masks (CIDR) to determine which destinations are local versus remote. Your device sends local traffic directly and remote traffic to the default gateway (your router). Routing is a hop-by-hop decision made by routers using the longest prefix match in the routing table. NAT (Network Address Translation) is common at the edge: it maps many private addresses to a single public address. Subnetting is the tool that partitions a network into smaller segments, which is critical for performance, security, and scaling in home/office environments.

Deep Dive An IP address has two parts: the network prefix and the host identifier. CIDR notation (for example, /24) tells you how many bits belong to the prefix. The prefix defines the boundary of local delivery. If the destination IP shares the same prefix, the host uses ARP to find the destination MAC and sends directly. If not, it sends to the default gateway. This simple rule explains most “why can’t I reach this device” problems. Subnetting is the practice of choosing a prefix length that fits your network size and segmentation goals. Too large a subnet creates unnecessary broadcast traffic and larger failure domains. Too small a subnet causes address shortages or awkward routing rules.

Routing decisions are made by examining the destination IP and finding the most specific (longest) match in the routing table. A default route (0.0.0.0/0) catches everything else. Each router decrements the TTL field, which prevents routing loops from persisting forever. When TTL reaches zero, the router drops the packet and sends an ICMP Time Exceeded message. This is the mechanism that traceroute exploits. In home networks, your router usually has a handful of routes: the local LAN, perhaps a guest LAN, and a default route to your ISP. But in small office networks, you might add static routes to reach a lab subnet, or a VPN route to reach a remote office. Misconfigured routes cause asymmetric paths, which are hard to debug without captures.

NAT adds a stateful translation table at the edge. It replaces private source IPs and ports with a public IP and a chosen source port (often called PAT). When replies come back, the router uses this table to translate them back to the internal host. This is how many devices share one public address. NAT also breaks the original end-to-end model of the internet, which is why inbound connections typically require explicit port forwarding. Understanding NAT is critical for troubleshooting “I can browse the web but cannot host a server” issues, and for understanding why some peer-to-peer applications struggle. NAT is not a firewall, but it has similar observable effects because unsolicited inbound traffic is dropped by default when no translation table entry exists.

IPv6 changes the addressing landscape. It uses 128-bit addresses, removing the need for NAT at the edge. Instead of ARP, IPv6 uses Neighbor Discovery (ND). IPv6 hosts often use Stateless Address Autoconfiguration (SLAAC) to build their own addresses from router advertisements. In practice, many home networks operate dual-stack (IPv4 and IPv6). This means troubleshooting can involve two parallel protocol stacks, with different failure modes. A device might fail over IPv4 but work over IPv6, or the reverse. Understanding IP addressing at both versions makes you far more effective at diagnosing real-world issues.

Finally, routing and addressing are where policy is enforced. VLANs map to IP subnets. Firewall rules frequently reference IP ranges. VPNs create new routes. If you know how to design and reason about addresses and routing tables, you can predict how traffic will flow before you even run a packet capture. That ability is what transforms you from a user of networks into an engineer of networks.

How this fit on projects Subnet math and routing logic are required for Projects 1-3, 9, 14, 18, and 19.

Definitions & key terms

  • CIDR: Prefix notation for networks (e.g., /24).
  • Default gateway: Router used for off-subnet traffic.
  • Longest prefix match: Routing rule that chooses the most specific route.
  • NAT/PAT: Translation of internal addresses to a public address with ports.

Mental model diagram

LAN 192.168.1.0/24       Router/NAT          Internet
Host 192.168.1.50  ->  [NAT table]  ->  203.0.113.5:45001

How it works

  1. Host checks if destination is in local subnet.
  2. If local, ARP and send directly; if not, send to gateway.
  3. Router chooses route via longest prefix match.
  4. NAT rewrites source IP/port for outbound flows. Invariants: TTL always decrements at routers. Failure modes: wrong subnet mask, missing default route, NAT table exhaustion.

Minimal concrete example

Routing table snippet:
192.168.1.0/24 -> eth0 (direct)
0.0.0.0/0 -> 192.168.1.1 (default)

Common misconceptions

  • “Two devices with the same IP will work if they are on different switches.” They will conflict if on the same subnet.
  • “NAT protects me from all inbound attacks.” It does not replace a firewall.

Check-your-understanding questions

  1. Why does a /24 network have 254 usable addresses?
  2. What happens when no route matches a destination?

Check-your-understanding answers

  1. Two addresses are reserved: network and broadcast.
  2. The packet is dropped (and often an ICMP unreachable is sent).

Real-world applications

  • Planning guest and IoT subnets.
  • Diagnosing port forwarding and inbound access problems.

Where you will apply it

  • Projects 1-3, 9, 14, 18, 19

References

  • “TCP/IP Illustrated, Vol 1” by Stevens - Ch. 3
  • RFC 791 (IPv4), RFC 8200 (IPv6)

Key insights Addressing and routing are the map; NAT and policy are the gatekeepers.

Summary If you can compute subnets and read routing tables, you can predict traffic flow.

Homework/Exercises to practice the concept

  1. Divide 192.168.10.0/24 into four /26 subnets.
  2. Sketch a routing table for a network with a guest VLAN and a VPN.

Solutions to the homework/exercises

  1. /26 blocks at .0, .64, .128, .192.
  2. Include routes for each subnet plus a default route to the ISP.

Transport and Ports (TCP and UDP)

Fundamentals The transport layer provides end-to-end communication between applications. TCP offers reliable, ordered delivery through acknowledgments, retransmission, and flow control. UDP provides minimal overhead without reliability guarantees, which makes it ideal for low-latency or simple query/response protocols like DNS. Ports are the addressing mechanism for applications. A network connection is identified by a 5-tuple: source IP, source port, destination IP, destination port, and protocol. Understanding how TCP and UDP differ is essential for building tools like ping-like diagnostics, port scanners, and proxies.

Deep Dive TCP is a stateful protocol. It begins with a three-way handshake that establishes initial sequence numbers on both ends. Once established, each side maintains a sliding window of bytes that have been sent but not yet acknowledged. Retransmission occurs on timeout or after duplicate acknowledgments. Flow control uses the receiver’s advertised window to prevent buffer overflow, while congestion control reacts to signs of network congestion by reducing the sending rate. These behaviors are not just theoretical: they explain why a large file transfer can slow down after packet loss, and why a connection may stall if ACKs are filtered or delayed.

UDP is the opposite: it simply wraps application data with source and destination ports and a checksum. There is no handshake, no retransmission, and no ordering. This makes UDP great for short queries, live streaming, or gaming, where timeliness is more important than perfect delivery. But it also means that the application must handle loss, duplication, or reordering if those problems matter. This is why protocols like DNS and DHCP include their own retry logic and transaction IDs.

Ports are the multiplexing mechanism of the transport layer. A single IP address can host many services because each service listens on a different port. Clients use ephemeral ports chosen by the OS to distinguish their connections. Firewalls and NAT devices often make decisions based on ports and protocol state, which is why understanding TCP states (SYN_SENT, ESTABLISHED, FIN_WAIT) is crucial for debugging. For example, a firewall that drops inbound SYN packets but allows inbound ACKs can cause mysterious failures in connection setup while established connections continue to work.

Transport behavior is also shaped by MTU and fragmentation. TCP segments are sized to fit within the path MTU. If a segment is too large and fragmentation is blocked, the connection can stall in ways that appear random. UDP has no built-in recovery for lost fragments, which can make large UDP payloads unreliable. This is why many UDP-based protocols keep messages small or implement their own segmentation and reassembly.

When you build transport-layer tools, you are interacting with a state machine. A port scanner that uses TCP SYN packets is testing how a host responds to a state transition. A proxy server is managing two concurrent TCP state machines and relaying data between them. A VPN tunnel often runs over UDP or TCP and must handle reliability differently depending on the transport. The more you understand transport mechanics, the more precise your debugging and design choices become.

How this fit on projects Projects 2, 3, 9, 11, 17, and 19 depend directly on transport behavior.

Definitions & key terms

  • 5-tuple: The identifiers of a transport flow.
  • Handshake: TCP connection establishment.
  • Window: Flow control mechanism for TCP.
  • Ephemeral port: Temporary client port assigned by the OS.

Mental model diagram

Client                     Server
SYN  -------------------->  (listening)
SYN-ACK <------------------
ACK  -------------------->  (established)

How it works

  1. TCP establishes state via handshake.
  2. Data is sent with sequence numbers and ACKs.
  3. Loss triggers retransmission and window reduction.
  4. UDP sends without state; application handles retries if needed. Invariants: TCP guarantees order if the connection stays up. Failure modes: half-open connections, blocked SYNs, dropped ACKs.

Minimal concrete example

UDP request/response:
Client -> UDP:53 query id=0x1234
Server -> UDP:53 response id=0x1234

Common misconceptions

  • “UDP is always faster.” It can be, but loss may negate benefits.
  • “TCP guarantees delivery across the internet.” It only guarantees delivery within the connection’s lifetime.

Check-your-understanding questions

  1. Why does a TCP connection need both sequence and acknowledgment numbers?
  2. When would you choose UDP over TCP for a home network tool?

Check-your-understanding answers

  1. To track sent bytes and confirm receipt in order.
  2. For low-latency, small messages where retries are acceptable.

Real-world applications

  • Reliable file transfer versus real-time streaming.
  • Port scanning and service discovery.

Where you will apply it

  • Projects 2, 3, 9, 11, 17, 19

References

  • RFC 9293 (TCP), RFC 768 (UDP)
  • “TCP/IP Illustrated, Vol 1” by Stevens - Ch. 11-16

Key insights Transport protocols are state machines; your tools must respect their state.

Summary TCP and UDP make different promises. Your designs must align with those promises.

Homework/Exercises to practice the concept

  1. List three application protocols that use UDP and why.
  2. Draw the TCP close sequence and label each side’s state.

Solutions to the homework/exercises

  1. DNS (small queries), NTP (time sync), VoIP (latency).
  2. FIN/ACK exchange with TIME_WAIT on the side that closes last.

Naming and Configuration Services (DNS, DHCP, mDNS)

Fundamentals Before a connection happens, a device needs two things: an address configuration and a name-to-address mapping. DHCP provides configuration: IP address, subnet mask, default gateway, and DNS servers. DNS provides name resolution: it turns a human-friendly name into IP addresses. On small local networks without an authoritative DNS server, mDNS and DNS-SD allow devices to discover services on the local link. These services are essential because users do not type IP addresses and devices do not manually configure themselves in modern networks.

Deep Dive DNS is a hierarchical distributed database. When a client needs to resolve a name, it asks a recursive resolver (often provided by the ISP or a local router). The resolver performs iterative queries starting at the root, then the TLD, then the authoritative server for the zone. Responses are cached according to TTL values. This caching is why DNS queries can be fast, and also why changes can take time to propagate. DNS responses can arrive over UDP for small messages or TCP for larger responses or zone transfers. Understanding this distinction matters for debugging, since UDP truncation forces a TCP retry.

DHCP follows a discover-offer-request-acknowledge (DORA) exchange. A client with no address broadcasts a DHCPDISCOVER. A server replies with a DHCPOFFER. The client requests the offered address with DHCPREQUEST, and the server confirms with DHCPACK. Leases are time-limited and periodically renewed. This system allows dynamic reuse of addresses and centralized configuration. But it also introduces failure modes: multiple DHCP servers can fight, leases can expire if the server is unreachable, and clients can receive inconsistent options (like a wrong default gateway) that make the network appear partially broken.

mDNS and DNS-SD provide zero-configuration discovery. Instead of contacting a DNS server, devices send multicast queries to a well-known address on the local link. This allows discovery of printers, media devices, and local services without manual setup. The protocol reuses DNS message formats but changes the transport and scope. mDNS is powerful for home networks but can become noisy in larger environments. Understanding the scope and TTL settings for mDNS is essential when diagnosing why a device appears in a discovery list but is not reachable, or why service lists change frequently.

Naming and configuration services also intersect with security. DNS can be spoofed if you trust the wrong resolver or if a local attacker injects responses. DHCP can be abused by rogue servers. This is why managed networks often implement DHCP snooping and DNS security mechanisms. In home networks, the threat model is different, but the failure modes are similar. A misbehaving IoT device running a DHCP server can cause intermittent failures that look like random internet drops.

Finally, these services are the backbone of usability. When DNS or DHCP fails, users perceive that “the internet is down,” even if the physical link is fine. Your ability to build a DNS resolver or DHCP server from scratch is a demonstration that you truly understand how network configuration and naming work. It also makes you capable of implementing local overrides like DNS sinkholes, which are highly practical for security and ad-blocking.

How this fit on projects Projects 5-8, 10, and 16 are direct applications of DNS, DHCP, and mDNS.

Definitions & key terms

  • Resolver: The client-side DNS component that asks questions.
  • Recursive resolver: DNS server that walks the hierarchy on behalf of clients.
  • TTL: Time-to-live for cached DNS answers.
  • Lease: The time a DHCP address is valid.
  • mDNS: Multicast DNS on a local link.

Mental model diagram

Client -> Resolver -> Root -> TLD -> Authoritative
          ^ cache TTLs at each step

How it works

  1. Client obtains an IP address and DNS server via DHCP.
  2. Client asks resolver for a name.
  3. Resolver walks the DNS hierarchy and caches answers.
  4. Local devices use mDNS for link-local discovery. Invariants: DNS is cached and hierarchical. Failure modes: rogue DHCP, stale DNS cache, mDNS storms.

Minimal concrete example

DNS query/response (text):
Query: A example.com
Answer: example.com -> 93.184.216.34 (TTL 86400)

Common misconceptions

  • “DNS is always real-time.” It is cached by design.
  • “DHCP only gives IP addresses.” It also provides gateway and DNS servers.

Check-your-understanding questions

  1. Why might a DNS change take hours to show up?
  2. What happens if a DHCP lease expires and the server is down?

Check-your-understanding answers

  1. Cached answers remain valid until TTL expires.
  2. The client may lose connectivity or fall back to a self-assigned address.

Real-world applications

  • Local ad-blocking via DNS sinkholes.
  • Zero-configuration printer discovery.

Where you will apply it

  • Projects 5-8, 10, 16

References

  • RFC 1034/1035 (DNS), RFC 2131 (DHCP)
  • RFC 6762/6763 (mDNS, DNS-SD)

Key insights Naming and configuration are invisible until they fail, then everything fails.

Summary DNS and DHCP are the core control plane of a home network.

Homework/Exercises to practice the concept

  1. Trace a DNS lookup from your device to the authoritative server.
  2. Capture a DHCP DORA exchange and label each step.

Solutions to the homework/exercises

  1. Use dig +trace and note each delegation.
  2. Filter UDP ports 67 and 68 and identify discover, offer, request, ack.

Operations, Diagnostics, and Security

Fundamentals Diagnostics and security are where theory becomes practical. ICMP provides feedback about connectivity, latency, and routing failures. Tools like ping and traceroute rely on ICMP to make network paths visible. Packet capture reveals the truth of what is happening on the wire, which is essential when logs or assumptions are wrong. Security in home/office networks is built on segmentation, stateful filtering, and secure Wi-Fi configuration. Understanding these tools and controls lets you diagnose failures quickly and prevent common threats.

Deep Dive ICMP is often misunderstood as “just ping,” but it is the control plane of IP. It reports unreachable destinations, TTL expiry, and fragmentation requirements. Traceroute manipulates TTL values to force routers along a path to send ICMP Time Exceeded messages, which reveals hop-by-hop routing. Understanding ICMP types and codes lets you differentiate between “host unreachable” and “port unreachable,” which can save hours of guessing. But ICMP is not guaranteed to be delivered, so diagnostics must be combined with other evidence like TCP resets and packet captures.

Packet capture is the definitive tool for understanding network behavior. A capture shows headers at every layer, timestamps, retransmissions, and the exact sequence of events that produced a failure. It also reveals hidden behaviors, such as DNS retries, TCP window size changes, or unexpected multicast traffic. Effective capture requires careful filtering and knowledge of what you are looking for. On switched networks, you may only see traffic destined for your host, so you may need port mirroring or monitor mode on Wi-Fi. Without this awareness, you can falsely conclude that traffic is not present when you are simply not observing the right link.

Security in home networks is primarily about reducing attack surface and limiting trust. A stateful firewall tracks connection state and allows return traffic while blocking unsolicited inbound flows. This is different from NAT, though NAT produces a similar effect. Segmentation isolates devices so that a compromised IoT device cannot reach sensitive systems. Wi-Fi security must protect the air interface using WPA2 or WPA3, and should avoid legacy configurations like WEP or open networks. VPNs create encrypted tunnels across untrusted networks; they can be site-to-site (linking networks) or remote access (linking a device to a network). VPNs also alter routing by creating new routes over the tunnel interface, which is why they sometimes break local network access or change DNS behavior.

Operational visibility is not just about troubleshooting failures. It is about validating performance and policy. A bandwidth monitor can show whether a device is saturating the uplink. A DNS sinkhole can show which devices are contacting malicious domains. A firewall log can show attempted scans or misconfigured services. These tools are the foundation of a healthy home or office network.

Finally, security is a system property, not a single setting. A strong Wi-Fi passphrase is meaningless if devices are on the same flat network with no segmentation. A firewall rule is only as good as the routing table that feeds it. The projects in this guide are structured to force you to test and verify these properties, not just configure them.

How this fit on projects Projects 2-4, 9-20 use diagnostics and security concepts directly.

Definitions & key terms

  • ICMP: Control messages for IP.
  • Stateful firewall: Filters traffic based on connection state.
  • Segmentation: Separating devices into isolated networks.
  • VPN: Encrypted tunnel over untrusted networks.

Mental model diagram

Client -> Router -> Internet
   |        |         |
   |   firewall state |
   |   ICMP feedback  |
   +-> capture point  |

How it works

  1. Use ICMP to test reachability and path.
  2. Capture packets to confirm actual behavior.
  3. Enforce policy with firewall and segmentation.
  4. Use VPNs to extend trust securely. Invariants: ICMP is best-effort, not guaranteed. Failure modes: blocked ICMP, asymmetric routing, misapplied firewall rules.

Minimal concrete example

Traceroute logic:
TTL=1 -> ICMP Time Exceeded from hop 1
TTL=2 -> ICMP Time Exceeded from hop 2
...

Common misconceptions

  • “If ping fails, the host is down.” ICMP may be blocked.
  • “NAT equals firewall.” NAT does not express security policy.

Check-your-understanding questions

  1. Why can traceroute fail even when the destination is reachable?
  2. Why might a VPN break access to local printers?

Check-your-understanding answers

  1. Routers or hosts may block ICMP Time Exceeded messages.
  2. VPN routes may override local routes, sending traffic into the tunnel.

Real-world applications

  • Diagnosing intermittent Wi-Fi dropouts.
  • Segmenting IoT devices away from trusted systems.

Where you will apply it

  • Projects 2-4, 9-20

References

  • RFC 792 (ICMP)
  • “TCP/IP Illustrated, Vol 1” by Stevens - Ch. 6

Key insights You cannot secure or fix what you cannot observe.

Summary Diagnostics and security are practical disciplines that transform network theory into reliable systems.

Homework/Exercises to practice the concept

  1. Capture a TCP handshake and annotate each packet.
  2. Design a guest network segmentation plan for your home.

Solutions to the homework/exercises

  1. Identify SYN, SYN-ACK, ACK, then the first data packet.
  2. Create a separate VLAN or SSID with no access to LAN subnets.

3. Project Specification

3.1 What You Will Build

An integrated home/office network stack that includes routing, NAT, DHCP, DNS, firewall, monitoring, and documentation.

Included:

  • CLI tool with clear output
  • Validation steps and logging
  • Documentation of assumptions

Excluded:

  • Production-grade performance tuning
  • Full security hardening

3.2 Functional Requirements

  1. Core function: Implement the primary behavior described in the project goal.
  2. Observable output: Produce deterministic output comparable to the Real World Outcome.
  3. Error handling: Handle timeouts, invalid inputs, and unreachable hosts gracefully.

3.3 Non-Functional Requirements

  • Performance: Complete typical tasks within a few seconds on a LAN.
  • Reliability: Fail safely and clearly on errors.
  • Usability: Provide concise CLI flags and helpful messages.

3.4 Example Usage / Output

$ ./stack_status
Router: online (NAT enabled)
DHCP: 12 active leases
DNS: 95% cache hit rate
Firewall: 4 rules, default deny
Monitoring: 24h bandwidth report saved

3.5 Data Formats / Schemas / Protocols

Protocols: Layering and Encapsulation, Link Layer and LAN Behavior (Ethernet, Wi-Fi, ARP, Switching), IP Addressing, Subnetting, and Routing (Including NAT), Transport and Ports (TCP and UDP), Naming and Configuration Services (DNS, DHCP, mDNS), Operations, Diagnostics, and Security.

3.6 Edge Cases

  • Target unreachable or timing out
  • Malformed or unexpected responses
  • Multiple interfaces or subnets

3.7 Real World Outcome

$ ./stack_status
Router: online (NAT enabled)
DHCP: 12 active leases
DNS: 95% cache hit rate
Firewall: 4 rules, default deny
Monitoring: 24h bandwidth report saved

3.7.1 How to Run (Copy/Paste)

  • Build: make (or create a virtual environment as needed)
  • Run: ./P20-home-network-capstone
  • Config: update any constants in a config file or flags
  • Working directory: project root

3.7.2 Golden Path Demo (Deterministic)

Run against a known local target and compare with the expected output.

3.7.3 If CLI: provide an exact terminal transcript

$ ./stack_status
Router: online (NAT enabled)
DHCP: 12 active leases
DNS: 95% cache hit rate
Firewall: 4 rules, default deny
Monitoring: 24h bandwidth report saved

4. Solution Architecture

4.1 High-Level Design

CLI Input -> Core Engine -> Output/Logs

4.2 Key Components

Component Responsibility Key Decisions
CLI Parser Parse flags and inputs Keep interface minimal
Core Engine Protocol logic and state Keep deterministic timing
Output/Logs Present results and errors Use consistent formatting

4.4 Data Structures (No Full Code)

Request:
  - target
  - protocol fields
Response:
  - status
  - timing
State:
  - retries
  - cache entries

5. Implementation Guide

5.1 Development Environment Setup

  • Ensure required tools (tcpdump, dig, ip) are installed.
  • Use elevated privileges where raw sockets are required.

5.2 Project Structure

project/
  README.md
  docs/
  src/
  tests/
  data/

5.3 The Core Question You’re Answering

“Can I design, build, and validate a complete network from the ground up?”

5.4 Concepts You Must Understand First

  1. End-to-end flow
    • How do all layers connect from client to internet?
    • Book Reference: “Computer Networks” - Ch. 1
  2. Service dependencies
    • Which services must come up first for a network to work?
    • Book Reference: “TCP/IP Illustrated, Vol 1” - Ch. 18-21
  3. Security posture
    • How do you segment and protect a mixed device network?
    • Book Reference: “Computer Networks” - Ch. 8

5.5 Questions to Guide Your Design

  1. Integration order
    • What is the minimal set of services for a functional network?
  2. Validation strategy
    • What tests prove each layer is working?

5.6 Thinking Exercise

Failure injection

If DNS fails but routing still works, what does the user experience?

Questions to answer:

  • How would you detect and isolate this failure?
  • What fallback can you provide?

5.7 The Interview Questions They’ll Ask

  1. “How would you design a secure home network?”
  2. “What are the dependencies between DHCP, DNS, and routing?”
  3. “How do you validate that NAT is working correctly?”
  4. “What monitoring signals would you collect?”
  5. “How would you recover from a misconfiguration?”

5.8 Hints in Layers

Hint 1: Build in layers Get routing and NAT working before services.

Hint 2: Add DHCP and DNS Validate clients can join and resolve names.

Hint 3: Pseudocode outline

- configure router and NAT
- bring up DHCP server
- bring up DNS resolver and sinkhole
- enable firewall rules
- verify with test clients

Hint 4: Verification Create a test checklist that covers link, IP, DNS, HTTP, and security.

5.9 Books That Will Help

Topic Book Chapter
Full stack view “Computer Networks” Ch. 1-8
DNS/DHCP “TCP/IP Illustrated, Vol 1” Ch. 18-21
Security “Computer Networks” Ch. 8

5.10 Implementation Phases

  1. Establish core protocol I/O and a minimal success path.
  2. Add parsing, validation, and timeouts.
  3. Add logging, metrics, and polish for output.

5.11 Key Implementation Decisions

  • Which interface and capture point provides visibility?
  • What timeout and retry strategy balances speed and accuracy?
  • How will results be validated against reference tools?

6. Testing Strategy

6.1 Test Categories

  • Unit: parsing and validation logic
  • Integration: protocol exchange with a real device
  • System: full run with reference tools

6.2 Critical Test Cases

  • Successful request/response path
  • Timeout and retry behavior
  • Invalid or unexpected input handling

6.3 Test Data

  • Local gateway IP and a known reachable host
  • A non-routable IP to trigger timeouts

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Problem 1: “Everything seems up but internet fails”

  • Why: NAT or DNS misconfiguration.
  • Fix: Validate NAT translations and DNS queries separately.
  • Quick test: Resolve by IP then by name.

Problem 2: “Clients join but cannot reach each other”

  • Why: Overly strict firewall or segmentation rules.
  • Fix: Add explicit allow rules for trusted subnet.
  • Quick test: Ping between two trusted devices.

7.2 Debugging Strategies

  • Capture traffic with tcpdump or Wireshark.
  • Compare against a known-good tool.
  • Log timestamps and retry logic.

7.3 Performance Traps

  • Excessive retries causing long runtimes.
  • Inefficient parsing under high packet rates.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add basic configuration flags for interface and timeout.
  • Improve output formatting and sorting.

8.2 Intermediate Extensions

  • Add caching or state persistence.
  • Add CSV or JSON output export.

8.3 Advanced Extensions

  • Add concurrency with careful rate limiting.
  • Add visualization or integration with a dashboard.

9. Real-World Connections

9.1 Industry Applications

  • Network diagnostics and troubleshooting
  • Security monitoring and policy enforcement
  • tcpdump / Wireshark
  • nmap / dnsmasq / unbound (as applicable)

9.3 Interview Relevance

  • Explaining protocol behavior
  • Diagnosing failures by layer

10. Resources

10.1 Essential Reading

Topic Book Chapter
Full stack view “Computer Networks” Ch. 1-8
DNS/DHCP “TCP/IP Illustrated, Vol 1” Ch. 18-21
Security “Computer Networks” Ch. 8

10.2 Video Resources

  • Wireshark or tcpdump walkthroughs (search for recent tutorials)
  • Vendor or RFC explainers for the relevant protocol

10.3 Tools & Documentation

  • RFCs for the protocols used in this project
  • man tcpdump, man ip, man ss