The OSI and TCP/IP Models, Retrofitted to Your Own Session

33.0 What this chapter gives you#

1. You will be able to say why networks are built in layers at all, what each layer is allowed to know, and what it is forbidden to know.
2. You will be able to name all seven OSI layers, define each one, and say what unit of data each one handles.
3. You will be able to explain that the OSI model came from a standards effort begun in 1977, published as ISO 7498 in 1984, and that the protocol suite it was built for lost to TCP/IP while the model survived as a teaching tool.
4. You will be able to name the four layers of the TCP/IP model, cite RFC 1122 from October 1989 as the document that states them, and map the two models against each other with real protocols in every row.
5. You will be able to place every single thing from the reader’s own broken session at exactly one layer, and say which chapter covered it.
6. You will be able to walk one real HTTP request down the stack with real header sizes, and state what fraction of the bytes on the air were payload.
7. You will be able to show, with evidence, that layers 1, 2 and 3 worked in that session, that layer 4 did not complete, and that layers 5 to 7 were never reached at all.
8. You will be able to use the general fault rule: find the highest layer that works and the lowest that fails, and the fault is between them.
9. You will be able to list the places the model is simply wrong about reality, including TLS, VPNs, MPLS, NAT and QUIC, without losing faith in the model.
10. You will be able to spot the same layering pattern in graphics, storage and compilers, and see it as general engineering rather than a networking curiosity.

33.1 Why layers exist at all#

PLAIN33.1.1 in simple words#

1. A network has to do many different jobs at once.
2. It must turn bits into a real signal, get data across one hop, get data across the world, notice losses and resend them, hide the contents from watchers, and agree what the contents mean.
3. So we split the work into layers. A layer is one level of the job.
4. Each layer does one kind of work. Each layer uses the layer below it and does not care how that layer works. Each layer offers a service upward and does not care what the layer above does with it.
5. The benefit is large. You can rip out one layer, put in a completely different one, and nothing above it needs to change.
6. The reader can carry the laptop out of the flat, join a friend’s wired network instead of the home WiFi, and the same git push works.
7. And when a failure crosses layers, nobody owns it, because each layer can honestly say it did its own job correctly.

PLAIN33.1.2 a picture in your head#

1. Think about posting a birthday card to a cousin in another city.
2. You put it in an envelope and write the address. Now the card can be handled by people who will never read it.
3. A worker empties the post box into a sack with a label saying which sorting office it goes to. A van carries the sack down a road.
4. That is layering. Each level has its own wrapping, its own address format, and its own workers who ignore everything else.

Where this comparison breaks:

5. In the post, the envelope survives the whole journey. In a network, the outer wrapping is thrown away and rebuilt at every single router. Only the middle wrapping, the IP header, travels end to end.
6. The post does not chop your card into forty numbered pieces, send them by different roads, and glue them back together. TCP does exactly that.
7. And in the post the address on the envelope is the real address of the real house. On the internet, the address on the reader’s packets was rewritten twice on the way out, by two different machines. That is NAT, Chapter 24.

PLAIN33.1.3 a worked example#

1. Here is the benefit, made concrete. The reader is on home WiFi in a flat in India, with a router at 192.168.0.1. Now imagine plugging in a cable.

2. The git program has no code in it for radio and none for copper. It does not know which is in use and cannot easily find out.
3. WiFi sometimes loses a frame because somebody switched on a microwave oven.
4. TCP was designed for wires, where “something is missing” almost always means the network is too busy. So TCP does the thing that helps a busy network. It slows down.
5. That is the price of the rule that a layer may not look below itself. It is also why WiFi does its own resending, so TCP never finds out.

PLAIN33.1.4 what is really happening inside#

1. A layer is not a place. It is a piece of code with a defined edge, and that edge is an interface: the short list of things the layer above is allowed to ask for.
2. The internet layer offers upward, roughly: “give me a lump of bytes and a destination address, and I will try to deliver it”.
3. The transport layer offers a much stronger promise: “give me a stream of bytes and I will deliver them all, in order, exactly once”.
4. Going down, each layer adds a small block of information at the front, called a header, holding only what that layer needs: addresses, lengths, numbers, flags.
5. So a packet is boxes inside boxes, with the message innermost. That wrapping is called encapsulation, and section 33.5 measures it in real bytes.
6. One strict rule: a layer must be replaceable without the layer above noticing. If replacing it breaks something above, the boundary was drawn in the wrong place.

TECHNICAL33.1.5 the engineer’s version#

1. The OSI vocabulary is worth knowing because it still appears in specs. A layer N entity talks to its peer using a protocol, and to layer N-1 on the same machine using a service.
2. A PDU at one layer is an SDU at the layer below. That is the cleanest one-line definition of encapsulation there is.
3. The costs of layering are documented, not folklore. RFC 3439, “Some Internet Architectural Guidelines and Philosophy”, by Randy Bush and David Meyer, December 2002, contains a section titled “Layering Considered Harmful”.

4. The counterweight is the end-to-end argument, from Saltzer, Reed and Clark, “End-to-End Arguments in System Design”, presented in 1981 and published in ACM Transactions on Computer Systems in 1984.
5. Its claim: a function such as reliability can only be completely and correctly implemented at the endpoints, so putting it in the network is at best a performance optimization, never a substitute.
6. Experts genuinely disagree about how strictly boundaries should hold. One camp treats any cross-layer visibility as technical debt. The other says wireless, mobility and congestion control cannot be done well without it.
7. Tools that isolate one layer on macOS: ifconfig for layers 1 and 2, arp -a for the layer 2 to 3 mapping, netstat -rn and traceroute for layer 3, nc -vz for layer 4, openssl s_client for TLS, and curl -v and dig for layer 7.

WORDS33.1.6 remember these#

1. Layer — one level of the job — a set of functions with a service interface upward and a peer protocol to the same layer remotely.
2. Header — the small label a layer adds — a prefix carrying that layer’s control information only.
3. Encapsulation — a box inside a box — a layer N PDU becoming the payload, or SDU, of a layer N-1 PDU.
4. PDU — the parcel a layer sends — protocol data unit, the unit exchanged between peer entities at one layer.
5. End-to-end argument — the ends must check, the middle cannot be trusted to — the principle from Saltzer, Reed and Clark, 1981 and 1984.

33.2 The OSI seven-layer model#

PLAIN33.2.1 in simple words#

1. In the late 1970s a large international committee set out to write down, once and for all, how computer networks should be built.
2. They split the job into seven layers, numbered 1 at the bottom to 7 at the top. Here they are, bottom first.
3. Layer 1, physical. Turning bits into something real: a voltage, a light pulse, a radio wave. It handles single bits.
4. Layer 2, data link. Getting a chunk of data across one hop, to the next box on the same local network. It handles frames.
5. Layer 3, network. Getting a chunk of data across many hops to a machine anywhere in the world. It handles packets.
6. Layer 4, transport. Making delivery reliable and ordered, and choosing which program on the machine gets it. It handles segments.
7. Layer 5, session. Starting, pausing and stopping a long conversation.
8. Layer 6, presentation. Agreeing how things are written down, and doing encrypting and squashing.
9. Layer 7, application. The thing you wanted: fetching a page, sending mail, pushing code.
10. Now the honest part. Layers 1, 2, 3 and 4 describe real things you can point at and measure.
11. Layers 5 and 6 barely describe anything that exists. In real systems that work is done inside the application or inside a library.

PLAIN33.2.2 a picture in your head#

1. Think of a large company that wrote a rulebook for how any two of its offices must exchange goods.
2. The rulebook has seven chapters. Chapter 1 covers the loading bay, 2 the local van, 3 the national route, 4 checking nothing was lost. Chapters 5, 6 and 7 cover the meeting: opening it, agreeing a language, and the business.
3. Then a smaller, scruffier company down the road ships goods using four scribbled pages, and wins every customer, because the four pages already worked while the seven chapters were still being argued over.
4. Twenty years later every logistics course still teaches the seven chapters, because they are the clearest description of the job. Everybody actually ships using the four scribbled pages.

Where this comparison breaks:

5. The OSI effort was not slow because the people were bad. It was slow because it was a genuine international consensus process across many governments and many computer makers, and consensus is slow.

