Network: Part 5. Network Layer

The era of simple solutions

In January 1974, Vint Cerf and Bob Kahn published the article "A Protocol for Packet Network Intercommunication" in IEEE Transactions on Communications: heterogeneous networks with different addresses, packet sizes, and reliability were supposed to exchange data through a single intermediate protocol. Half a century later, all of the world's communication rests on this idea. As of October 2026, the global BGP routing table contains 1,085,491 IPv4 prefixes announced by approximately 79,744 autonomous systems — and every packet between them is processed by the mechanisms of the network layer: addressing, route lookup, forwarding, congestion control, and fragmentation.

The paradox of the network layer is that the most important layer of the global network is designed to be deliberately unreliable. IP does not guarantee delivery, order, or payload integrity, and it does not protect against forgery of the sender's address. A modern backbone router forwards hundreds of terabits per second, while the decisions about where to direct each packet are made by a protocol that in 1981 described a network of several hundred hosts. And yet this "dumb" network has survived growth by a factor of millions, the exhaustion of its own address space, three decades of attempts to replace it with a new protocol, and countless accidents.

This paradox gives rise to a series of critical questions for anyone who designs or operates networks:

1. The architectural question. Why did the Internet choose the connectionless datagram model — as opposed to the virtual circuits that the telecommunications industry of the 1970s–1990s insisted on? What had to be paid for it?
2. The scalability question. The routing table grew from hundreds of entries in ARPANET to over a million prefixes. Which mechanisms — hierarchy, aggregation, CIDR — kept it from consuming all the memory of routers, and why does it continue to grow even though it could be 44% smaller?
3. The economic question. The Internet is routed not by geography, but by economics: BGP is a protocol of policies, not of metrics, and the path between two buildings in the same city may run through another continent, because that is cheaper according to the providers' contracts.
4. The congestion question. In October 1986, the throughput of an ARPANET section dropped a thousandfold — from 32 Kbit/s to 40 bit/s. Congestion collapse and "bufferbloat" still determine why a video call "stutters" while the internet is working.
5. The security question. The network layer has no built-in authentication: anyone can announce someone else's addresses or forge the sender's address. This has led to route hijacks, shutdowns of entire countries, and cryptocurrency thefts; the industry's answer — RPKI, filtering, and MANRS — has been deployed only partially.
6. The evolution question. IPv4 addresses have been running short since the 1990s; they lasted another thirty years — thanks to NAT, a "crutch" that nobody planned to make permanent. The transition to IPv6 has been going on since 1998 and only by 2026 reached half of users.

Next we will go through the entire network layer: from the historical roots and the two competing models of the network — through IP addressing, ARP, the internal structure of the router and routing algorithms — to BGP and the economics of the Internet, congestion, fragmentation, NAT, anycast, MPLS and SDN, tunnels and security. In the finale we will trace the path of a single packet from a home laptop to a server in a data center. The material is based on IETF standards, the classic networking literature, and the practice of operating modern networks.

The birth of the network layer: from packet switching to the "catenet"

Packet switching: Baran, Davies, and the priority dispute

The idea underlying the network layer is older than the Internet itself. In the early 1960s, Paul Baran of the RAND Corporation was looking for a way to build a communication system that would survive a nuclear strike. In the eleven-volume report "On Distributed Communications" (1960–1964) he proposed a distributed network of nodes transmitting messages in small blocks on the "hot potato" principle: each node immediately forwards the block onward. AT&T rejected the idea — the telephone monopoly saw no reason to break the proven model of circuit switching.

Independently of Baran, in 1965 Donald Davies of the British National Physical Laboratory (NPL) proposed a similar scheme, introduced the very term "packet," and built the real NPL Mark I network (1967–1970). The dispute over who holds the priority — Baran, Davies, or Leonard Kleinrock of UCLA, whose queueing theory formed the basis of the mathematical description of such networks — has been dragging on for decades. What matters is something else: by the end of the 1960s the idea was "in the air," and it was the Americans who implemented it.

In 1969 the ARPA agency commissioned the company BBN to build ARPANET. The first interface message processor (IMP — the ancestor of the router), based on the Honeywell DDP-516, was delivered to UCLA on September 2, 1969; the BBN team was led by Frank Heart. On October 29, 1969, student Charlie Kline attempted to transmit the word LOGIN from Los Angeles to the Stanford Research Institute; the system managed to send the letters L and O, after which it crashed. The first message in the history of the Internet was "Lo."

The first IMPs solved tasks that today we would call network layer tasks: they chose a route for each packet according to tables built by a distributed algorithm based on distance vectors with the "hop count" metric. The algorithm suffered from the same diseases as modern RIP — slow convergence and "counting to infinity" — and in 1979 it was replaced by an algorithm based on link state, the prototype of OSPF.

Louis Pouzin's Cyclades and the birth of the datagram

The decisive conceptual step was made not by an American, but by a Frenchman. Louis Pouzin, who headed the Cyclades network (1971–1974), turned the familiar scheme upside down: instead of the network being responsible for reliable delivery (as in X.25 and in ARPANET itself), Cyclades shifted that duty to the end hosts, and the network transmitted simple unacknowledged packets — datagrams (the very word "datagram" was introduced by Pouzin). The routers kept no state about flows: each packet was processed independently, which made the network simple, cheap, and resilient to node failures.

In 1974 Pouzin wrote a memo about the "catenet" (a "chain network"), a system of interconnected networks in which packets travel between heterogeneous networks through gateways. The memo landed on the desk of Vint Cerf and Bob Kahn, who were at that very moment struggling with uniting ARPANET, the PRNET packet radio networks, and the SATNET satellite network. Pouzin's ideas — the datagram, the "dumb" network and "smart" hosts — directly influenced the architecture of TCP/IP.

Cyclades itself perished: the French state bet on X.25 networks (Transpac, which later served the famous Minitel), and by the end of the 1970s Pouzin's experiment was shut down. The victory of X.25 in France turned out to be Pyrrhic — the world chose the Cyclades model.

ARPANET, the "catenet," and the 1974 protocol

Cerf and Kahn's 1974 article described a single internetworking protocol: TCP, which at that time included both datagram routing and reliable delivery. By 1978 it became clear that the tasks needed to be separated, and Cerf, Kahn, Postel, and Cohen arrived at a two-level scheme — TCP for connections and IP for delivering datagrams across network boundaries. The nodes connecting networks were called gateways in the RFCs of that time; the term "router" came into use later.

The key principle was "fate sharing," described later by Dave Clark: the state of a connection is stored on the end hosts, right where its participants are. If an intermediate node dies, the connection is not lost irretrievably: the hosts are alive, the state is with them, and they can restore communication over a new path. For a network created for military failure scenarios, this was more important than any performance optimization.

RFC 791 and the "Flag Day" of January 1, 1983

In September 1981 a set of documents was released that defined the Internet for the next forty years: RFC 791 (IP), RFC 792 (ICMP), and RFC 793 (TCP), edited by Jon Postel. And on January 1, 1983, ARPANET was switched from NCP to TCP/IP — a transition that went down in history as Flag Day. Postel had been preparing it for years, sending host administrators letters promising to disconnect everyone who did not upgrade by the deadline; the operation went surprisingly smoothly. There were several hundred hosts at the time — compare that with 2026, when any similar protocol replacement stretches out over decades.

The design philosophy: the end-to-end argument and the hourglass

In 1984, Jerome Saltzer, David Reed, and David Clark formulated the "end-to-end argument": a function can be completely and correctly implemented only at the end nodes, so placing it deep inside the network makes sense only as an optimization. Reliability, delivery order, security — these are the duties of the edges of the network, not of its core. Hence — "a dumb network and smart hosts," a principle that still distinguishes the Internet from telephony.