PLAIN33.2.3 a worked example#

1. Place one ordinary thing at all seven layers: the reader’s laptop asking github.com for something.
2. Layer 7: the intent, “give me the list of branches”, expressed in HTTP.
3. Layer 6: the text is written as UTF-8 bytes and the whole thing is encrypted by TLS. Both are presentation-flavoured jobs.
4. Layer 5: the connection is opened, reused for several requests, then closed. In practice HTTP and TLS do this themselves. No separate session program exists.
5. Layer 4: TCP opens a connection to port 443, numbers every byte, and resends anything lost.
6. Layer 3: IP puts 20.207.73.82 on the front and asks the network to carry it.
7. Layer 2: 802.11 puts the router’s hardware address on the front and sends it over WiFi to 192.168.0.1.
8. Layer 1: the radio turns those bits into a 5 GHz signal in the air.
9. Notice how thin layers 5 and 6 were. That is not a flaw in the example. That is what the model looks like when you apply it honestly.

PLAIN33.2.4 what is really happening inside#

1. The unit of data has a different name at each layer, and engineers use the names precisely.
2. Bits at layer 1. Frames at layer 2. Packets at layer 3. Segments at layer 4 for TCP, datagrams for UDP. Just “data” at layers 5, 6 and 7.
3. Using the wrong word signals that you have not understood the model. A router does not forward frames end to end. It forwards packets and builds a new frame for each hop.
4. Layer 2 uses a MAC address, burned into the hardware, meaningful only on the local link.
5. Layer 3 uses an IP address, meaningful worldwide, changeable by software in a second.
6. Layer 4 uses a port number, which picks a program on one machine.
7. Four naming systems, and three lookups between them: DNS turns names into IP addresses, ARP turns IP addresses into MAC addresses, and the operating system turns port numbers into programs.

TECHNICAL33.2.5 the engineer’s version#

1. The layers with their PDU names and real examples.

2. Layer 1, physical: the mechanical, electrical, functional and procedural means to activate and maintain a connection for bit transmission. It defines connectors, voltages, modulation and timing, and has no notion of a message.
3. Layer 2, data link: transfer across a single physical link, including framing, physical addressing, error detection and, on shared media, access control. It is bounded by the link. It does not route.
4. Layer 3, network: delivery across an arbitrary number of intermediate links, including logical addressing, routing and fragmentation.
5. Layer 4, transport: end-to-end delivery between processes, including multiplexing by port, reliability, ordering and flow control.
6. Layer 5, session: establishment, management and termination of dialogues, including checkpointing and synchronization points.
7. Layer 6, presentation: syntax and semantics of transferred data, including representation conversion, compression and encryption.
8. Layer 7, application: the interface to the application process, not the application itself.
9. The history, with dates. Work began in ISO Technical Committee 97, Subcommittee 16, in 1977, created specifically to produce an open systems architecture.
10. Charles Bachman, at Honeywell, is generally credited with proposing the seven-layer structure to that subcommittee in 1977 and 1978. He had won the ACM Turing Award in 1973 for his database work.
11. Hubert Zimmermann published the readable statement of it, “OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection”, in IEEE Transactions on Communications, April 1980.
12. The model was published as the international standard ISO 7498 in 1984, and in parallel by CCITT, now ITU-T, as Recommendation X.200.
13. OSI was never only a model. It was a full protocol suite meant to replace everything: X.25 and CLNP at the network layer, TP0 to TP4 at transport, X.400 for mail, X.500 for directory, FTAM for files.
14. Governments mandated it. In the United States, FIPS 146, the Government OSI Profile or GOSIP, made OSI protocols a requirement for federal procurement from August 1990. The 1995 revision permitted TCP/IP and the mandate ended.
15. Why it lost is argued about, but the usual reasons are: TCP/IP was already deployed and free, the OSI specifications were large and expensive to obtain, implementations lagged the standards by years, and the ARPANET had completed its own switch to TCP/IP on 1 January 1983.
16. Andrew L. Russell’s article “OSI: The Internet That Wasn’t”, IEEE Spectrum, July 2013, is the standard readable account.
17. Now the part most courses omit: OSI pieces that survived and that you use.

18. IS-IS deserves a pause. It is ISO/IEC 10589, an OSI routing protocol, adapted to carry IP by RFC 1195 in December 1990, and it runs inside some of the largest carrier backbones in the world.
19. X.509 came out of the X.500 directory work in 1988. Every TLS certificate the reader’s browser checks is an X.509 certificate encoded in ASN.1 DER. Both are OSI presentation-layer artefacts.
20. On layers 5 and 6, be blunt. No mainstream internet protocol implements a separate session or presentation entity. RFC 1122 does not have them. Anyone who says TLS “is layer 6” is using a convenient label, not a standard.

WORDS33.2.6 remember these#

1. OSI — the seven-layer teaching model — Open Systems Interconnection Basic Reference Model, ISO 7498:1984 and ITU-T X.200.
2. Frame — the parcel on one hop — the layer 2 PDU, with link addresses and a frame check sequence.
3. Packet — the parcel for the whole journey — the layer 3 PDU, with source and destination IP addresses.
4. X.509 — the format of a website’s certificate — the ITU-T certificate standard from the 1988 X.500 series, encoded in ASN.1 DER.
5. IS-IS — a routing protocol from the OSI family — ISO/IEC 10589, extended for IP by RFC 1195, widely used in carrier cores.
6. GOSIP — the government rule that OSI must be bought — US FIPS 146, mandatory from August 1990, relaxed in 1995.

33.3 The TCP/IP four-layer model#

PLAIN33.3.1 in simple words#

1. The internet you are actually using was not built from the seven-layer model. It was built from a smaller, older, plainer set of ideas.
2. That set has four layers.
3. The link layer: getting bits across one hop. This is the OSI physical and data link layers rolled into one.
4. The internet layer: getting a packet across the world. This is IP, and only IP.
5. The transport layer: getting a stream to the right program, reliably. This is TCP and UDP.
6. The application layer: everything else. HTTP, DNS, SSH, mail, git. This is OSI layers 5, 6 and 7 rolled into one.
7. Notice the shape: a thin waist in the middle. There is exactly one internet layer protocol, IP, and everything above and below is plural.
8. That shape is called the hourglass. Many link technologies below, many applications above, one IP in the middle.

PLAIN33.3.2 a picture in your head#

1. Picture an hourglass made of glass, standing on a table.
2. The wide top is full of sand grains of every colour: web, mail, video calls, games, git, software updates, streaming.
3. The wide bottom is also full of different grains: WiFi, Ethernet, fibre, 4G, 5G, satellite, Bluetooth.
4. The narrow neck is one single grain type. That is IP. Every grain from the top must pass through it.
5. Because the neck is one thing everybody agreed on, the top and the bottom can each change completely without asking permission.

Where this comparison breaks:

6. The neck is not as narrow as the picture suggests. There are two IPs now, version 4 and version 6, and making them coexist has taken thirty years and is unfinished. The reader’s machine reported IPv6: (none), which is that unfinished job showing up in a flat in India.
7. And the neck is being widened from above. QUIC, in section 33.8, pushed transport logic up into applications, which the clean picture does not allow.

PLAIN33.3.3 a worked example#

1. Take the reader’s curl -v https://github.com and label it in four layers instead of seven.

Application  HTTPS request for github.com, plus the
             TLS handshake, plus the earlier DNS query
Transport    TCP connection to 20.207.73.82 port 443
Internet     IPv4 packets, source 192.168.0.x,
             destination 20.207.73.82, TTL counting down
Link         802.11 frames over 5 GHz WiFi to the MAC
             address of 192.168.0.1

2. Try the same with seven layers and you will find yourself arguing about whether TLS is 5 or 6, and where the DNS query belongs.

PLAIN33.3.4 what is really happening inside#

1. The four-layer model is written into the document that tells you how to build a host: RFC 1122, October 1989, “Requirements for Internet Hosts - Communication Layers”, edited by Robert Braden.
2. Its companion RFC 1123, published the same month, covers the application layer in detail. Together they are the closest thing the internet has to a constitution for end machines, and they are still cited in new work.
3. The reason the internet model came first is chronology. IP was specified in RFC 791 in September 1981 and TCP in RFC 793 the same month. ISO 7498 appeared in 1984. Working code beat the committee by three years.

TECHNICAL33.3.5 the engineer’s version#

1. The mapping table, with real protocols in every row. This is the one to memorize.

2. ARP is placed at “Internet” above, and that is a compromise. ARP has its own EtherType, 0x0806, and rides directly on Ethernet, so it is not carried by IP, yet its entire purpose is to serve IP. RFC 1122 discusses it under the link layer. Textbooks place it at 2, at 3 and at “2.5”. All are defensible.
3. ICMP is carried inside IP packets, protocol number 1, so structurally it sits above IP. Yet it is universally called a layer 3 protocol because its job is network control. RFC 1122 requires every host to implement it.
4. Numbers worth carrying for the protocols in that table:

5. RFC 9293, August 2022, is the current consolidated TCP specification. RFC 793 is obsolete as a citation, though every engineer still says “793” out of habit. RFC 8200, July 2017, is IPv6 as a full internet standard, replacing RFC 2460 from 1998.

WORDS33.3.6 remember these#

1. TCP/IP model — the four-layer picture of the real internet — the internet architecture as stated normatively in RFC 1122, October 1989.
2. Link layer — the “one hop” level — OSI layers 1 and 2 combined: framing, link addressing and the physical medium.
3. Internet layer — the “whole world” level — IP, plus ICMP and the routing protocols that populate the forwarding table.
4. Hourglass — many things above, many below, one in the middle — the property that IP is the single universal convergence layer.

33.4 The reader’s own session, layer by layer#

PLAIN33.4.1 in simple words#

1. Everything the reader saw in one broken evening is going to be put in its place in the model, one layer at a time.
2. That is worth doing for one reason: once a thing has a layer, a fault in it has a layer, and a fault with a layer is a fault you can find.
3. The setting: a flat in India, a home broadband line, a Mac on WiFi, and a git push to GitHub that would not go.
4. The evidence gathered was a traceroute that reached twelve hops, a curl that sat silent for fifteen seconds, a DNS answer that was correct, and the same site loading instantly on mobile data.

PLAIN33.4.2 a picture in your head#

1. Picture a tall office block with seven floors and a parcel chute down the middle.
2. On floor 7 somebody writes a note: “send me the list of branches”. They fold it into a bag, label the bag, and drop it to floor 6.
3. Floor 5 labels which conversation it belongs to. Floor 4 adds a piece number so nothing is lost. Floor 3 adds the street address of the far building. Floor 2 names the next van driver. Floor 1 loads the van.
4. At the far building the same seven floors unwrap in the opposite order, each removing only its own label, until floor 7 reads the note.

Where this comparison breaks:

5. Nothing physically moves down the floors. The message is written once into one block of memory, and each layer writes its header into space reserved in front of it. There is no copying and no chute.
6. And the labels are not equal. The floor 3 label, the IP address, is the only one that survives the whole journey. The floor 2 label is torn off and rewritten at every building on the route.

PLAIN33.4.3 a worked example#

1. Here is the whole session sorted by layer. This table is the answer to “where does everything I have learned actually go”.

2. Eighteen rows, every one a real observed thing from one evening.

PLAIN33.4.4 what is really happening inside#

Layer 1, physical: the radio in the air.

1. What it is: the level that turns ones and zeros into something physical that travels. Voltage on copper, light in glass, or a radio wave in air.
2. What sits here: the WiFi radio inside the Mac and the matching radio inside the box at 192.168.0.1, working at either 2.4 GHz or 5 GHz.
3. This layer is why walls matter and why a microwave oven can slow a download. Covered in Chapter 23, “Networking From Zero”.

Layer 2, data link: getting across the room.

4. What it is: the level that moves a chunk of data across exactly one hop, to the next box sharing the same wire or the same air.
5. What sits here: the 802.11 frame, the addresses burned into the hardware, and the ARP question that found the router.
6. A MAC address is a six-byte number fixed to a network card. It means something only on the local network and never travels past the router.
7. The Mac knew the router’s IP address, 192.168.0.1, but a radio card cannot send to an IP address. It needs a MAC address.
8. So the Mac shouted to everybody on the local network: “who has 192.168.0.1, tell me your hardware address”. That question is ARP.
9. The router answered, and the Mac then put that hardware address on the front of every frame it sent.
10. The box at 192.168.0.1 is three devices in one shell: a radio access point, a small switch, and a router. The switch part lives entirely at this layer. Covered in Chapter 23.

Layer 3, network: getting across the world.

11. What it is: the level that carries a packet across many hops, through machines that have never heard of you, to any address on earth.
12. What sits here: every single IP address the reader saw.
13. 192.168.0.1 is the router, a private address valid only inside the flat.
14. 20.207.73.82 is what github.com resolved to: a public address in a Microsoft-owned range.
15. 172.31.0.17 at hop 2, and the 172.26.x addresses at hops 4, 5 and 6, are also private, but they belong to the reader’s internet provider, not to the flat. A provider using private addresses in its own core is normal and is covered in Chapter 24.
16. 137.97.29.249 at hop 3 is a public address belonging to the provider.
17. Every IP packet carries a counter called TTL, time to live. Every router it passes reduces the counter by one. At zero the router discards the packet and sends back a complaint.
18. Traceroute abuses that on purpose. It sends a packet with the counter set to 1, then 2, then 3, and collects the complaints. Each one names a router. That is how the reader’s twelve-hop list was made.
19. Routing is the question of which way to send a packet next. Between companies that is answered by BGP, the protocol by which every network tells its neighbours which addresses it can reach.
20. BGP is why hop 7 was the first machine named ntwk.msn.net. At that point the packets left the provider and entered Microsoft’s own network.
21. Covered in Chapter 24 for addresses, and in the routing chapter for TTL, traceroute and BGP.

Layer 4, transport: reaching the right program, reliably.

22. What it is: the level that turns “a machine” into “a program on a machine”, and turns unreliable delivery into a reliable stream.
23. What sits here: TCP, the number 443, and the fifteen seconds of silence.
24. An IP address gets you to a machine. A port number picks which program on it. 443 is the agreed number for secure web traffic.
25. TCP does not just start sending. It performs a three-step greeting.
26. Step one: the Mac sends a small packet marked SYN, meaning “I would like to open a connection”.
27. Step two: the server should reply with SYN and ACK, meaning “yes, and I would like one too”.
28. Step three: the Mac replies ACK, and only then may real data flow.
29. In the reader’s session step one happened, over and over. Step two never happened, not once.
30. curl printed Trying 20.207.73.82:443..., waited fifteen seconds and gave up. That was the Mac patiently repeating step one. Covered in the TCP chapter.

Layers 5 and 6, the awkward ones: TLS.

31. What they are supposed to be: managing a conversation, and agreeing how things are written and encrypted.
32. What sits here: TLS, the thing that puts the S in HTTPS. It sits above TCP and below HTTP, turning a plain reliable stream into a secret, tamper-proof reliable stream.
33. The honest version: TLS does not fit. Its own specification never mentions an OSI layer number. It is not a session layer, because HTTP manages its own sessions. It is not a presentation layer, because it converts no data formats. It is wedged into a gap the model did not plan for.
34. In this session TLS never ran at all. TLS needs a working TCP connection before it can say its first word. Covered in the TLS chapter.

Layer 7, application: the thing you actually wanted.

35. What it is: the protocol that says what the request means.
36. What sits here: three separate application protocols, all involved in one git push.
37. HTTP is the request-and-response language of the web. HTTPS is that same language carried inside TLS.
38. DNS is the naming service. Before anything else, the Mac asked 1.1.1.1 what github.com meant and got back 20.207.73.82.
39. Git has an application protocol of its own, spoken inside HTTP, which sends a pack of objects and receives progress messages back.
40. The error the reader saw twice, send-pack: unexpected disconnect while reading sideband packet, comes from that git protocol. The sideband is the side channel git uses for progress text while a pack transfers.
41. That is a layer 7 error message describing a layer 4 event. Section 33.6 returns to it, because it is the most useful thing in this chapter.
42. Covered in Chapter 25 for DNS, in the HTTP chapter for HTTP and HTTPS, and in the git chapters for the pack protocol.