In 1988, David Clark published "The Design Philosophy of the DARPA Internet Protocols," laying out the goals of the architecture by priority: the main one — operation under conditions of failure (fate sharing), then — support for heterogeneous services, then — economic efficiency and scalability. The same idea is expressed by the "hourglass" model: IP is the narrow waist, above which is any number of applications (HTTP, DNS, video, protocols not yet invented), and below which — any physics (Ethernet, Wi-Fi, optics, satellites, even — according to the April Fools' RFC 1149 — carrier pigeons). The narrowness of the waist is the source both of the Internet's strength and of its conservatism: changing IP is harder than changing anything else in the history of technology.

Two models of the network: datagrams versus virtual circuits

Before dissecting IP, one must understand the fundamental architectural choice that is not for nothing placed at the very beginning of any conversation about the network layer: a network can operate according to one of two models, and almost all of its properties depend on this choice.

The datagram network

In the datagram model, each packet is sent independently and carries the full destination address. No connection is established: routers keep no state about flows and make the decision for each packet anew. Packets of one flow may travel by different routes, arrive in a different order, be duplicated, or be lost — the network neither notices nor corrects this.

Such a model is simple: a router needs only a "destination prefix → next hop" table, not a table of millions of connections. It is resilient: when a link fails, traffic is simply redistributed, and nobody's "state" is lost. And it is ideally suited for burst data traffic, which is by nature poorly predictable. It is precisely this model that IP chose.

Virtual circuits: X.25, Frame Relay, ATM

In the virtual circuit model, a connection is established before data transmission: the network lays out a path and records in each transit node the state — "incoming channel identifier X is translated into outgoing Y on port Z." All packets of the connection travel by one route, in the order sent, and the network can guarantee them bandwidth and delay.

That is how X.25 was built (the CCITT standard of 1976) — the protocol of the telephone administrations of the whole world, with a heavy data link layer and per-tick tariffication. That is how Frame Relay worked in the 1990s. That is how ATM was designed — the ambitious technology of the 1980s–1990s that promised to unite voice, video, and data in one network of fixed-size cells (53 bytes), and to which the telecommunications industry assigned the role of the foundation of 21st-century communication.

Why the Internet chose datagrams

The dispute between datagrams and virtual circuits was not only technical, but also cultural and economic. The telephone companies thought in terms of connections: a connection is an understandable unit of tariffication, guaranteed quality, and management. The pioneers of the Internet thought in terms of packets: state in the network was considered an evil, because it does not survive failures and does not scale.

Practice settled the dispute. First, state in every node for every connection meant that the network knows about connections what it should not know — and it breaks when a node reboots. Second, virtual circuits tolerate emergency rerouting poorly: when a path is severed, the connection has to be rebuilt entirely, whereas datagrams simply start traveling by another route. Third, economics: Cisco routers on ordinary hardware turned out to be cheaper than ATM switches, and Ethernet cheaper than ATM interfaces. Fourth, the end-to-end argument: if reliability is needed on the hosts anyway, duplicating it in the network is pointless.

By the mid-1990s it was clear that IP+Ethernet had won, although the remnants of ATM lived on in provider backbones into the 2000s. The price of victory turned out to be real: the datagram model does not guarantee quality of service or delivery order, so these tasks had to be solved "on top of and alongside" — TCP, queues, DiffServ, traffic engineering. And, ironically, virtual circuits returned to the Internet under new names — MPLS and segment routing.

Comparison of the models

Let us summarize the comparison of the two models. The datagram model does not require connection establishment, survives the failure of a router (packets find another path), and stores no state, but it does not guarantee order and is hard to provide with quality of service. A virtual-circuit network establishes a connection, guarantees order, and reserves resources — but the failure of a node tears all connections passing through it, and routers store a table entry for each connection. The Internet chose datagrams — probably the most important architectural decision in the history of communications: all the other properties of the network layer, from the "best effort" of IP to the policies of BGP, follow from it.

The functions of the network layer

The network layer solves one main task: delivering a packet from source to recipient through a multitude of intermediate networks. The data link layer delivers frames within one network; the network layer stitches such networks together into an internet (internet in the general sense, Internet as a proper name). Five functions follow from this task.

Addressing

Every device interface is assigned a global identifier — an IP address. Unlike the MAC address, which is "baked into" the network card and has meaning only within its own broadcast zone, the IP address is hierarchical: the high-order bits denote the network, the low-order bits — the host. It is precisely the hierarchical nature that allows routes to be aggregated and the system to scale; a flat address space (like that of MAC) would not have worked for a million networks.

Routing

Routing is the computation of paths: how a packet gets from source to recipient. This is the "brain" of the network layer: routing protocols exchange information and build routing tables (RIB — Routing Information Base).

Forwarding

Forwarding is the use of the tables: a packet has arrived at an input interface, and in fractions of a microsecond it must be decided which output interface to send it out of. This is no longer logic, but an operation at speed: a lookup in the table (FIB — Forwarding Information Base), performed in hardware billions of times per second. The separation of routing and forwarding is one of the key ideas of the layer: the slow "brain" builds the tables, the fast "reflexes" work according to them.

Congestion control

If incoming traffic steadily exceeds outgoing throughput, queues grow, delays increase, packets are lost. One thought is important here: congestion is not an error, but a normal, expected state of a packet network. The network layer can prevent congestion (limiting and smoothing traffic) and react to it (signaling senders, dropping or marking packets). The mechanisms — from the "leaky bucket" to ECN and modern AQM — are dissected below.

Fragmentation

Different networks have different maximum packet sizes (MTU). If a packet does not fit into the MTU of the next network, it is divided into fragments and reassembled at the end node. In IPv4, intermediate routers know how to fragment; in IPv6 this is forbidden — only the source fragments. Both schemes generate their own problems, up to full-fledged attacks.

To these five functions, two more are added in practice: internetworking as a principle — "inside the network there can be anything, from the outside everyone sees IP" — and quality of service (QoS), the attempt to make a network built on the "best effort" principle behave predictably for delay-sensitive traffic.

IP: the protocol on which everything rests

The IPv4 header

Let us dissect the IPv4 header (RFC 791) — field by field, in the order in which they lie on the wire.

Version (4 bits) — the protocol version (4 or 6; the field seems redundant until you remember that the two versions have coexisted for thirty years already). IHL (4 bits) — the header length in 32-bit words: minimum 5 (20 bytes), maximum 15 (60) — room reserved for options.

DSCP and ECN (8 bits together; in RFC 791 the field was called Type of Service) — quality of service: the 6 bits of the DSCP code set the class of the packet, and the 2 bits of ECN allow the network to signal congestion without dropping the packet. The history of this field is the history of two failures and one slow success.

Total Length (16 bits) — the full length of the packet with the header, maximum 65,535 bytes: because of this limit, 9000-byte "jumbo frames" fit into IP easily, while objects larger than that have to be fragmented.

Identification, Flags, Fragment Offset — the trio of fragmentation fields: Identification is the same for all fragments of one packet, Flags contain the DF bit ("do not fragment") and MF ("more fragments follow"), Fragment Offset is the offset of the fragment in units of 8 bytes.

TTL (8 bits) — time to live. Formally in seconds, in fact since the early 1990s — in hops: every router decreases it by one; at zero the packet is destroyed, and an ICMP Time Exceeded goes to the sender. This is the fuse against routing loops.

Protocol (8 bits) — which next-level protocol to hand the payload to: 1 — ICMP, 6 — TCP, 17 — UDP, 47 — GRE, 50 — ESP (IPsec). This is the "demultiplexing" of the network layer: the thread linking L3 to the transport.

Header Checksum (16 bits) — a checksum of the header only; it is recomputed at every hop, because the TTL has changed. IP does not check the integrity of the payload — TCP/UDP are responsible for that with their own checksums.

Source / Destination Address (32 bits each) — the sender and the recipient; they do not change along the entire path of the packet — unlike the MAC addresses, which are rewritten at every hop.

Options — record route, timestamp, source routing. The latter allowed the sender to dictate the path of the packet — and was abandoned: it breaks independent routing and was used in attacks, so providers filter it.

Best effort: what IP does not guarantee

The operating principle of IP is called best effort delivery. IP does not guarantee delivery, order, absence of duplicates, payload integrity, or protection against forgery of the source address. All the network does is honestly try to deliver each packet individually and, if it cannot, usually report this via ICMP (and often does not report it).

To the question "why is IP unreliable?" the correct answer is this: because reliability was deliberately moved out into TCP — so that the network itself would remain simple and scalable. This is a direct consequence of the end-to-end argument: retransmissions, ordering, and congestion control make sense only between the end hosts. UDP (protocol 17) demonstrates the reverse side of the choice: to an application that does not need TCP's reliability (voice, video, DNS, games), IP gives exactly what it has — "bare" datagram delivery.

IPv4 addressing: classes, subnets, CIDR

The first IPv4 addressing scheme was classful: the first octet determined the class — A (1–126, network plus 24 bits of hosts), B (128–191, plus 16 bits), C (192–223, plus 8 bits). The scheme seemed elegant and failed spectacularly: organizations received entire class B networks of 65 thousand addresses even if they needed three hundred. By the early 1990s the Internet faced "two crises": the exhaustion of class B address space and the explosive growth of the routing table.

The first answer was subnetting (RFC 950, 1985): an organization divided its network into parts using a mask invisible to the outside world. The second — and decisive — was CIDR (Classless Inter-Domain Routing, RFC 1518/1519, September 1993): classes were abolished altogether, and the network prefix became of arbitrary length — 192.168.1.0/24 means "the first 24 bits are fixed, the remaining 8 bits are hosts." CIDR made it possible to allocate blocks "to size" and, more importantly, to aggregate routes: one line 10.0.0.0/8 in the table instead of 256 lines 10.x.0.0/16.

Today routers work not with addresses, but with prefixes. Route lookup is a longest prefix match search: if the table contains both 10.0.0.0/8 and 10.1.0.0/16, a packet to 10.1.2.3 will go by the second route, because it is more specific. From this property grew a whole class of BGP attacks: announcing a more specific prefix hijacks the victim's traffic.

Private addresses and special ranges

Part of the IPv4 space is reserved for special needs: RFC 1918 (February 1996) set aside three ranges for private networks — 10.0.0.0/8 (16.7 million addresses), 172.16.0.0/12 (1 million), 192.168.0.0/16 (65 thousand; the 192.168.1.x familiar to everyone comes from there). Additionally there exist 127.0.0.0/8 — the loopback address, 169.254.0.0/16 — link-local for the case when there is no DHCP server (RFC 3927), 100.64.0.0/10 — the space for carrier NAT (RFC 6598), 224.0.0.0/4 — multicast, and 240.0.0.0/4 — a reserved stock that was never needed.

The exhaustion of IPv4: chronology and the address market

That 32-bit addresses (4.3 billion) would not be enough had been said since the late 1980s. The chronology of the end stretched over a decade: on February 3, 2011, IANA distributed the last five /8 blocks among the regional registrars; then addresses ran out at APNIC (April 2011), RIPE NCC (September 2012), LACNIC (June 2014), ARIN (September 2015), and on November 25, 2019, RIPE NCC announced the complete exhaustion of the IPv4 pool and opened a "waiting list."

In parallel, in April 2011, Microsoft bought 666,622 IPv4 addresses at Nortel's bankruptcy auction for 7.5 million dollars — roughly 11 dollars per address. Thus the IPv4 market was born: addresses became a commodity. Prices grew to a peak of about 50 dollars per address by 2024, then corrected, and by 2026 the range is from 11 to 32 dollars depending on the size of the block. The economic meaning is clear: it is cheaper to buy addresses than to migrate to IPv6 — and it is precisely this arithmetic, not technology, that determines the pace of migration.

IPv6: the history of creation and the architecture

Work on the successor of IPv4 began in the 1990s under the name IPng (IP: Next Generation). Three proposals competed: SIPP by Steve Deering, TUBA (TCP over the OSI protocol CLNP), and PIP by Paul Francis. In January 1995, RFC 1752 fixed the recommendation: to develop SIPP with 128-bit addresses. The specification came out as RFC 1883 (December 1995), then RFC 2460 (1998), and the current edition is RFC 8200 (July 2017). The number "5" was skipped not by accident: it was taken by the experimental stream protocol ST-II (RFC 1190, 1990), from which many ideas of RSVP and multicast grew.

What changed in IPv6:

• The address is 128 bits: 3.4·10³⁸ values. The address space stopped being the limiting resource — the routing table became it.
• A fixed 40-byte header. The checksum was removed (it is duplicated by the data link and transport levels), options were moved out into a chain of extension headers, processed only where needed. The fields go in the order: Version, Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit, then the 128-bit source and destination addresses — the header became simpler for hardware processing.
• No fragmentation in transit: routers do not cut a packet that is too big, but return an ICMPv6 Packet Too Big to the source; only the sender fragments.
• The Flow Label field (20 bits) — an attempt to bring back into the datagram network the notion of a "flow": packets of one flow can be processed identically (for example, not bounced by ECMP across different paths).
• TTL was renamed to Hop Limit, Type of Service — to Traffic Class, Protocol — to Next Header. There is no broadcast — it was replaced by multicast: even ARP-like functions are implemented through special multicast groups.

Addresses are written in hexadecimal form separated by colons; leading zeros are omitted, a sequence of zero groups is replaced with :: — for example, 2001:db8::1. It is worth mentioning SLAAC autoconfiguration (RFC 4862): a host can obtain an address without DHCP by listening to router advertisements — but the early scheme of forming the address from the MAC (EUI-64) allowed tracking the user across networks, and it had to be closed with "privacy extensions" (RFC 4941) — temporary random addresses.

Why IPv6 took thirty years to deploy

The global launch of IPv6 took place on June 6, 2012 (World IPv6 Launch; a year earlier there was the trial World IPv6 Day) — Google, Facebook, Yahoo, Akamai, and others turned on IPv6 "on a permanent basis." Fourteen years have passed since then: according to Google's statistics, the share of users coming to its services over IPv6 in 2026 is approximately 45–50%. The spread across countries is enormous: India and France have passed 60–70%, the USA is around half, and many corporate networks remain practically purely IPv4.

The reasons are not technological: IPv6 is better than IPv4 by almost every engineering parameter. The problem is in economics. NAT removed the urgency of migration; dual stack requires operating two networks simultaneously for years; the operator sees no direct benefit "here and now." The result is a collective stalemate: everyone acknowledges the necessity of IPv6, but nobody wants to pay for an urgent transition. Among the servers of the million largest domains, the majority already support IPv6, but "switching off IPv4" is still far away. The network layer lives in a state of permanent upgrade — exactly what the "hourglass" architecture turned out to be ready for.

Transition mechanisms: dual stack, tunnels, translation

Over thirty years the industry produced three families of mechanisms for the coexistence of versions. Dual stack — a node supports IPv4 and IPv6 simultaneously; the choice of version when connecting is made by Happy Eyeballs (RFC 8305): the client tries both addresses in parallel and stays on the one that worked faster. Tunneling — IPv6 packets are packed into IPv4 (6in4, 6to4, Teredo); historically this allowed the islands of IPv6 to communicate across the ocean of IPv4. Translation — NAT64/DNS64 (RFC 6144–6147): the DNS resolver synthesizes an IPv6 address from an IPv4 one, and a gateway translates the packets. The largest example is T-Mobile US, operating as IPv6-only with the 464XLAT mechanism (RFC 6877).

ARP: how IP finds a specific device

Address resolution

Between the network and data link levels there is a gap: IP knows the recipient's address (192.168.1.10), but the Ethernet frame needs a MAC address. The ARP protocol (Address Resolution Protocol, RFC 826, November 1982, David Plummer) closes this gap with one question: "Whose IP is this? Tell me your MAC."

It works like this. The host sends a broadcast frame to the MAC address FF:FF:FF:FF:FF:FF — all devices of the segment hear it; the frame contains the question "Who has 192.168.1.10?" The device with that IP responds by unicast: "That's me, my MAC is AA:BB:CC:DD:EE:FF." The response is cached in the ARP table (usually for a few minutes), and subsequent packets to the same addressee go out without polling. There are also variations: gratuitous ARP (a node itself announces "this IP is now mine" — used in cluster failover and, unfortunately, in attacks), proxy ARP (a router answers for other people's IPs), RARP (the reverse protocol for diskless workstations, the ancestor of BOOTP and DHCP).

The key limitation: ARP works only within a single broadcast zone. Routers do not pass broadcast traffic through — otherwise one ARP request would wake up the entire Internet.

When the target is in another network: the default gateway

If you need to send a packet to 8.8.8.8, ARP will not help: Google DNS is not in my segment. The host compares the destination address with the mask of its subnet, realizes that the address is "foreign," and sends the packet to the default gateway — usually the home router: it makes an ARP request for the gateway's IP and wraps the packet in a frame addressed to its MAC.

From this follows the fundamental rule that distinguishes an understanding engineer from one who has memorized definitions: the destination IP address does not change along the entire path, while the destination MAC address is rewritten at every hop. The packet "for 8.8.8.8" on each segment is wrapped in a frame to the nearest neighbor: from the laptop — to the router, from the router — to the provider's router, and so on, until on the last segment the frame is addressed to the MAC of the server itself. IP is the end-to-end address of "where to," MAC is the local address of "to whom to hand it over right now."

Security problems of ARP and NDP in IPv6

ARP is defenseless by design: it does not authenticate responses, and many stacks accept "unsolicited" cache updates. Hence ARP spoofing: an attacker in a shared segment broadcasts responses "the gateway's IP is my MAC" and becomes a "man in the middle" for all the neighbors. There are protections — static entries, Dynamic ARP Inspection on managed switches, IP-MAC-port binding — but they require managed infrastructure, which an arbitrary network does not have.

In IPv6, the place of ARP was taken by the NDP protocol (Neighbor Discovery, RFC 4861), operating on top of ICMPv6 and multicast: the same tasks (address resolution, finding routers, determining neighbor reachability) and the same diseases. The attempt to close them cryptographically (SEND, RFC 3971) did not take root — instead of authentication, administrators rely on filtering and isolation of segments.

Inside the router

"A router forwards packets" — everyone knows this phrase, but what happens inside when a packet enters the port of a backbone device is rarely dissected. And yet it is precisely the internal architecture of the router that explains why the network layer is built this way and not another.

Packet processing step by step

A packet that has arrived at a router passes through a pipeline. The input port receives the physical-level signal, assembles the data-link-level frame (for example, Ethernet), checks its checksum (FCS), and strips the header — the IP packet is "pulled out" of the frame. The IP header is checked: version, length, checksum. The router decrements the TTL; at zero the packet is destroyed, and an ICMP Time Exceeded goes to the sender — this is how the network protects itself from loops. The checksum is recomputed — it covers the TTL.

Next comes the main step: the route lookup by destination address. The router searches the forwarding table for the longest matching prefix entry (longest prefix match) and obtains the "next hop" — the neighbor to which the packet must be handed over — and the output interface. The packet is queued at the output port, and when its turn comes — it is wrapped in a new frame with new MAC addresses and a new FCS and goes out into the wire.

The separation into routing and forwarding is physically visible here: routing protocols (OSPF, BGP) slowly fill the routing table (RIB); from it the best paths are loaded into the forwarding table (FIB), and it is the FIB that is used for every packet. Routing is the "brain," forwarding is the "reflexes." The first packet of a flow may take the slow path through the central processor (slow path), but the millions that follow are processed in hardware at line speed (fast path).

Routing tables

An example of a simple routing table:

Network          Next hop
192.168.1.0/24   connected locally (port eth0)
10.0.0.0/8       192.168.1.1
0.0.0.0/0        provider's gateway (default route)

The default route (0.0.0.0/0) is a special case of aggregation: "everything that did not match anything more specific, send there." A home router stores a handful of lines; a provider's backbone router — the full BGP table, which in 2026 exceeded a million prefixes. Hence the practical consequence: the growth of the table is not abstract statistics, but a demand for expensive hardware.

The architecture: input ports, switching fabric, output ports

Structurally, a router consists of input ports (reception, parsing, route lookup), a switching fabric (the internal "bus" carrying packets from input to output), and output ports (buffering, scheduling, transmission). Historically, three generations of fabrics have been replaced: memory (the first routers — essentially computers — copied the packet under processor control), a bus (simple, but all traffic shares its bandwidth), and a crossbar — a network of parallel paths allowing several packets to be transferred simultaneously to different outputs; it and its derivatives are used in modern devices.

The crossbar is associated with the classic problem of head-of-line blocking: a packet whose output port is busy blocks the entire queue of its input port, even if other outputs are free. The solutions are virtual output queues (VOQ, a separate queue for each output port) and speeding up the fabric (speedup) relative to line rate. At the output ports, packets are buffered — and the size of these buffers, as we will see below, determines delays across the entire Internet.

TCAM, ASIC, and hardware acceleration

Backbone routers must make the forwarding decision in hundreds of nanoseconds — on a 100 Gbit/s interface with minimal packets, no processor can cope with such a pace. Therefore the longest prefix match search is performed in specialized TCAM memory (ternary content-addressable memory): it compares the address with all entries in parallel in one clock cycle. TCAM is expensive, power-hungry, and limited in volume, so the full table of the DFZ (default-free zone) must fit within the FIB limits — and every extra prefix announced by someone in the world literally costs memory on all the backbone routers of the planet.

Besides TCAM, modern forwarding is built on network ASICs and programmable pipelines: the P4 language (2015–2016, Barefoot Tofino chips) allows specifying exactly how a packet is processed in hardware — not only IP routing, but arbitrary headers and logic. The boundary between "hard" forwarding and "soft" control is blurring — this prepares the ground for SDN. The revolution in hardware forwarding, however, was made in 1998 by the Juniper M40, where the lookup and forwarding were done by hardware, not by a Unix-like processor as in the Cisco devices of the time; the speed grew by orders of magnitude, and the market for backbone devices changed forever.

Routing algorithms

Routing answers the question "which path is best?" — and the answer is more complicated than it seems, because "best" is determined by a metric (hop count, delay, cost, policy), and the network itself is distributed: nobody sees it in its entirety. Practical algorithms divide into two families — distance vector and link state — plus a separate class, "path vector," for BGP.

The shortest path: Dijkstra's algorithm

The basic abstraction is a graph: nodes are routers, edges are links with a weight. The task is to find the minimum-cost path from the source to all nodes; it is solved by Dijkstra's algorithm (1959). The cost can be anything: a unit per hop, a value inversely proportional to bandwidth (this is what OSPF does), delay, or the monetary price of transit. Dijkstra is the computational core of link-state protocols; how the nodes learn the graph is the concern of the protocols.

Distance vector: RIP and "counting to infinity"

In the distance vector family, each router keeps a table "network → distance to it" and periodically reports its table (or part of it) to its neighbors. The neighbor adds the cost of the link and chooses the minimum — this is how knowledge spreads through the system. The mathematical foundation is the Bellman-Ford equation: a distributed algorithm in which each node computes its own optimum from the optima of its neighbors.

The classic implementation is RIP (RFC 1058, 1988): the metric is the hop count, maximum 15, broadcasting of the full table every 30 seconds. RIP is primitively simple and is still encountered in small networks; RIPng (RFC 2080) ported it to IPv6; RIPv2 (RFC 2453) added CIDR support and authentication.

The main problem of the family is "count to infinity." If a network falls off, the information spreads slowly and peculiarly: node A learns about the loss, but neighbor B believes the path through A is alive and reports to A "my distance to network X is 5 hops"; A accepts the route, not realizing that it leads back through B into nowhere. The metric grows until it hits "infinity" (16 in RIP): in practice this means minutes of a black hole and routing loops. Partial medicines: split horizon ("do not tell a neighbor what you learned from it"), poison reverse (tell it, but with an infinite metric), hold-down timers, limiting the metric. Only the transition to link state fully solves the problem.

The early ARPANET used distance vectors from 1969 and in practice encountered all their diseases — up to the point that during periods of load, routing updates queued up behind user packets. In 1979 the network switched to an algorithm based on link state — the dispute between the two families was settled not by theory, but by accidents.

Link state: OSPF and IS-IS

In link-state protocols, every router knows the entire map of the network. The work is built in five steps: discover neighbors (hello packets), measure the cost of links, collect a description of one's own connections (LSA) and distribute it to everyone by reliable flooding, in which each node retransmits what it received once, build from all the LSAs a topology map identical at every node, and run Dijkstra's algorithm on it.

OSPF (Open Shortest Path First; OSPFv2 — RFC 2328, 1998, John Moy) is the most widespread interior protocol of the Internet. It is free and open (as opposed to Cisco's proprietary EIGRP, published as RFC 7868 only in 2016), supports authentication, equal-cost paths (ECMP), and — critically for large networks — areas: routers know everything about their own area and only aggregated information about the rest of the world, while backbone area 0 links the others. OSPFv3 (RFC 5340) is adapted for IPv6.

IS-IS is a descendant of the OSI protocol (ISO 10589, adaptation RFC 1142) that outlived its stack: it turned out to be better designed for scaling, and it is exactly what many large providers chose for interior routing. The comparison of the families is fundamental: link state knows the network completely (more expensive in memory and CPU, faster in convergence, more resistant to loops); distance vector knows only directions and distances (cheaper, slower, more vulnerable).

Hierarchical routing and aggregation

If every router stored a route to every network in the world, a table of over a million prefixes would stand in every home router, and updates would swamp the network. The salvation is hierarchy: the Internet is divided into autonomous systems; inside them — into OSPF areas or IS-IS zones; inside zones — into local networks. A router stores detailed routes about its own zone and aggregated ones about the outside world: one line instead of millions.

Aggregation (summarization) is CIDR in action. According to the CIDR Report for October 2026, of the 1,085,491 prefixes of the full table, 608,802 aggregate perfectly — that is, 44% of the entries exist only because their owners need multihoming (connection to several providers), traffic engineering, or protection against hijacking by more specific announcements. Hierarchical routing scales exactly to the extent that participants are willing to sacrifice specificity for compactness — and this is a constant tension between the optimization of each one and the capacity of the system of all.

Stability, convergence, and loops

After any change of network topology, time is needed for convergence — the period while all routers come to a consistent state; during this time transient loops and temporary black holes are possible. Distance vectors have slow convergence (minutes); link state — fast (seconds), but expensive in resources. An unstable link causes route flapping — continuous announcements and withdrawals of a route; against this, damping is applied (RFC 2439), temporarily suppressing "nervous" routes. A separate task is the speed of reaction to failure: telephony and financial transactions require restoration in tens of milliseconds, so around the basic protocols a layer of fast recovery mechanisms has grown — BFD (RFC 5880), detecting the death of a link in milliseconds, IP Fast Reroute, and LFA (Loop-Free Alternates). The last line of defense against loops remains the TTL: whatever errors the tables contain, the packet will die after 255 hops. The philosophy of the layer in its pure form — not perfect correctness, but bounded damage.

Interdomain routing: BGP and the economics of the Internet

All the protocols above work inside a single network — where there is one administration, one policy, and one goal. The Internet, however, consists of tens of thousands of independent networks, and the protocol that stitches them together differs fundamentally from OSPF or RIP: it chooses routes not by distance, but by contracts.

Autonomous systems

An autonomous system (AS, RFC 1930) is a network under a single administrative control with a single routing policy: a provider, a cloud, a university, a data center operator. Every AS is issued a number (ASN): historically 16-bit, since the mid-2000s — 32-bit, because the numbers started running out too. As of October 2026, about 79,744 autonomous systems are visible in the global table; of them, over 28 thousand announce exactly one prefix; the largest by number of prefixes is Amazon (AS16509, about 17.5 thousand). The Internet is not one network, but a confederation of thousands of sovereigns, and BGP is their diplomatic protocol.

BGP: a protocol of policies, not metrics

BGP (Border Gateway Protocol) operates on top of TCP: routers exchange information about the reachability of prefixes through sessions on port 179. The history of the protocol: RFC 1105 (1989), BGP-2 and BGP-3 (1991), and finally BGP-4 (RFC 1654, 1994; the current specification RFC 4271, 2006) — it was BGP-4 that added support for classless addressing; without CIDR the routing table would have suffocated back in the nineties. External BGP (eBGP) connects different ASes; internal (iBGP) carries external routes inside one's own. Every announcement carries attributes: AS_PATH — the list of autonomous systems traversed (it is also the protection against loops: seeing its own number, the router rejects the announcement), NEXT_HOP, LOCAL_PREF (the larger the better), MED — a hint to the neighbor, and communities — labels for flexible policy. Route selection goes in a strict order: local preferences, AS_PATH length, origin, MED.

The main thing to understand about BGP: it does not search for the shortest path in the physical sense. AS_PATH is measured in the number of autonomous systems, not kilometers: a "shorter" path may be more expensive and less advantageous. A provider may prefer a long route because it passes through customers (who are not paid for traffic — quite the opposite) rather than through transit suppliers. The model, formalized by Lixin Gao and Jennifer Rexford, is called valley-free routing: announcements propagate upward (to providers) and sideways (to peers) only for customer and own traffic, but not for the transit of someone else's traffic between two providers. Violation of this unwritten constitution of the Internet is what a route leak is called.

Peering, transit, and exchange points

The economics of connectivity reduces to two contracts. Transit: provider A pays provider B for delivering traffic anywhere. Peering: two networks exchange the traffic of their customers for free (settlement-free) or by agreement — this saves money and reduces delays. Physically, peering happens at Internet exchange points (IXP): DE-CIX in Frankfurt, AMS-IX in Amsterdam, LINX in London, MSK-IX in Moscow — large IXPs switch hundreds of networks and tens of terabits per second. At the top of the hierarchy are some fifteen global tier-1 networks, which pay nobody for transit because they peer with each other without settlements; below them — tier-2 and thousands of access networks. The topology of the system obeys a power law (Gao and Rexford, 2000): a few nodes with gigantic connectivity, a huge number — with minimal connectivity.

The conclusion worth stating explicitly: the Internet is routed not by geography, but by economics. Traffic between two providers in one country may go via Frankfurt, and communication within Africa went through Europe for decades — because direct contracts were absent, and transit through the former metropolises was cheaper.

Why a globally optimal route does not exist

Inside a single AS, optimization is possible: one administration, one objective function, OSPF computes the minimum cost. Between ASes there is no common objective function: each system has its own benefit and its own contracts. A decentralized game of tens of thousands of selfish participants is not obliged to converge to a global optimum — and it does not. The "best route" at the scale of the Internet is not a mathematical concept but a negotiable one; any attempt to "improve the Internet centrally" runs precisely into this.

A chronicle of incidents: from AS7007 to the present day

The history of BGP incidents is the best textbook on the structure of interdomain routing.

• April 25, 1997, AS7007. A router of the provider MAI Network Services began announcing other people's routes as its own, with a truncated AS_PATH. Half the world switched its traffic into a black hole — the first mass proof that BGP believes any announcement.
• February 24, 2008, YouTube and Pakistan Telecom. The provider was ordered to block YouTube inside the country; it announced a more specific /24 prefix from YouTube's address space — and the transit partner PCCW broadcast the announcement all over the world. YouTube went down globally for almost two hours. A textbook example of how an internal censorship measure becomes a global accident.
• April 8, 2010, China Telecom. For about 18 minutes, roughly 15% of the routes of the entire Internet were announced through the Chinese network, including the addresses of American government agencies; the details are disputed, but the fact of the mass redirection is confirmed.
• August 28, 2017, Google and Japan. The provider NTT Communications, due to a configuration error, translated more specific routes to Google's prefixes; a significant part of Japanese traffic traveled for an hour through Google's network as through a transit one.
• April 24–25, 2018, MyEtherWallet. Attackers hijacked the prefixes of Amazon Route 53 and redirected the DNS requests of users of the cryptocurrency wallet to a phishing server. About 150 thousand dollars in ether were stolen — the first loud case in which a BGP hijack was directly converted into the attackers' money.
• June 24, 2019, Cloudflare and the Verizon "optimizer." The automatic route optimizer Noction in the small French network DQE generated incorrect more specific announcements, including Cloudflare's prefixes; Alliance Networks passed them upward to Verizon, and that one spread them around the world. Users lost access to sites behind Cloudflare for more than an hour; Verizon did not respond to emergency appeals for hours, and it had no limits on the number of prefixes accepted.
• October 4, 2021, Facebook. An unsuccessful maintenance command withdrew all of Facebook's BGP announcements (about 126 prefixes). The company disappeared from the global table — together with WhatsApp, Instagram, and everything tied to its DNS. Recovery took about six hours — partly because Facebook's internal tools depended on the same network; the losses were estimated in tens of millions of dollars. The largest BGP incident in history was arranged by the victim itself: the cause was a configuration error, not an attack.
• July 8, 2022, Rogers. The largest Canadian operator lost its network for about 15 hours due to a maintenance failure that withdrew routes and broke DNS; Interac payments and part of the emergency services calls did not work.
• June 27, 2024, Cloudflare 1.1.1.1. The public DNS resolver degraded for several hours due to a combination of a hijack and a leak: the erring network announced the 1.1.1.1 prefixes without valid RPKI signatures, but networks without origin validation accepted the announcements.
• January 22, 2026, a leak by Cloudflare itself. A policy automation error on a router in Miami caused Cloudflare to announce other people's IPv6 prefixes to its providers and peers — a type 3 and 4 leak according to RFC 7908, lasting 25 minutes. The irony is that the culprit was the company that had spent years describing other people's leaks — and it was caused by an innocuous-looking change: a prefix list was removed from the policies, and the empty list matched "all routes."

The general conclusion from the chronicle: almost all major incidents are not malicious intent, but configuration errors multiplied by BGP's complete trust in announcements, and they spread through third hands, because the interdomain system has no center capable of stopping the avalanche.

Protecting routing: RPKI, BGPsec, and MANRS

The answer to hijacks became RPKI (Resource Public Key Infrastructure, RFC 6480, 2012): the owner of the address space publishes a signed ROA object (Route Origin Authorization) — "prefix X may be announced by AS Y." Routers with origin validation (ROV) enabled discard announcements that contradict the ROA. According to APNIC data, in March 2026 about 60% of observed IPv4 routes were RPKI-valid, 38% had no records, and 2% were invalid. There is progress, but the uncovered 40% means that a hijack is still possible — and the incident of June 2024 with 1.1.1.1 showed: signing your own prefixes is not enough; the others must turn on validation too.

BGPsec (RFC 8205, 2017) signs the entire AS_PATH, protecting against path forgery, but ran into cost: signatures bloat the announcements, and there is no mass deployment. More practical are the "lightweight" mechanisms: the ASPA profile (standardized at the end of 2024), which checks announcements against data on customer-provider relationships, and the OTC attribute (Only-to-Customer, RFC 9234, 2022), which helps catch leaks. The MANRS initiative (since 2014, under the aegis of the Internet Society) reduces hygiene to four rules: filtering other people's prefixes, protection against spoofing, coordination with neighbors, global validation. Compliance is voluntary — and that is the whole Internet in a nutshell: the security of the layer is built not by coercion, but by the accumulation of collective discipline.

ICMP: the service protocol of the Internet

IP silently discards the packets it cannot deliver — if not for ICMP (Internet Control Message Protocol, RFC 792, September 1981), the network would be not only unreliable, but also mute. ICMP is the feedback of the network layer: messages about errors and the simplest diagnostics. Formally it is not an independent protocol, but part of IP: ICMP messages travel in ordinary IP packets with protocol number 1 (58 in IPv6), and every node is obliged to process them.

Message types

The main ICMPv4 messages: Destination Unreachable (type 3) with the codes "network/host/port unreachable" and the especially important "fragmentation required with DF set" — it is precisely this one that feeds path MTU discovery; Time Exceeded (type 11) — the TTL hit zero; Redirect (type 5) — the router hints to the host to go to the network directly through a neighbor; Echo Request / Echo Reply (types 8 and 0) — the basis of ping; Parameter Problem (type 12) — a broken header. Historically there also existed Source Quench (type 4) — a primitive congestion signal; it proved harmful and was buried by RFC 6633 in 2012.

In IPv6 the role of ICMP has grown radically: ICMPv6 (RFC 4443) carries not only errors, including Packet Too Big (the analog of "fragmentation needed"), but also the entire neighbor discovery protocol NDP — router advertisements, address solicitations, reachability determination. To filter ICMPv6 in an IPv6 network is to break its basic functions, not to "increase security," as it sometimes turned out with ICMPv4.

ping and traceroute: the two tools that made the network observable

ping was written by Mike Muuss in December 1983 at the Ballistic Research Laboratory; the name comes from the sound of a sonar: an echo request went out, an echo reply came back. More than forty years later it is still the first command that any network engineer types when "nothing works."

traceroute appeared in 1987: Van Jacobson of LBL implemented an idea suggested by Steve Deering — and it turned out to be genius in its audacity. The utility sends a series of probes with successively increasing TTL: a probe with TTL=1 is killed by the first router, which sends back an ICMP Time Exceeded — this is how we learn the first hop. TTL=2 — the second, and so on, until the probe reaches the target. Each "dead" packet reveals the name and address of its executioner: the path through the Internet is reconstructed from the corpses. Implementations differ in their probes (UDP to high ports in Unix, ICMP Echo in Windows tracert, TCP SYN in modern utilities), while paris-traceroute and dublin-traceroute fight the fact that ECMP bounces the probes of one "flow" across different paths.

ICMP in the modern network: filtering and "black holes"

The attitude to ICMP has come full circle. In the 1990s ICMP messages were considered diagnostics; then — a vector of attacks (the smurf attacks of the late 1990s avalanche-amplified echo requests through broadcast addresses), and administrators began filtering ICMP "just in case." The side effect turned out to be worse than the disease: by blocking ICMP, the network loses PMTUD, breaks traceroute, and deprives senders of information about errors — connections do not break honestly, they "hang." Modern practice is selective passing: allow Echo and, critically important, Fragmentation Needed / Packet Too Big, limit their rate, ignore Redirect on transit interfaces.

Congestion, queues, and quality of service

Congestion is the state in which the demand for bandwidth exceeds the supply; its symptoms are growing delays, overflowing queues, and packet losses. The causes are not only "too much traffic": limited buffering, imbalance of link speeds, bursts (burst traffic), and feedback loops between transport protocols and the network. The key thesis: congestion is a normal state of a packet network, not a malfunction; a network designed without a margin for congestion is doomed.

The 1986 collapse and the work of Van Jacobson

In October 1986, the Internet first learned what congestion collapse is: on the ARPANET section between Berkeley and LBL, throughput dropped a thousandfold — from 32 Kbit/s to 40 bit/s. Almost all the resources of the network were being spent on retransmitting packets that nobody managed to accept. Van Jacobson's research showed the mechanics: TCP senders synchronously increased their rate, synchronously clogged the queues, synchronously lost packets, and synchronously restarted — self-oscillations rocking the network.

Jacobson's report "Congestion Avoidance and Control" at SIGCOMM 1988 became one of the most cited in the history of networking technologies: exponential smoothing of retransmission timers, slow start, congestion avoidance with additive increase and multiplicative decrease of the window (AIMD). The performance of the section grew several times over — not from new hardware, but from the right algorithm. Problems had been addressed before too: in January 1984, John Nagle published RFC 896, describing the collapse in the Ford Aerospace network and proposing an algorithm to fight the avalanche of small packets — "Nagle's algorithm," which to this day is disabled with the TCP_NODELAY flag for the sake of interactive applications.

Open-loop and closed-loop: the leaky bucket and the token bucket

The methods of fighting congestion divide into prevention (open-loop — we solve the problem without looking at the current state: admission control, traffic smoothing, correct design) and reaction (closed-loop — the network detects congestion and signals: ICMP in the past, ECN today, packet losses as a crude but working signal — always).

Two classic smoothing mechanisms are the "leaky bucket" and the "token bucket." The leaky bucket, proposed by Jonathan Turner in 1986, works like a queue with a constant service rate: however much pours in, it flows out evenly. The token bucket is arranged the opposite way: tokens arrive in a tank at rate R; a token is needed to send a packet; if the tank of capacity B is full, the sender can splash out the accumulated amount at once. The average rate is limited by R, but bursts up to B are allowed — practice chooses the token bucket, because real data traffic lives by bursts. The combination of both mechanisms sets two policing parameters — the sustained rate and the admissible "hump": it is in such terms that the contractual obligations of providers are formulated.

Queues: FIFO, drop tail, and the fair queue

When packets arrive faster than the outgoing link, they are buffered. The simplest discipline is FIFO with drop tail: the queue is full — the new packet is thrown out. Simple, cheap, and harmful: overflow at many nodes simultaneously synchronizes the losses of a multitude of TCP flows, and they synchronously go into slow start — the network breathes with sawtooth dips of throughput (global TCP synchronization). Besides, FIFO is unfair: an aggressive flow captures more of the queue and more of the channel. The answer was the fair queue (fair queueing; Demers, Keshav, and Shenker, SIGCOMM 1989): the ideal model — a server of its own for each flow; the real one — approximations like WFQ and SFQ. Later the idea returned into mass devices as fq_codel — the standard queueing discipline of the Linux kernel since 2017.

RED and ECN: signal instead of dropping

Sally Floyd and Van Jacobson in 1993 proposed RED (Random Early Detection): do not wait for the queue to overflow, but start randomly dropping (or, in the WRED variant, weighted by classes) packets in advance, when the average queue length exceeds a threshold. Randomness is fundamental: different TCP flows receive losses at different moments and desynchronize. RED became the bridge to ECN (Explicit Congestion Notification, RFC 3168, 2001): why spoil a packet if you can mark it? Two bits in the IP header declare: "the sender is ECN-capable" (ECT) and "there was congestion at the router" (CE). TCP reduces the window as if the packet had been lost — but without the loss. Deploying ECN took a decade and a half: the pioneers were data centers (DCTCP, 2010, uses the fraction of marks), then operators and client stacks caught up.

Bufferbloat: how buffers ate the delay

In 2009–2011, Jim Gettys and Kathleen Nichols described a systemic disease that received the name bufferbloat: manufacturers of home and carrier equipment installed huge queues — "so as not to lose packets." The result turned out to be the opposite: on a clogged channel of a home router, packets stand for seconds in a multi-megabyte queue, the delay grows to 5–10 s, VoIP and games become impossible, and TCP, seeing the absence of losses, keeps accelerating. Losses are a poor congestion signal, but their absence in a gigantic buffer is an even worse signal: the network stays silent until it starts "choking" on delay.

The medicines are active queue management algorithms (AQM). CoDel (Controlled Delay; Nichols and Jacobson, 2012) tracks not the length of the queue, but the minimum delay of packets in it: if it steadily exceeds the target (5 ms), packets begin to be dropped at a shrinking interval — this quickly damps the congestion and does not punish short bursts. FQ-CoDel adds fair separation by flows; PIE (RFC 8033) solves the same task with a PI controller. All three became part of DOCSIS 3.1 and the Linux kernel. The final chord is the L4S architecture (RFC 9330–9332, January 2023): two separate queues for traffic with a "fine" reaction to ECN marks and for classic traffic — delay in units of milliseconds at full utilization of the channel. Thirty-seven years between the collapse of 1986 and L4S — and all that time the problem was one: how to honestly tell the sender that the network is congested, without dropping packets.

QoS: IntServ, RSVP, and DiffServ

Different applications need different things: a video call needs low delay and jitter (it will survive losses of up to a few percent); a file transfer needs reliability while being indifferent to delay; web surfing — something in between. A "best effort" network does not understand this: all packets are equal.

The first attempt — IntServ (RFC 1633, 1994): the application reserves resources for a flow with the signaling protocol RSVP (RFC 2205, 1997); every router stores the reservation state and guarantees bandwidth and delay. The model is beautiful and unscalable: per-flow state in the core of the Internet is exactly those virtual circuits that the network once rejected. IntServ survived in niches, and RSVP degenerated into RSVP-TE — a traffic engineering protocol for MPLS.

The second attempt turned out to be viable — DiffServ (RFC 2474/2475, December 1998): 6 bits of the DSCP field in the IP header set the class of service of the packet; routers apply to the classes a per-hop behavior (PHB): EF (Expedited Forwarding) — low delay for voice, AF (Assured Forwarding) — a guaranteed share with gradations of importance, BE (Best Effort) — everything else. No per-flow state: only classes — scalable and simple. The main flaw: DSCP must be understood identically by all networks along the path, but between domains the marks are erased — nobody wants to carry someone else's "premium traffic" for free. That is why DiffServ works wonderfully inside a trusted domain — a provider, a corporation, a data center (voice in VoLTE is marked EF) — and works almost nowhere end-to-end across the whole Internet. The honest compromise of the hourglass: global simplicity versus local manageability.

Fragmentation and Path MTU Discovery

MTU: why packets have to be cut

Every data link layer network has a maximum frame size, and the IP packet inside has an MTU (Maximum Transmission Unit). Ethernet — 1500 bytes, PPPoE — 1492 (8 bytes are eaten by the PPP headers), FDDI — 4352, tunnels — 1500 minus the overhead (GRE, IPsec, VXLAN eat from 24 to 50+ bytes). A packet assembled for a "thick" network may not fit into a "narrow" one along the way — and then the IPv4 router divides it into fragments.

How it works

The fragments of one packet carry the same Identification and different Fragment Offsets; all except the last have the MF flag raised. The fragments travel independently and may arrive in any order; the receiver buffers them and assembles the original packet. Reassembly is performed only at the end node: intermediate routers do not reassemble fragments — otherwise each would store fragment state, and that is again virtual circuits, only without the advantages.

The consequences are harsh: the loss of any fragment kills the whole packet — a packet of ten fragments, at a fragment loss probability of 1%, arrives with a probability of about 90%. Reassembly requires memory and timers — a vector of resource attacks. Only the first fragment contains the L4 headers: firewalls filtering by ports see them only in the first piece, and let the rest through "blind."

Attacks on fragmentation

Fragmentation gave security a genre of its own. The teardrop attack (1997) sent fragments with overlapping offsets — Windows and Linux stacks got confused during reassembly and crashed. Ptacek and Newsham's work "Insertion, Evasion, and Denial of Service" (1998) showed how overlapping fragments allow "hiding" the attack payload from an IDS: the detection system and the end node assemble one set of fragments into different packets. Tiny fragment — a tiny first fragment into which the TCP ports do not fit — bypassed early filters. The modern response: prohibiting fragmentation where it is not needed (in IPv6 there is none in transit), packet normalization at the IDS, and filtering of anomalous fragments.

Path MTU Discovery and black holes

The correct strategy is not to cut packets along the way, but to know in advance the minimum MTU on the whole route. For this there is PMTUD (Path MTU Discovery, RFC 1191, 1990, Mogul and Deering): the sender raises the DF bit ("do not fragment"); the router for which the packet is too big discards it and returns an ICMP Fragmentation Needed with its MTU; the sender reduces the size and tries again.

In practice, PMTUD is famous for "black holes": if somewhere along the path an administrator has filtered all ICMP, the packets with DF die silently, the sender learns nothing, and the connection "hangs" — a symptom familiar to anyone who has configured a VPN (RFC 2923 is devoted entirely to this pathology). The medicines: MSS clamping (the router corrects the MSS option in the TCP handshake, RFC 6691), PLPMTUD (RFC 4821, RFC 8899) — probing the path with packets of different sizes without relying on ICMP — and common sense: do not filter ICMP Fragmentation Needed. In IPv6 there is no fragmentation in transit at all, so PMTUD through ICMPv6 Packet Too Big is a mandatory part of the network's operation; to break it is to break IPv6 connectivity entirely.

NAT: the crutch on which the Internet rests

History and reasons

NAT (Network Address Translation) was invented as a temporary measure: RFC 1631 (May 1994, Kjeld Egvang and Paul Francis) described address translation as a bridge that would stretch IPv4 until the victorious deployment of IPv6. Thirty-two years have passed; IPv6 is at half of users; NAT has become not a bridge but a load-bearing structure — practically every home router in the world today is a NAT device, and large mobile operators have "double NAT" (CGNAT). The reason is the shortage of IPv4 addresses; the second, unexpected reason is "free" security: from outside, the network cannot be reached without explicit configuration.

How NAT works inside the router

The classic case is NAPT (Network Address Port Translation), also known as PAT: not only addresses, but also ports are translated. An internal host 192.168.1.5 sends a packet to 8.8.8.8 from port 1234. The router substitutes the pair (IP, port) with its external one — (80.123.45.6, 54321) — and writes into the translation table the line 192.168.1.5:1234 ↔ 80.123.45.6:54321. When the reply arrives, the router finds the line and substitutes the addressee back. The entries live as long as the connection is alive — and it is precisely this table that is the state which NAT adds to the "stateless" datagram network. One public address serves thousands of connections this way: the theoretical limit is about 64 thousand translations.

The consequences: the end of the end-to-end model

NAT breaks end-to-end addressing: from the Internet you cannot simply "knock" on a specific host. This hits all protocols based on incoming connections: P2P, game servers, IP telephony, remote access. The community responded with an industry of workarounds: STUN (RFC 5389) allows a host to learn its external address and the "type" of NAT (symmetric is the hardest to punch through), TURN (RFC 5766) — a relay, a guaranteed but traffic-billed path, ICE (RFC 8445) — an algorithm that tries all variants and chooses the one that works; WebRTC and all modern P2P are built on this stack. For local networks there are UPnP IGD, NAT-PMP, and PCP (RFC 6887) — protocols by which devices ask the router to "forward a port" automatically; their security is a separate headache (vulnerabilities like CallStranger showed that UPnP is better not listened to from the internet).

Separately suffer the protocols that carry IP addresses inside the payload: FTP in active mode, SIP, H.323, IPsec ESP. For them, ALG (Application Level Gateways) were invented — router modules that peek into the payload and correct the addresses; ALGs are so fragile that the modern style is "turn off ALG and use the right protocol." IPsec was saved by NAT-T mode (encapsulation of ESP in UDP/4500).

CGNAT and the address market

Carrier-grade NAT (CGN, Carrier-Grade NAT) places the translation at the provider: thousands of subscribers share a pool of public addresses, and their internal addresses live in the range 100.64.0.0/10 (RFC 6598) so as not to conflict with the home 192.168.x.x. Double translation aggravates all the problems of NAT and adds new ones: several subscribers on one public address break geolocation, the "requests per second per IP" limits of services, and forensics — to understand which of a thousand subscribers was online from the address at a given moment, the provider is obliged to keep port allocation logs, which is itself a question of privacy.

Economically, CGNAT is a way not to buy IPv4 at market price and not to hurry with IPv6. Mobile networks are ahead here: T-Mobile US and Reliance Jio operate IPv6-only, and IPv4 availability is provided by translation — a scheme that was conceived back in 2011–2012 as the mainline path of transition.

NAT as a "firewall": myth and reality

The opinion is widespread that NAT is security. Reality is more complicated: yes, NAT blocks unwanted incoming connections — but the simplest firewall does the same and does it better: a stateful firewall understands which packet belongs to an established connection, and NAT does not. NAT breaks end-to-end cryptography (IPsec in transport mode does not work through NAPT), interferes with logging, and gives a false sense of being protected. The correct formulation: NAT is an address translator with a side effect of filtering, not a means of protection; security is given by the firewall, and the address deficit is cured by IPv6.

Anycast, multicast, and multipath routing

Besides the familiar unicast ("one address — one node"), the network layer knows two more addressing models and one load distribution model, each with its own fate.

Anycast: one address — many nodes

Anycast is a mechanism in which one and the same IP address is announced from many points of the network (usually through BGP), and routing itself brings the sender to the "nearest" instance — nearest in the sense of BGP policy, not of kilometers. The sender does not know which physical server it will hit; different packets of his may arrive at different instances; therefore it is safe to build on top of anycast primarily stateless protocols — first of all DNS.

It was DNS that made anycast an industry standard: of the thirteen "root" logical servers of the Internet, by the mid-2020s more than a thousand and a half instances are physically deployed around the world. The public resolvers of Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) are also anycast: a user in Delhi and a user in Frankfurt address one and the same address, but land in different data centers. For CDNs and DDoS protection, anycast is a way to spread an attack across points of presence. The practice of operation is described in RFC 4786 (2007); the main requirements are the stability of announcements (switching instances tears connections) and the consistency of state where it is needed.

Multicast: a beautiful idea that did not become a mass service

Multicast solves the task "one sender — a group of recipients" without duplicating traffic: the packet is addressed to a group (in IPv4 — the range 224.0.0.0/4, in IPv6 — ff00::/8); routers build delivery trees and replicate packets only at the branching points. The savings when broadcasting to millions are obvious.

The history of multicast is romantic: in March 1992, at an IETF meeting in San Diego, Steve Casner and Van Jacobson broadcast audio to dozens of sites around the world — the MBone was born, a network of tunnels linking the islands of multicast across the non-multicast ocean. In November 1994, the MBone broadcast a Rolling Stones concert — one of the first mass internet streams. The group management protocols (IGMP at the edge, PIM in the core) were created and standardized.

But in the global Internet, multicast never became a common service. The reasons: per-group state in every router (again scaling), the asymmetry of economics (the sender saves, the recipients pay with transit), the complexity of diagnostics, and the weakness of source control. Multicast survived where there is one administrative domain: IPTV at operators, stock exchange quote distributions, internal data center distributions. In IPv6 it became a mandatory part of the architecture, but it did not generate mass "broadcast" services — the niche was taken by CDNs and adaptive streaming over ordinary unicast.

ECMP: multipath as a way to use all the metal

Real networks are redundant: between two routers there are almost always several equivalent links, between data centers — dozens of paths. ECMP (Equal-Cost Multi-Path) allows keeping in the table several next hops for one prefix and distributing flows among them — not per packet (otherwise the order inside a TCP flow would break), but by a hash of the tuple (source IP, dest IP, protocol, ports).

ECMP is the foundation of the modern Internet: without it, neither link aggregation at providers nor data center networks (where the Clos topology gives dozens of equal paths) would be possible. Its diseases are just as fundamental: the hash can be unlucky (two "elephants" — huge flows — land on one link and clog it while the others idle); when the topology changes, part of the flows jumps to other paths and overtakes already-sent packets (reordering breaks TCP). The answers are balancing by flowlet (bunches of packets inside a flow), adaptive routing in the newest fabric switches, and algorithms like Hedera and CONGA.

MPLS and traffic engineering

Labels instead of prefixes

MPLS (Multiprotocol Label Switching; architecture — RFC 3031, January 2001) inserts between the L2 and L3 headers a short label (20 bits). The edge router (LER) analyzes the IP packet once and attaches a label; the internal ones (LSR) then look only at the label: "label 42 arrived from port 3 → replace it with 77 and send it out port 5." The label table is small, the lookup is trivial — this is switching, not routing. The label stack allows tunnels to be nested inside each other.

Historically, MPLS was sold as an accelerator: in the late 1990s, the longest prefix match search in software was slow. By the mid-2000s the motive was outdated — TCAM and ASICs made IP lookup hardware-based. But MPLS did not die; it was reborn: its real value turned out to be not in speed.

What it is really needed for

The first value of MPLS is traffic engineering. IP routing drives all traffic along one "best" path, leaving the backup ones idle; MPLS with RSVP-TE allows explicitly laying a tunnel along a chosen route — around a congested node, with guaranteed bandwidth. The second is VPN (RFC 4364): the provider sells clients isolated networks, where the address spaces may overlap, routes are separated by VRF, and transport is provided by labels. The third is independence from IP: IPv4, IPv6, Ethernet frames, and anything else are carried over MPLS — a universal backbone transport, where IP itself is only one of the passengers.

Practically all backbone networks of providers of the 2000s–2020s are built on MPLS in the core with IP/BGP at the edges. The Internet user does not see this — and should not: MPLS lives inside autonomous systems; between domains, BGP still reigns.

Segment routing: SR-MPLS and SRv6

The new generation is Segment Routing (SR; architecture RFC 8402, 2018): the path of the packet is set not by state in the intermediate nodes, but by a list of segments in the packet itself — "go through node A, then through link B, then to C." Each segment is a number (in SR-MPLS it is a label; in SRv6 — a 128-bit IPv6 address with a behavior program). The state disappears from the core: the source or a controller "sews" the path into the header, and the transit nodes follow the instruction.

SRv6 (RFC 8986, 2021) is especially interesting: a segment is an IPv6 address, and its low-order bits are a function of the node ("forward," "apply policy"), that is, the processing program is sewn into the address itself. By the mid-2020s, SRv6 is being actively deployed by large operators — as a replacement for MPLS where one IPv6 stack is needed for all occasions. Thus virtual circuits, having lost to datagrams in the 1980s, made a third attempt — in the form of "source routing" compatible with the datagram philosophy.

SDN: separating control from forwarding

The idea and the prehistory

The classic router combines two principles: the data plane (forwarding packets according to tables) and the control plane (the protocols filling the tables); the network as a whole is the result of the emergent behavior of thousands of independent decisions. SDN (Software-Defined Networking) proposes a separation: leave forwarding to simple hardware, and move control into a logically centralized software controller that sees the network as a whole and dictates flow rules to the devices.

The idea ripened for a long time: back in the 1990s there existed software-controlled switches (5ESS in telephony, "softswitch" in VoIP). The breakthrough came in 2008: the article "OpenFlow: Enabling Innovation in Campus Networks" by Nick McKeown and colleagues from Stanford described a protocol by which the controller adds, changes, and deletes "packet header → action" rules in switches. Routing innovations could now be written on the controller, without waiting for vendor firmware.

Controllers, whitebox switches, and practice

The ecosystem grew quickly: controllers NOX/POX/Floodlight, industrial ONOS and OpenDaylight, commercial platforms VMware NSX, Cisco ACI, "white" switches (whitebox) — standard hardware with an open network OS. In hyperscale data centers, SDN became the norm: the network is programmed by the same automation pipeline as the virtual machines.

But centralization turned out to be a double-edged stick. The controller is a single point of failure (treated by clustering, but the consistency of a distributed controller is itself a hard problem), and the full vision of the network runs into scale: millions of flows — millions of rules. And the main thing — Internet-scale SDN did not happen: the global Internet has no owner to whom control can be handed over; BGP with its political pluralism is "anti-SDN" by nature. SDN won inside domains (data centers, campuses, carrier cores) and stopped at their borders.

Data center networks: Clos and overlay

The modern data center is built on the Clos topology (leaf-spine): servers connect to leaf switches; those connect to spine switches by a complete bipartite graph; between any pair of servers there are several equivalent paths; ECMP distributes the flows; capacity is grown by adding spine rows. The structure invented by Charles Clos in 1952 for telephone switches turned out to be ideal for clouds.

On top of the physical IP network, an overlay is deployed — virtual tenant networks: VXLAN (RFC 7348, 2014) packs Ethernet frames into UDP/IP with a 24-bit VNI identifier (16 million isolated segments versus 4094 for VLAN), and EVPN over BGP (RFC 7432) carries the addresses of virtual machines between leaf switches. The L3 addressing of the physical world became the transport for a "virtual L2/L3" in which the workloads live — the hourglass squared: IP below holds the overlay, IP inside the overlay holds the applications.

Tunnels, VPN, and mobility

IP over IP

Tunneling — packing a packet of one protocol into a packet of another — is the universal tool of the network layer: this is how the IPv4/IPv6 transition mechanisms, MPLS transport, VXLAN, and VPNs work. The simplest variant is IP-in-IP (RFC 2003): the IP packet entirely becomes the payload of another IP packet. GRE (RFC 2784) adds universality — inside there can be not only IP but also Ethernet; many "virtual wires" are built this way. Tunnels are both a way to bypass restrictions and a way to impose them: routing through a tunnel hides from the operator the real endpoints of the traffic.

IPsec: cryptography of the network layer

IPsec is a family of protocols built directly into IP: AH authenticates the packet as a whole (and is almost not used — it is incompatible with NAT), ESP (Encapsulating Security Payload, protocol 50) encrypts and authenticates the payload, IKE negotiates the keys. Modes: transport (the payload is protected) and tunnel (the packet is wrapped entirely — the basis of "site-to-site" VPN).

The history of IPsec is instructive. Developed in the mid-1990s as a mandatory part of IPv6, it never became ubiquitous: the mandate quietly died out, IKE is famous for the complexity of its configuration, NAT breaks transport mode. IPsec survived in three niches: VPN between branches (being displaced by WireGuard), remote access (being displaced by the zero trust model), and… the cryptography of BGP: sessions between the routers of providers are protected precisely by ESP in transport mode. The irony of the architecture: the protocol that was predicted to become the protection of the entire Internet became the working tool for protecting routing itself.

Where IPsec required certified gateways, modern minimalism offers WireGuard (Jason Donenfeld, 2015–2017; in the Linux kernel since 2020): about 4000 lines of code, one cryptographic primitive (Noise), operation over UDP. The network layer for it is just a transport: WireGuard creates a virtual interface, and its routing is managed by the ordinary means of the OS. Yet another confirmation that simplicity beats completeness.

Mobile IP: mobility as a property of the layer

When a host moves between networks, its IP address changes, and connections break. Mobile IP (RFC 5944 for IPv4, RFC 6275 for IPv6) solves the task in the spirit of the layer itself: a permanent "home address" is fixed to the node; in a foreign network it obtains a "care-of address" and registers it with the home agent, and that one intercepts the packets to the home address and tunnels them to the care-of address. For the correspondent, the node is motionless.

In practice, Mobile IP is almost not used — it was eclipsed by solutions above and below: applications learned to survive an address change (QUIC binds the session to a connection ID, not to an IP), and cellular operators solved mobility in their own plane: GTP tunnels all the traffic of the phone through a fixed point in the operator's network, so that the phone, from the point of view of the Internet, is always "at home." The task that the layer can solve, the world solves where it is more convenient — and Mobile IP remained a beautiful textbook example of tunnel mobility.

Security of the network layer

The absence of source authentication

An IP packet can be sent with any source address: the Source Address field is not checked by the network. This spoofing is the congenital defect of the architecture, laid down not out of negligence, but out of philosophy: the delivery network does not know who pays for the tickets. The consequences are the whole genre of DDoS attacks with amplification and reflection: the attacker sends small requests with the victim's forged address to open servers (DNS, NTP, memcached), and those flood the victim with large responses; the amplification reaches tens of thousands of times (memcached — up to 51,000×, which allowed the attack on GitHub in February 2018 to reach 1.35 Tbit/s).

The answer has been known since 2000: BCP 38 (RFC 2827) — ingress filtering, checking at the boundary of the network that outgoing packets carry addresses from its prefixes. Later were added uRPF (RFC 3704) — checking the reversibility of the path in routers, and SAVI — binding addresses to the ports of access switches. According to the many-year measurements of the Spoofman project (CAIDA), the share of networks from which a forged address cannot be sent grew from single digits of percent in the mid-2000s to two thirds by the mid-2020s — but the BCP 38 rule is still voluntary, and "spoofable" networks remain the raw material base of botnets. Here, as in a mirror, the political economy of the network layer is visible: the correction of a defect known to everyone has for decades run not into technology, but into the absence of coercion.

Attacks on the mechanisms of the layer itself

Besides spoofing, all the service mechanisms are vulnerable: ARP poisoning, ICMP Redirect forcing a host to change its route to the attacker's, false ICMP error messages tearing connections, fragmentation attacks bypassing inspection tools, BGP hijacks and leaks, DHCP starvation, DNS cache poisoning (demonstrated by Dan Kaminsky in 2008) — formally a level higher, but exploiting the anycast and UDP nature of network delivery. The network layer is an attack surface in its entirety: almost everything listed exists because the service protocols of the layer were designed in an era of trust.

What has been done and what is missing

The modern set of protections: RPKI for route origin (60% valid by March 2026), ASPA/OTC for relationships and leaks, BGPsec for the path (almost not deployed), filtering by BCP 38/uRPF/SAVI, prefix limits on BGP sessions (which Verizon did not set in 2019), coordination through RFC 9234. The protection is built from the bottom up, by the agreement of the participants, not by decree from above — MANRS as a "gentleman's set." The vulnerability of the system is determined by its weakest participant, and the price of the error of a single operator is global: we saw this in 2008 with YouTube, in 2021 with Facebook, and in January 2026 with Cloudflare.

The path of a packet through the Internet: putting it all together

Let us trace one HTTP request from a laptop to a server, using all the apparatus we have dissected. This exercise is useful in that it shows: not one of the mechanisms works in isolation.

1. DNS. The application knows only the name. The resolver (usually an anycast address like 1.1.1.1 or 8.8.8.8) iteratively queries the root servers, the zone servers, and the authoritative servers of the domain, obtaining the IP of the server. Each of these requests itself traveled the entire path described below — the Internet rests on the recursion of its own protocol.
2. The local decision. The host's stack compares the destination IP with the subnet mask: the address is "foreign," the packet will go through the default gateway — the home router.
3. ARP. The host looks in its cache for the router's MAC; if there is no entry — a broadcast request "who has 192.168.1.1?", the reply, the cache. The packet is laid into an Ethernet frame: source MAC — the laptop, destination MAC — the router, destination IP — the final server (unchanged!).
4. NAT. The router allocates a port on the external address, writes a line into the translation table, rewrites the source IP:port. Now, for the Internet, the packet originates from the router's provider address.
5. The provider's backbone. The routers decrement the TTL, do a longest prefix match over the FIB (filled by OSPF/IS-IS and iBGP), ECMP chooses one of the equivalent paths; possibly the packet travels inside an MPLS or SRv6 tunnel, and the DSCP determines the queue at the output. At the AS boundary, eBGP has already chosen the best external route by policy: local pref, AS_PATH length, MED.
6. Between systems. The packet crosses a chain of autonomous systems — possibly through an IXP in one hop, possibly through transit providers on another continent; the path was chosen not by mileage, but by valley-free rules and contracts. At every boundary — a new MAC, a new TTL, the same destination IP.
7. The destination data center. Anycast or an L4 balancer brings the packet to the rack; the overlay network (VXLAN/EVPN) carries it to the virtual machine; firewalls check the legitimacy of the connection.
8. The response. The server answers to the external NAT address and the translated port; the router finds the line in the translation table and restores the internal address; TCP assembles the segments into a stream; the application receives the response. The path took tens of milliseconds and 10–20 hops — each with its own queue, policy, and probability of error.

What remains unchanged along the whole path: the source and destination IP addresses (if NAT is not counted). What changes at every hop: the MAC addresses of the frame, the TTL, the header checksum. What can happen on the way: loss (an overloaded queue), delay (buffers), reordering (ECMP when routes shift), fragmentation (a narrow MTU), discarding by filters, hijacking (a BGP incident). And to all of this the network layer gives one answer: best effort — and diagnostic tools (ping, traceroute) to understand where exactly everything broke.

Conclusions

The network layer is a global system for delivering packets through a multitude of independent networks, built on a compromise between simplicity, scalability, and manageability. Everything we have dissected fits into several through-lines.

The first line — simplicity as a strategy. The datagram model, best effort IP, the absence of state in the core, the end-to-end argument: the network is deliberately made "dumb" in order to survive, scale, and not depend on the technologies of the edges. For this it paid with reliability (TCP restored it), quality of service (DiffServ, queues, and AQM are fixing it — and still have not fixed it globally), and security (BCP 38, RPKI, MANRS are patching it — voluntarily and slowly). Every "hole" of the network layer is not an oversight of the designers, but a conscious price of a choice, which each generation of engineers revisits anew.

The second line — hierarchy against growth. CIDR, aggregation, autonomous systems, OSPF areas, ECMP, tunnels: all these are ways to keep a table of a million prefixes within the limits of hardware memory and protocol convergence time. The full table could be 44% smaller with perfect aggregation — the difference between the ideal and reality is the cost of multihoming, traffic engineering, and distrust between participants. The scalability of the Internet is not a property of algorithms, but the result of continuous bargaining between the compactness of common structures and the specificity of private interests.

The third line — economics as a protocol. BGP routes not packets, but contracts. Valley-free rules, peering versus transit, IXPs as market squares, anycast as a way to sell proximity — the topology of the Internet repeats the topology of its business. Hence the fragility too: the system has no center, neither technical nor political; a globally optimal route does not exist in principle; and the only "police" is the mutual interest of the participants not to burn the common field. The chronicle of incidents from AS7007 (1997) to the Cloudflare leak (2026) is the story of how a trust-based protocol lives in a hostile world — and so far survives.

The fourth line — permanent evolution. The network layer has changed three times and has not stopped: IPv4 survived the exhaustion of addresses thanks to NAT and the address market; IPv6 reached half of users in thirty years; inside the layer, MPLS replaced ATM, SDN and SRv6 are replacing the classic control planes, L4S closes the gestalt of buffering of 1986. The hourglass works: the waist of IP remains narrow, while the worlds above it and below it are renewed continuously.

For the engineer, the practical conclusion sounds like this. First, to understand the network layer means to understand where exactly the connection breaks: ping and traceroute cover the diagnostics of availability; MTU and ICMP filtering explain VPN "hangs"; NAT translation tables — the unavailability of services; BGP monitoring — global "storms." Second, almost all real accidents of the layer are configurational: an empty prefix list, a removed limit, an unfiltered announcement, a blocked ICMP; therefore discipline (filters by default, session limits, RPKI, BCP 38) is more important than any single protocol. Third, the network layer teaches humility: a network of a million independent participants is not managed by decree — it evolves by agreements.

The Internet works not because it is perfect, but because it is simple enough to scale and distributed enough to survive the mistakes of each individual participant. The network layer is the place where this philosophy is turned into engineering solutions: TTL instead of flawless tables, best effort instead of guarantees, policy instead of the optimum, BCP instead of police. The next step up is the transport layer, where TCP and UDP will take upon themselves everything that IP consciously gave up: reliability, order, flow, and connection.