TECHNICAL33.4.5 the engineer’s version#

Layer 1, physical.

1. Home WiFi uses two delicensed bands: roughly 2.400 to 2.4835 GHz, and roughly 5.15 to 5.85 GHz. Exact permitted sub-bands differ by country and change over time, so check your national regulator rather than a textbook.
2. In the 2.4 GHz band only three 20 MHz channels do not overlap: 1, 6 and 11. In 5 GHz there are far more, bondable into 40, 80 or 160 MHz.
3. 802.11ac uses OFDM with up to 256-QAM, 8 bits per symbol; 802.11ax adds 1024-QAM at 10 bits per symbol. Subcarrier spacing is 312.5 kHz for 802.11a, n and ac.
4. Received signal strength in dBm is the number to look at.

Layer 2, data link.

5. An 802.11 data frame header is 24 bytes: frame control 2, duration 2, three 6-byte address fields, and sequence control 2. A QoS data frame adds a 2-byte QoS control field, giving 26.
6. To carry IP, an 8-byte LLC/SNAP header is inserted, ending in EtherType 0x0800. On Ethernet that EtherType sits in the 14-byte header instead.
7. WPA2 with CCMP adds an 8-byte header and an 8-byte message integrity check. A 4-byte CRC-32 frame check sequence closes every frame.
8. WiFi acknowledges every unicast frame at layer 2 and retransmits if the ACK is missing. Ethernet does not. That is the duplicated-reliability cost from section 33.1, made real.
9. ARP is RFC 826, November 1982, by David Plummer. A request is a broadcast to ff:ff:ff:ff:ff:ff with EtherType 0x0806.
10. Inspect the cache with arp -a, which prints lines like ? (192.168.0.1) at 1c:3b:f3:0a:9e:71 on en0 ifscope [ethernet]. An entry reading (incomplete) means the request went unanswered, which is a pure layer 2 fault. Watch it live with sudo tcpdump -i en0 -n arp.

Layer 3, network.

11. The IPv4 header is 20 bytes with no options: version and header length 1, DSCP and ECN 1, total length 2, identification 2, flags and fragment offset 2, TTL 1, protocol 1, header checksum 2, source 4, destination 4.
12. Address classification for the session, against RFC 1918, February 1996:

13. The 172.16.0.0/12 block covers 172.16.0.0 through 172.31.255.255, so every 172.16, 172.26 and 172.31 address above is private. This is the range people most often misread.
14. TTL is an 8-bit field. macOS sets an initial TTL of 64. Each forwarding router decrements it and recomputes the header checksum, because the header changed.
15. At zero the router discards the packet and returns ICMP type 11 code 0, time exceeded in transit, per RFC 792, September 1981. Traceroute, written by Van Jacobson in 1987, exists entirely to harvest those.
16. macOS traceroute sends UDP probes to high ports by default, three per hop. traceroute -I uses ICMP echo, and traceroute -P TCP -p 443 uses TCP, which is the more informative test when one port is suspected.
17. The reader’s hops 5, 6, 8, 9 and 11 each printed more than one address. That is equal-cost multi-path forwarding: three probes took three parallel links. It is a healthy sign, not a fault.
18. From hop 7 every name ends in ntwk.msn.net, which is Microsoft network infrastructure. The city codes are airport-style: del01 Delhi, bom01 Mumbai, pnq20 and pnq21 Pune.
19. The role and interface codes are Microsoft naming conventions, not standards: ibr internal backbone router, rwa regional wide-area router, owr outer wide-area router, and ae, be and po all meaning a bundle of physical links acting as one logical link.
20. Inter-domain routing is BGP-4, RFC 4271, January 2006, descended from RFC 1105 in 1989. Microsoft’s best known autonomous system number is 8075. I have not verified which AS announces the exact prefix containing 20.207.73.82, so treat that attribution as likely rather than proven.

Layer 4, transport.

21. The TCP header is 20 bytes minimum. A macOS SYN typically carries 20 bytes of options, giving a 40-byte header and a 60-byte IP packet with no payload at all. Typical options are maximum segment size, window scale, selective acknowledgement permitted, and timestamps, with NOP bytes for alignment.
22. Port 443 is the IANA-registered port for HTTP over TLS. Port 22 is SSH. Both appear in this session and only one of them worked.
23. The initial retransmission timeout is 1 second per RFC 6298, June 2011, and doubles on each retry. So in fifteen seconds the Mac sends a SYN at roughly t=0, 1, 3, 7 and 15 seconds: about five packets, about 300 bytes, and zero bytes received.
24. macOS bounds the whole connect attempt with the sysctl net.inet.tcp.keepinit, default 75000 milliseconds, so 75 seconds. curl gave up at 15 seconds, well before the kernel would have.
25. What did not happen is the evidence. No TCP RST came back, which would have meant a closed port. No ICMP type 3 came back, which would have meant a device admitting it refused the packet. Nothing came back.
26. Confirm the shape with sudo tcpdump -i en0 -n 'host 20.207.73.82 and tcp port 443'. Repeated outbound Flags [S] lines with nothing inbound is the exact signature. Test one port quickly with nc -vz -G 5 20.207.73.82 443.

Layers 5 and 6, TLS.

27. The TLS record header is 5 bytes: content type 1, legacy version 2, length
    2. Under TLS 1.3 with an AEAD cipher such as AES-128-GCM, each record also carries a 16-byte authentication tag and one byte of real content type inside the encrypted body.
28. A full TLS 1.3 handshake costs one round trip before application data: ClientHello with a key share, then ServerHello, EncryptedExtensions, Certificate, CertificateVerify and Finished, then the client’s Finished.
29. The ClientHello carries the server name extension, SNI, containing the text github.com. Whether that name is visible on the wire depends on whether Encrypted Client Hello is in use at both ends; check its current standards status before relying on it either way.
30. None of this ran. TLS is carried over TCP and TCP never opened, so the reader’s machine never emitted a single TLS byte to 20.207.73.82.
31. Test this layer alone with openssl s_client -connect github.com:443 -servername github.com, which separates a TLS fault from a TCP fault by showing how far it got.

Layer 7, application.

32. DNS is RFC 1034 and RFC 1035, November 1987, over UDP and TCP port 53. The reader’s resolver was 1.1.1.1, Cloudflare’s public resolver, not the router. It answered 20.207.73.82, correctly and fast.
33. HTTP/1.1 is now RFC 9112, June 2022, replacing RFC 7230 from 2014 and RFC 2616 from 1999. HTTP/2 is RFC 9113 and HTTP/3 is RFC 9114.
34. Git over HTTPS uses the smart HTTP protocol: a GET of /info/refs?service=git-receive-pack for discovery, then a POST to /git-receive-pack carrying the pack.
35. Git frames its own messages in pkt-line format: a four-character hexadecimal length prefix followed by that many bytes, with 0000 as a flush marker. That is layer 7 framing inside HTTP inside TLS inside TCP.
36. The sideband multiplexes three channels in one stream: channel 1 pack data, channel 2 progress text, channel 3 a fatal error. send-pack: unexpected disconnect while reading sideband packet means the stream ended while git was waiting for the next pkt-line on that side channel.
37. Observe layer 7 with dig github.com, curl -v, and GIT_TRACE_PACKET=1 git push, which prints every pkt-line git exchanges.

WORDS33.4.6 remember these#

1. MAC address — the hardware name of a card — a 48-bit link-layer address whose top 24 bits are an IEEE-assigned OUI.
2. ARP — the shout that finds a router’s hardware address — Address Resolution Protocol, RFC 826, EtherType 0x0806, broadcast request, unicast reply.
3. TTL — the counter that stops packets circling forever — an 8-bit IPv4 field decremented per hop, triggering ICMP type 11 at zero.
4. BGP — how networks tell each other what they can reach — Border Gateway Protocol version 4, RFC 4271, the inter-domain routing protocol.
5. SYN — the first word of a TCP conversation — the synchronize flag opening the three-way handshake, retransmitted with exponential backoff.
6. SNI — the site name sent before encryption starts — Server Name Indication, the TLS extension letting one address serve many certificates.
7. pkt-line — how git chops its own stream into messages — a four-hex-digit length prefix plus payload, with 0000 as a flush packet.
8. Sideband — the channel carrying progress text — git’s multiplexing of pack data, progress and errors over one connection.

33.5 Encapsulation walked through with real numbers#

PLAIN33.5.1 in simple words#

1. Encapsulation means putting a thing inside a bigger thing that carries it. Every layer does it, adding a small label at the front of what it was given.
2. So the message you cared about ends up buried in the middle of a much bigger bundle of bytes.
3. This costs you. The labels are real bytes, sent over the real air, taking real time, and you are paying for them.
4. The answer, for a small request over WiFi, is that roughly four bytes in every ten are labels rather than message.
5. For large transfers the picture is much better, because the labels stay the same size while the message gets bigger.

PLAIN33.5.2 a picture in your head#

1. Think of wooden nesting dolls, the kind where each one opens with a smaller one inside.
2. The smallest doll is a folded note: the thing you actually wanted to send.
3. Around it goes a doll marked “secret”, which locks. That is TLS.
4. Around that, a doll marked “piece 4 of 9”. That is TCP.
5. Around it goes a doll marked “secret”, which locks. That is TLS.
6. Around that, a doll with the far building’s street address. That is IP.
7. Around that, a doll naming the courier taking it to the end of the road. That is WiFi. You post the outermost doll.

Where this comparison breaks:

8. Real dolls get much thicker at each level. Network headers do not. The IP header is 20 bytes whether it wraps 1 byte or 1,460.
9. And a real doll survives the journey. The outermost network shell is stripped and rebuilt at every router, with different labels every time.

PLAIN33.5.3 a worked example#

1. Here is one real, complete HTTP request, of the kind git sends when it starts talking to GitHub.

GET /kedbyte/notes.git/info/refs?service=git-upload-pack HTTP/1.1
Host: github.com
User-Agent: git/2.39.5 (Apple Git-154)
Accept: */*
Accept-Encoding: deflate, gzip
Pragma: no-cache

2. Counting every character, including the carriage return and line feed ending each line and the blank line that closes the headers, that is exactly 190 bytes.
3. Now watch it grow on the way down, one layer at a time.

4. Final answer: 318 bytes go over the air to carry 190 bytes of request.
5. That is 128 bytes of overhead, 40.3 percent of the frame. The payload is 59.7 percent.

PLAIN33.5.4 what is really happening inside#

1. Nothing is copied five times. The operating system allocates one buffer and deliberately leaves empty space at the front, called headroom.
2. Each layer writes its header backwards into that space and moves a pointer. The message bytes never move.
3. On macOS and the BSD family that buffer is an mbuf. On Linux it is an sk_buff. Both reserve headroom for exactly this reason.
4. This is why “the data travels down through the layers” is a teaching lie. Section 33.98 says so plainly.
5. The one place bytes really are copied is the boundary between the kernel and the network card, and modern cards use DMA to avoid even that.

TECHNICAL33.5.5 the engineer’s version#

1. The full nesting, drawn to scale of description rather than of size.

+--------------------------------------------------------+
| 802.11 QoS data frame          318 bytes               |
| hdr 26|CCMP 8|LLC 8|...|MIC 8|FCS 4                    |
| +----------------------------------------------------+ |
| | IPv4 packet                    264 bytes           | |
| | IP header 20 bytes                                 | |
| | +------------------------------------------------+ | |
| | | TCP segment                    244 bytes       | | |
| | | TCP header 20 + options 12                     | | |
| | | +--------------------------------------------+ | | |
| | | | TLS 1.3 record                 212 bytes   | | | |
| | | | rec hdr 5 + type 1 + AEAD tag 16           | | | |
| | | | +----------------------------------------+ | | | |
| | | | | HTTP GET request         190 bytes     | | | | |
| | | | | the only part anyone wanted            | | | | |
| | | | +----------------------------------------+ | | | |
| | | +--------------------------------------------+ | | |
| | +------------------------------------------------+ | |
| +----------------------------------------------------+ |
+--------------------------------------------------------+

2. The 128 bytes of overhead, itemized so you can check every number.

3. On wired Ethernet the layer 2 cost would be 18 bytes rather than 54: a 14-byte header and a 4-byte FCS. The same request would be 282 bytes on the wire and 67.4 percent payload.
4. Layer 1 on WiFi is not measured in bytes at all. It is measured in microseconds, and that is where the true overhead hides.
5. Approximate airtime for that single 318-byte frame on 5 GHz, 802.11ac, one spatial stream, 80 MHz, at a physical rate of 433 Mbit/s:

6. Read that again. The data itself occupies under 3 percent of the airtime. Everything else is protocol.
7. Efficiency improves enormously with size.

8. 1,398 is not arbitrary. From a 1,500-byte MTU, subtract 20 for IP and 32 for TCP with timestamps to get an MSS of 1,448, then subtract 22 for the TLS record, leaving 1,426 bytes of application data. Round down further for a VPN or PPPoE header, which is why 1,398 and 1,400 are common settings.
9. Read real header sizes off the wire with tcpdump -i en0 -v -X, or open a capture in Wireshark, where each layer appears as an expandable tree in exactly the nesting shown above.

WORDS33.5.6 remember these#

1. Encapsulation — putting a message inside a bigger envelope — wrapping a layer N PDU as the payload of a layer N-1 PDU.
2. Overhead — the bytes that are not your message — header and trailer bytes as a fraction of the transmitted unit.
3. Headroom — the empty space in front of the message — reserved bytes at the start of a kernel packet buffer so headers can be prepended without copying.
4. MTU — the biggest frame a link will carry — maximum transmission unit, 1,500 bytes for standard Ethernet.
5. MSS — the biggest chunk of data one TCP segment carries — maximum segment size, the MTU minus the IP and TCP headers.
6. FCS — the check at the end of a frame — frame check sequence, a 32-bit CRC letting the receiver discard corrupted frames.

33.6 Where the reader’s failure sits in the model#

PLAIN33.6.1 in simple words#

1. The question is not “what is wrong”. It is “which layer is wrong”, because that is a question evidence can answer.
2. Layer 1 worked. The laptop was on the WiFi, frames were going out and coming back. If the radio were dead nothing at all would have happened.
3. Layer 3 worked, and this is the strong evidence. The traceroute reached twelve routers, the last inside Microsoft’s network in Pune.
4. Think about what that proves. Packets from the flat crossed the provider’s network, entered Microsoft’s, travelled Delhi to Mumbai to Pune, and complaints from those routers came all the way back.
5. Layer 4 did not complete. The laptop said hello to port 443 about five times over fifteen seconds and was never answered.
6. Layers 5, 6 and 7 were never attempted. TLS cannot start without TCP, HTTP cannot start without TLS, git cannot start without HTTP.
7. So the fault is at layer 4, or in something that only affects layer 4 traffic to that address.
8. That is a far smaller question than “the internet is broken”, and it was reached in about two minutes of evidence gathering.

PLAIN33.6.2 a picture in your head#

1. Imagine a lift in a tall building that is not arriving. You could stand there guessing, or you could check floors.
2. On floor 4 you press and nothing happens. No light, no sound, no error.
3. You now know something precise: the fault is at or just below floor 4, and floors 5, 6 and 7 have not been tested and cannot be, because you cannot get to them.

Where this comparison breaks:

4. In a building, a fault on floor 4 is on floor 4. On a network, the thing that broke layer 4 may sit at layer 3, in a router that drops only packets with certain port numbers.
5. So “the fault is at layer 4” means “the symptom is at layer 4”. The cause may be a device operating below it that inspects above itself. Section 33.8 is about exactly that dishonesty.

PLAIN33.6.3 a worked example#

1. The evidence table. Left, the layer. Middle, what was observed. Right, what that proves.

2. That is not a contradiction. DNS to 1.1.1.1 is a different destination on UDP port 53, not TCP port 443. It took a different path with a different transport, and it succeeded.
3. The most useful thing was the mobile data test: the same request over a different provider’s network succeeded instantly.
4. Change one variable, hold the rest. The variable that changed was the path from layer 1 to layer 3. The failure followed the path, not the machine and not the server.

PLAIN33.6.4 what is really happening inside#

1. Find the highest layer that demonstrably works, and the lowest layer that demonstrably fails. The fault is between them.
2. Work from the bottom up, because a low layer failing makes every test above it meaningless.
3. There is no point debugging a certificate error if ARP is failing. The certificate error is a lie told by a program that could not reach anything.
4. The traceroute proves that packets reached hop 12 and replies returned. It proves nothing about hops 13 onward, because routers commonly refuse to send the replies traceroute needs.
5. Silence at the end of a traceroute is normal and is not evidence of a fault. Saying otherwise is the most common mistake in network diagnosis.
6. What settled the reader’s case was a TCP connection attempt that got no response of any kind, combined with the same attempt succeeding over a different network.
7. That combination supports one conclusion: something on that particular path silently discarded the packets. It does not identify who, and honest diagnosis stops there.

TECHNICAL33.6.5 the engineer’s version#

1. The outcomes of a TCP connection attempt, and what each proves, are the sharpest diagnostic in networking.

2. The reader got the fourth row. A RST would have meant packets arrived and something answered. An ICMP unreachable would have meant a device admitted responsibility. Silence means neither.
3. The sequence of commands that produces this evidence, in order:

ifconfig en0 | grep -E 'status|inet '
arp -a | grep 192.168.0.1
ping -c 3 192.168.0.1
traceroute -n 20.207.73.82
traceroute -P TCP -p 443 -n 20.207.73.82
nc -vz -G 5 20.207.73.82 443
nc -vz -G 5 20.207.73.82 22
dig +short github.com @1.1.1.1
curl -v --max-time 15 https://github.com

4. Line 5 is the one most people omit and the most informative: a TCP traceroute to port 443 shows how far port 443 traffic specifically gets, which a UDP or ICMP traceroute cannot tell you.
5. Compare lines 6 and 7. In the reader’s session one transport worked and the other did not, localizing the problem to something treating port 443 differently from port 22.
6. Note what that does not prove. It does not prove who is doing the treating, nor that it is deliberate. Consistent with the evidence: a filter, a misrouted prefix, an overloaded state table, or an asymmetric return path. Not consistent: the server being down, since the same address served the same content over mobile data.
7. The git error from the same session, send-pack: unexpected disconnect while reading sideband packet, is the same lesson in a different costume: a layer 7 message whose real cause was a layer 4 connection dying mid-stream.
8. That is why the error tells you nothing about whether the push landed. The disconnect happened while reading the response. The write may already have been applied on the server. The only correct action is to re-query the remote state, never to assume from the error text.

WORDS33.6.6 remember these#

1. Bottom-up diagnosis — check the ground floor first — testing layers in ascending order so no test is invalidated by a lower failure.
2. Silent drop — the packet vanishes with no complaint — a discard with no RST and no ICMP error, giving the sender no information at all.
3. RST — a slammed door — the TCP reset flag, meaning the host was reached and refused the connection.
4. ICMP unreachable — a written refusal — ICMP type 3, with codes for host, network, port and administrative prohibition.
5. Localizing — narrowing where the fault is — changing exactly one variable at a time until the failure follows the variable.

33.7 A fault-to-layer table#

PLAIN33.7.1 in simple words#

1. If you learn the shape of each failure, the error message tells you where to look before you have run a single command.
2. The table in this section is the one to pin above your desk. Read it in either direction: from a symptom find the layer, or from a layer find the command that tests it.

PLAIN33.7.2 a picture in your head#

1. Think of a doctor with a list: fever means one family of causes, a rash another, a limp a third.

Where this comparison breaks:

2. A body has one owner. A network path crosses many, and the layer showing the symptom is often not the layer that owns the cause.

PLAIN33.7.3 a worked example#

1. Symptoms and the tool that settles each one.

2. The same nine rows, each with a real example.

3. The last row is from the reader’s own session. A push was refused because the personal access token did not carry the workflow scope and the push changed a CI workflow file.
4. That failure is as high in the stack as a failure can be. Every layer below it worked perfectly. The bytes arrived, were decrypted, were understood, and were then declined on policy grounds.

PLAIN33.7.4 what is really happening inside#

1. Two rules make the table usable. First, an error message names the layer that noticed, not the layer that failed. Git’s sideband error was written at layer 7 about a layer 4 event.
2. Second, the higher the layer, the more specific the error text, and the more likely it is to be honest about itself.
3. A 403 from an API tells you precisely what is wrong. A timeout tells you almost nothing, because a timeout is what you get when nobody spoke.
4. So an ugly, detailed error message is good news. Silence is bad news, because the failure is low and nobody on the path will explain themselves.

TECHNICAL33.7.5 the engineer’s version#

1. Exact commands, roughly one per layer, on macOS.

# 1 physical / 2 link
ifconfig en0 | grep -E 'status:|ether|inet '
system_profiler SPAirPortDataType | grep -A4 'Current Net'
# 2 link
arp -a -n | grep 192.168.0.1
sudo tcpdump -i en0 -n arp
# 3 network
netstat -rn -f inet | head
ping -c 3 -W 1000 192.168.0.1
traceroute -n -w 1 -q 3 20.207.73.82
# 4 transport
nc -vz -G 5 20.207.73.82 443
sudo tcpdump -i en0 -n 'host 20.207.73.82 and tcp'
# 5/6 TLS
openssl s_client -connect github.com:443 -servername github.com
# 7 application
dig +short github.com @1.1.1.1
curl -v -i --max-time 15 https://github.com
GIT_TRACE_PACKET=1 GIT_CURL_VERBOSE=1 git push

2. Interpretation notes that are easy to get wrong.
3. ping failing does not prove layer 3 is broken. Many networks and hosts drop ICMP echo by policy. Use it as positive evidence only.
4. nc -vz reporting “Connection refused” is a success for layers 1 to 4. It means a RST came back, so packets reach the host in both directions.
5. openssl s_client printing verify error:num=20 means it could not build a chain to a trusted root, usually a missing intermediate certificate on the server, not an expired one. Read the number.
6. curl exit codes are layered too, which makes them a shortcut: 6 is DNS failure, 7 is connect failure, 28 is timeout, 35 is a TLS handshake error, 60 is certificate verification failure.

WORDS33.7.6 remember these#

1. Symptom — what you see — the observable behaviour, belonging to the layer that reported it, not necessarily the layer at fault.
2. NXDOMAIN — the name does not exist — the DNS response code for a queried name with no records at all.
3. Verify error 20 — the chain could not be built — OpenSSL’s code for unable to get local issuer certificate, usually a missing intermediate.
4. Connection refused — a host said no — an RST in response to a SYN, which proves bidirectional reachability.
5. Scope — what a token is permitted to do — the permission set attached to a credential, checked at the application layer after everything else worked.

33.8 Where the model lies#

PLAIN33.8.1 in simple words#

1. The layered model is a map. The internet is the territory. The map is wrong in several specific, well-known places.
2. Five places matter, and every working engineer meets all five.
3. First, TLS does not fit anywhere. It sits between transport and application and belongs to neither.
4. Second, a VPN carries whole layer 3 packets inside a layer 7 connection, so the layers stop being an order and become a loop.
5. Third, MPLS is so awkwardly placed that the industry gave up and invented the number 2.5 for it.
6. Fourth, NAT reaches into two layers at once and rewrites both, which the model says is forbidden.
7. Fifth, QUIC moved the transport layer out of the operating system and into ordinary programs.

PLAIN33.8.2 a picture in your head#

1. Think of a road map of a city printed in 1984.
2. But a tunnel has been dug that the map does not show, a one-way street has been reversed, and two roads have been merged into a flyover.

Where this comparison breaks:

3. A map can be reprinted. The OSI model cannot, because its value is that everybody already agreed on the numbers. Fixing it would destroy the only thing it is good for.

PLAIN33.8.3 a worked example#

1. The reader’s own Mac showed several utun interfaces. Those are tunnel interfaces, and they are the clearest example of the model folding in on itself.
2. The VPN software takes that whole packet, encrypts it, and sends it as the payload of another connection, which has its own layer 3 and 4 headers.
3. So the order, reading outward, is: application, TLS, TCP, IP, and inside that, IP again, TCP again, TLS again, application again.
4. Layer 3 is now above layer 7. The model has no vocabulary for that.

PLAIN33.8.4 what is really happening inside#

1. The honest version: layers are not a physical fact about packets. They are a naming scheme for functions.
2. A packet does not know it is layer 3. It is a sequence of bytes that some piece of code chooses to read as an IP header.
3. Once you see that, tunnelling stops being strange. It is bytes carried by bytes.
4. And middleboxes stop being strange too. Nothing physically prevents a router from reading a TCP header, or a firewall from reading an HTTP path. The model says they should not. It cannot stop them.

TECHNICAL33.8.5 the engineer’s version#

1. The five violations, precisely.
2. TLS. RFC 8446, August 2018, never assigns TLS an OSI layer number. TLS requires a reliable ordered byte stream below it and presents one above it, which makes it a transport-layer shim, but it performs no multiplexing and no addressing, which are the defining transport functions. Industry usage is inconsistent: load-balancer vendors say “layer 7”, security vendors say “layer 6”, researchers write “layer 4.5”. None is normative.
3. VPNs. WireGuard, released by Jason Donenfeld in 2016 and merged into Linux 5.6 in March 2020, carries IP inside UDP inside IP: layer 3 over 4 over 3. OpenVPN, from James Yonan in 2001, can carry IP inside TLS inside TCP. IPsec, RFC 4301 from December 2005, carries IP inside IP. VXLAN, RFC 7348 from August 2014, carries Ethernet frames inside UDP: layer 2 over 4.
4. MPLS. RFC 3031, January 2001. The shim header is 4 bytes: a 20-bit label, 3 traffic class bits, 1 bottom-of-stack bit and an 8-bit TTL. It sits between the layer 2 and layer 3 headers, and forwarding uses the label instead of the IP address. It is neither layer 2 nor layer 3, so the industry calls it layer 2.5. That number appears in no standard.
5. NAT. RFC 3022, January 2001, updating RFC 1631 from May 1994. A NAT rewrites the layer 3 source address and the layer 4 source port together, then recomputes both the IP header checksum and the TCP or UDP checksum, because the transport checksum covers a pseudo-header containing the IP addresses. One device edits two layers in a single operation, and must understand the layer above it to do so at all.
6. The reader’s own traffic was translated at least twice: once by the box at 192.168.0.1, and again inside the provider’s private core at the 172.31 and 172.26 addresses, which is carrier-grade NAT.
7. QUIC. RFC 9000, May 2021, with HTTP/3 in RFC 9114, June 2022. QUIC implements connection setup, reliability, ordering, flow control and congestion control, all transport functions, in user space over UDP.
8. Three consequences follow. Transport logic now ships and updates on the browser’s schedule instead of the operating system’s. Most of the transport header is encrypted, so middleboxes cannot read or modify it. And streams are independent, so one lost packet no longer stalls the others, which was TCP’s head-of-line blocking problem.
9. Two more untidy cases. ARP has no clean layer: it uses its own EtherType rather than riding on IP, yet exists solely to serve IP. ICMP is carried inside IP yet is universally treated as part of layer 3.
10. Summary of the lies, with the honest placement.

11. Keep the model anyway. Nobody has proposed a replacement that is both more accurate and as easy to talk about, and the numbers are how engineers communicate during incidents.

WORDS33.8.6 remember these#

1. Tunnel — carrying a whole packet inside another packet — encapsulating a layer N PDU inside a protocol at or above layer N.
2. Middlebox — a device in the path that reads above its own layer — NATs, firewalls, proxies and load balancers that inspect layer 4 or 7.
3. MPLS — forwarding by label instead of address — Multiprotocol Label Switching, RFC 3031, a 4-byte shim between layers 2 and 3.
4. TCP meltdown — two reliability timers fighting — throughput collapse from running TCP inside a TCP tunnel.
5. Head-of-line blocking — one lost piece stalling everything behind it — the TCP property that QUIC’s independent streams remove.
6. Pseudo-header — why NAT must fix two checksums — the IP address fields included in the TCP and UDP checksum computation.

33.9 Why layering still earns its keep#

PLAIN33.9.1 in simple words#

1. After a section listing what is wrong with the model, the fair question is whether it is worth keeping. It is, for three reasons. First, modularity: each piece can be built, tested and replaced on its own.
2. Second, independent innovation. Anyone can improve one layer without asking permission from the layers above or below.
3. Third, reasoning about faults. The whole of section 33.6 was only possible because the parts had names and an order.
4. The second reason is the one that built the internet. Nobody had to coordinate. A radio company could invent faster WiFi while a browser company invented a faster web, and neither had to speak to the other.

PLAIN33.9.2 a picture in your head#

1. Think of the standard shipping container, introduced in the 1950s.
2. The container is the agreed shape in the middle. Everything above and below it changed completely over seventy years. IP is that container.

Where this comparison breaks:

3. A container is a physical object with a fixed size. An IP packet is a convention that anyone can, and does, quietly violate with tunnels.

PLAIN33.9.3 a worked example#

1. Three real cases where one layer changed enormously and nothing above it needed to know.
2. Case one, layers 1 and 2. Ethernet ran at 10 Mbit/s in 1980 and now runs at 400 Gbit/s. That is 40,000 times faster.
3. The frame format did not change: six bytes of destination address, six of source, two of type. An IP stack written for 10 Mbit/s Ethernet describes the same frame that crosses a modern data centre.
4. Case two, layers 1 and 2 again, at home. The reader’s household connection would have been a dial-up modem in the 1990s, then ADSL over a phone line, then fibre, and on a phone it is 4G or 5G radio.
5. Case three, the awkward TLS layer. TLS 1.3 was published as RFC 8446 in August 2018 and replaced almost everything about the handshake: two round trips became one, old ciphers were deleted, the negotiation was redesigned.
6. Web applications did not change. Servers and browsers were upgraded, and the HTTP requests flowing over the top were byte-for-byte identical.

PLAIN33.9.4 what is really happening inside#

1. The mechanism behind all three cases is a stable interface. As long as the service offered upward keeps its shape, the implementation beneath can be replaced entirely.
2. This is the same reason a program written in 1990 still runs on a modern processor: the instruction set is a stable interface, and everything under it was rebuilt many times.
3. It is also why badly drawn boundaries cause so much trouble. NAT broke the assumption that an address is stable end to end, and the internet is still paying for it thirty years later.

TECHNICAL33.9.5 the engineer’s version#

1. Concrete figures for the three cases.

2. Ethernet’s frame format is essentially unchanged since the DIX Ethernet version 2 specification of 1982 and IEEE 802.3, approved in 1983. Later additions such as the 4-byte 802.1Q VLAN tag from 1998 are insertions, not redesigns.
3. Wi-Fi shows the same pattern at layer 1: 802.11 in 1997 at 2 Mbit/s, 802.11b in 1999 at 11 Mbit/s, 802.11g in 2003 at 54 Mbit/s, 802.11n in 2009, 802.11ac in 2013, 802.11ax as Wi-Fi 6 in 2021, and Wi-Fi 7 certification from January
   2024. The MAC frame the reader’s laptop sends is recognizably the 1997 frame.
4. The counterexample proves the rule. IPv6, specified in 1998 and now RFC 8200 from July 2017, changed the layer everything else depends on, and adoption has taken three decades. The reader’s machine reported IPv6: (none).

WORDS33.9.6 remember these#

1. Modularity — building in replaceable pieces — decomposition into units with stable interfaces and hidden implementations.
2. Stable interface — the promise that does not change — the contract a layer offers upward, permitting its implementation to be replaced.
3. Narrow waist — the one thing everybody must agree on — the single universal convergence protocol, IP, in the internet architecture.
4. Ossification — the network becoming hard to change — the effect of middleboxes depending on details protocols never promised to keep.

33.10 The same idea outside networking#

PLAIN33.10.1 in simple words#

1. Layering is not a networking idea. It is an engineering idea that networking happens to describe most carefully.
2. In graphics, a game does not talk to a graphics chip. It talks to a library, which talks to a driver, which talks to the chip.
3. In storage, a program does not talk to flash memory. It writes a file, which a filesystem turns into numbered blocks, which a driver turns into commands, which the drive turns into operations on cells.
4. In compilers, your source becomes tokens, then a tree, then a neutral intermediate form, then machine instructions, then something smaller still inside the processor.

PLAIN33.10.2 a picture in your head#

1. Think of a restaurant. You read a menu, not a recipe. The cook reads a recipe, not a farm. The farm grows food without knowing any menu.

Where this comparison breaks:

2. In a restaurant a customer can walk into the kitchen. In a well-built software stack, upper levels usually cannot reach past the level below, and when they can, that shortcut becomes a bug that lasts for years.

PLAIN33.10.3 a worked example#

1. The graphics stack, top to bottom, with the reader’s Mac in mind.

Your program          draw this triangle
Graphics API          Metal, Vulkan, OpenGL calls
Driver                translates to GPU commands
Command buffer        a queue in shared memory
GPU hardware          thousands of small cores

2. The storage stack has the same shape.

Your program          write("notes.txt", data)
Filesystem            APFS or ext4: file -> blocks
Block layer           queue, scheduling, caching
Driver                NVMe or SATA commands
Flash translation     pretends to be numbered sectors
NAND cells            charge trapped in floating gates

3. The flash translation layer is the interesting one. It presents a lie upward: it pretends the drive is numbered sectors that can be overwritten in place. NAND flash cannot do that at all.
4. That is exactly what NAT does at layer 3, and it causes the same class of surprises: performance that does not match the model, and behaviour that only makes sense once you know about the hidden layer.

PLAIN33.10.4 what is really happening inside#

1. The compiler stack has the same shape. Source text becomes tokens, tokens become a tree, and the tree becomes an intermediate representation that belongs to no particular processor.
2. The value of the neutral middle form is the value of IP: many languages above it, many processors below it, one thing in the middle.

TECHNICAL33.10.5 the engineer’s version#

1. Stable interfaces acting as narrow waists, outside networking.

2. LLVM began as Chris Lattner’s work at the University of Illinois around 2000 to 2003, and its intermediate representation is now the middle layer for Swift, Rust, Clang and many others.
3. Direct3D appeared in 1995, Metal in 2014, Vulkan 1.0 in February 2016. All are the same architectural move: a stable command interface above a driver that changes with every hardware generation.
4. NVMe 1.0, published in March 2011, replaced the disk-shaped assumptions of older interfaces with a queue-based one while keeping the block abstraction above it unchanged. Filesystems did not need rewriting.
5. The instruction set architecture is the layer boundary that matters most in a processor: the same binary runs on chips from different companies with entirely different internal designs, which is precisely the layering promise.

WORDS33.10.6 remember these#

1. Abstraction layer — a level that hides the mess below — a module presenting a simplified interface over a more complex implementation.
2. Intermediate representation — the neutral middle form in a compiler — a machine-independent program form such as LLVM IR.
3. Flash translation layer — the part that makes flash look like a disk — the controller firmware mapping logical blocks to physical NAND pages.
4. Instruction set architecture — the contract between software and a chip — the documented instructions and behaviour a processor must implement.
5. Leaky abstraction — when the mess below shows through — an interface whose performance or failure behaviour reveals its implementation.

33.98 Common wrong ideas#

1. Wrong: data physically travels down through the layers. Right: nothing moves. The message sits in one buffer with reserved space at the front, and each layer writes its header into that space and moves a pointer. On a Mac that buffer is an mbuf, on Linux an sk_buff.
2. Wrong: TCP/IP has seven layers. Right: the internet architecture stated in RFC 1122, October 1989, has four: link, internet, transport and application. Seven is OSI, a different model from a different organization.
3. Wrong: the OSI model is what the internet uses. Right: the internet uses protocols designed before OSI existed. IP was RFC 791 in September 1981; ISO 7498 appeared in 1984. OSI survives as vocabulary and as a teaching frame, not as the running system.
4. Wrong: layer 8 is a real layer, for the user. Right: there is no layer 8 in ISO 7498 or any standard. It is a joke that became a habit, and using it in a serious document marks you as guessing.
5. Wrong: TLS is layer 6. Right: no standard says so. RFC 8446 assigns no layer number. TLS sits between transport and application and is called 5, 6 or 4.5 by different vendors, all informally.
6. Wrong: the traceroute stopped, so that is where the fault is. Right: routers commonly refuse to send the ICMP time-exceeded replies traceroute needs. Stars at the end of a trace are normal. The reader’s trace ended in stars after hop 12 and that fact alone proved nothing.
7. Wrong: a router forwards frames. Right: a router forwards packets. It discards the incoming layer 2 frame entirely and builds a new one for the next hop with different addresses. Only the layer 3 header survives end to end, minus the TTL.
8. Wrong: switches work at layer 3 because they have IP addresses. Right: the management address on a switch is for talking to the switch. Its forwarding decisions use MAC addresses, which is layer 2. A device that forwards on IP addresses is a router, whatever the box is labelled.
9. Wrong: an error message tells you which layer failed. Right: it tells you which layer noticed. Git’s send-pack: unexpected disconnect while reading sideband packet is a layer 7 message describing a layer 4 event.
10. Wrong: if the model and the network disagree, the network is doing it wrong. Right: the model is a map. NAT, VPNs, MPLS and QUIC all break it, they are all deployed at enormous scale, and they are not going away.

33.99 Chapter summary in 20 lines#

1. Layering splits network work into levels, where each level uses the level below without knowing how it works and serves the level above.
2. The benefit is that a whole level can be replaced and nothing above notices: radio to copper, dial-up to fibre, TLS 1.2 to TLS 1.3.
3. The cost is duplicated work, hidden information, header overhead, and faults that cross layers and belong to nobody. RFC 3439 from December 2002 says so in a section titled “Layering Considered Harmful”.
4. OSI has seven layers: physical, data link, network, transport, session, presentation, application, handling bits, frames, packets, segments and data.
5. It came from ISO subcommittee 16 starting in 1977, was described by Hubert Zimmermann in 1980, and was published as ISO 7498 in 1984, also ITU-T X.200.
6. The OSI protocol suite lost to TCP/IP. GOSIP made it a US federal purchasing requirement in August 1990 and the mandate was relaxed in 1995.
7. Pieces of OSI did survive and you use them daily: X.509 certificates, ASN.1 encoding, IS-IS routing in carrier backbones, and LDAP descended from X.500.
8. Layers 5 and 6 barely map onto anything real. No mainstream internet protocol implements a separate session or presentation entity.
9. The TCP/IP model has four layers: link, internet, transport, application, stated normatively in RFC 1122, October 1989.
10. Its shape is an hourglass: many link technologies below, many applications above, and exactly one IP in the middle.
11. In the reader’s session, layer 1 was the 5 GHz WiFi radio, layer 2 was the 802.11 frame and the ARP lookup for 192.168.0.1, and layer 3 was every IP address from 192.168.0.1 to 20.207.73.82, including the private ISP hops 172.31.0.17 and 172.26.x.
12. Layer 4 was TCP to port 443, layers 5 and 6 were TLS, and layer 7 was DNS to 1.1.1.1, HTTP, and git’s own pack and sideband protocol.
13. Encapsulating one real 190-byte HTTP GET produced a 318-byte WiFi frame: 22 bytes of TLS, 32 of TCP, 20 of IP and 54 of 802.11, so 40.3 percent overhead and 59.7 percent payload.
14. At layer 1 the picture is worse. That frame occupies about 6 microseconds of a roughly 207-microsecond airtime slot, under 3 percent.
15. The reader’s failure sits precisely at layer 4. Layers 1, 2 and 3 reached hop 12 inside Microsoft’s network in Pune, layer 4 never completed its handshake, and layers 5 to 7 were never attempted.
16. The general rule: find the highest layer that demonstrably works and the lowest that demonstrably fails, and the fault is between them.
17. Each layer has a signature failure and a tool that tests it: ifconfig, arp -a, ping, traceroute, nc -vz, openssl s_client, dig, curl.
18. The model lies in five well-known places: TLS fits nowhere, VPNs put layer 3 inside layer 7, MPLS is called layer 2.5, NAT rewrites layers 3 and 4 together, and QUIC moved transport into user space over UDP.
19. Keep the model anyway. It is how engineers talk to each other during incidents, and no clearer replacement has been proposed.
20. The same pattern runs through graphics, storage and compilers, so learning it once pays for itself far outside networking.