Drop VLSM terminology from subnetting post, add IANA references

Replaces every user-visible use of 'VLSM' / 'Variable-Length Subnet
Masking' with plain descriptions of what the allocator is doing.
Everything already lives under CIDR; the separate VLSM label was an
extra name for the same mechanism and not helpful.

Retitles the post to 'what the slash actually means'.

Expands the reserved-ranges section with proper authority links:
IANA itself, the IPv4 Special-Purpose registry, the multicast registry,
RFCs for NAT, loopback, DHCP, OSPF, PIM, limited broadcast, CGN, and
whois, plus a pointer to the five regional internet registries.
This commit is contained in:
Graham McIntire 2026-04-22 16:47:49 -05:00
parent 87368d28d7
commit 632cb96cd6
No known key found for this signature in database
GPG key ID: F4ABF488E6029E59
3 changed files with 19 additions and 19 deletions

View file

@ -37,7 +37,7 @@ Working scratch list. Same format as the NLOS post: vanilla JS, 2D canvas, scene
- **Garbage collection, three flavors.** Same heap, same allocation pattern, three collectors running in parallel panes: mark-sweep, copying, generational. Watch pause times and fragmentation diverge. Slider for allocation rate to find where each collector falls over.
- **Branch prediction history.** A loop with a data-dependent branch. Toggle between always-taken, two-bit saturating counter, and a small perceptron predictor. Mispredict rate and pipeline bubbles rendered as wasted clock ticks.
- **A load balancer at work.** Incoming requests, a pool of backends with varying response times. Switch between round robin, least connections, and consistent hashing. Kill a backend and watch the failure modes differ.
- **Subnetting IPv4.** An address and a prefix length. Slider from /8 to /30. Bits light up in the network and host portions. Host count, usable range, broadcast address, and subnet mask all recompute live. Second scene: take a /22 and carve it into a /24 + /25 + /26 + /27 + /28 to fit a specific set of site sizes. Overlap and waste rendered visually so VLSM clicks. Third scene: two hosts with given addresses and masks; show whether they're on the same subnet and, if not, what the gateway decision looks like.
- **Subnetting IPv4.** An address and a prefix length. Slider from /8 to /30. Bits light up in the network and host portions. Host count, usable range, broadcast address, and subnet mask all recompute live. Second scene: take a /22 and carve it into a /24 + /25 + /26 + /27 + /28 to fit a specific set of site sizes. Overlap and waste rendered visually so mixed-size CIDR carving clicks. Third scene: two hosts with given addresses and masks; show whether they're on the same subnet and, if not, what the gateway decision looks like.
- **Layer 2 and layer 3, side by side.** A small network: a few hosts, a switch, a router, two subnets. A packet leaves a host with a destination IP on the other subnet. Watch the ARP for the default gateway, the L2 frame addressed to the router's MAC, the router rewriting the L2 header and forwarding out a different interface, another ARP on the far side, final delivery. Toggle between a hub (collisions visible), a learning switch (MAC table filling in), and a router (routing table consulted per packet). Second scene introduces VLANs and trunking: the same switch logically split, a trunk port carrying tagged frames, the router-on-a-stick doing inter-VLAN routing. The phrase "broadcast domain" stops being abstract.
- **TCP in the weeds (follow-up to how-tcp-and-udp-work).** MSS negotiation, Path MTU Discovery, segmentation of a 10 KB write into 1460-byte segments, fast retransmit and SACK, delayed/accumulated ACKs, Nagle's algorithm, the PSH and URG flags, connection teardown with FIN/FIN-ACK and the TIME-WAIT state, keepalives and persist timers. One scene per mechanism with a small packet diagram each. Written for the reader who already understands the basics.

View file

@ -8,11 +8,11 @@ draft = true
<div class="scene-host" data-scene-host>
An [IPv4 address](https://en.wikipedia.org/wiki/IPv4) is 32 bits. That is the whole of it. Everything else you ever hear about subnets, masks, supernets, VLSM, CIDR, and the `/24` that turns up in every man page on Earth is just an elaborate argument about where to draw a line in those 32 bits and what the two halves mean.
An [IPv4 address](https://en.wikipedia.org/wiki/IPv4) is 32 bits. That is the whole of it. Everything else you ever hear about subnets, masks, supernets, CIDR, and the `/24` that turns up in every man page on Earth is just an elaborate argument about where to draw a line in those 32 bits and what the two halves mean.
The address gets dressed up in dotted decimal for the benefit of humans who do not like reading binary, and it is easy to forget there are only ever bits underneath. The prefix length (the number after the slash) is the scoreboard: everything to the left is the network, everything to the right is a host within that network. Move the line, change the number of networks, change the number of hosts per network. The math is not complicated. It only feels that way because it is usually taught by somebody reading out a subnet mask table instead of letting you see the bits.
Below, the same territory in three scenes. Start with the address and the mask, then carve a block into a mix of smaller blocks (VLSM), then do the one routing decision every host makes on every outbound packet: am I talking to you directly, or do I need to hand this to my gateway?
Below, the same territory in four scenes. Start with the address and the mask, then carve a block into a mix of smaller blocks, then roll a few blocks back up into a single supernet, then do the one routing decision every host makes on every outbound packet: am I talking to you directly, or do I need to hand this to my gateway?
## The address, the mask, and the slash
@ -24,15 +24,15 @@ Two host values are reserved in each subnet. The all-zeros host is the network a
A /32 is a single address with no room for anyone else, which is useful for loopbacks and host routes. A /0 is the whole internet, which is useful as a default route and for almost nothing else.
## Carving a block with VLSM
## Carving a block into mixed sizes
Early IPv4 had exactly three network sizes: /8, /16, /24, called Class A, B, and C. If you needed 500 addresses you got a /16 with 65,534 of them and threw 65,034 in the bin. [Classless Inter-Domain Routing](https://datatracker.ietf.org/doc/html/rfc4632) arrived in 1993 to stop doing that. With CIDR and its close cousin [Variable-Length Subnet Masking](https://en.wikipedia.org/wiki/Subnetwork#Variable-length_subnet_masking), you can take any block and carve it into smaller blocks of whatever sizes you actually need, and you can do this recursively until the block has nothing left to give.
Early IPv4 had exactly three network sizes: /8, /16, /24, called Class A, B, and C. If you needed 500 addresses you got a /16 with 65,534 of them and threw 65,034 in the bin. [CIDR](https://datatracker.ietf.org/doc/html/rfc4632) arrived in 1993 to stop doing that. Under CIDR any block can be split into smaller blocks of whatever sizes you actually need, and those in turn into smaller blocks, until the parent has nothing left to give.
<div id="scene-vlsm"></div>
The parent block above is a /22: four /24s, 1022 usable hosts. The slider picks a VLSM strategy that allocates the largest subnet first, then the next, and so on until the parent is full or the remaining space is too small to honor the request. Each subnet gets drawn at its correct size, which makes it visible how fast the address space disappears when you start asking for /24s, and how much further you can stretch the block when the things on it actually fit in /27s.
The parent block above is a /22: four /24s, 1022 usable hosts. The slider picks an allocation strategy that hands out the largest subnet first, then the next, and so on until the parent is full or the remaining space is too small to honor the request. Each subnet gets drawn at its correct size, which makes it visible how fast the address space disappears when you start asking for /24s, and how much further you can stretch the block when the things on it actually fit in /27s.
VLSM is greedy: largest first, then walk down. The rule is that every subnet must be aligned to its own size. A /24 has to start on a multiple of 256. A /26 has to start on a multiple of 64. You cannot hand out a /26 that starts at offset 32 any more than you can hand out a 64-byte block of memory that starts at a 32-byte boundary. If this feels familiar it is because IP address allocation and memory allocation are more or less the same problem, and in both cases the scheme that works is the one where everything lines up on powers of two and you do not argue with it.
The allocator is greedy: largest first, then walk down. The rule is that every subnet must be aligned to its own size. A /24 has to start on a multiple of 256. A /26 has to start on a multiple of 64. You cannot hand out a /26 that starts at offset 32 any more than you can hand out a 64-byte block of memory that starts at a 32-byte boundary. If this feels familiar it is because IP address allocation and memory allocation are more or less the same problem, and in both cases the scheme that works is the one where everything lines up on powers of two and you do not argue with it.
## Going the other way: supernetting
@ -42,23 +42,23 @@ Supernetting is the same operation as subnetting, run backwards. Take several sm
The two /24 subnets live inside 10.20.0.0/16. The red bracket is the smallest single prefix that covers both. Slide A and B to consecutive even positions (4 and 5, 128 and 129, 200 and 201) and the bracket neatly becomes a /23 with no collateral. Slide them apart or onto misaligned positions (say 3 and 4, or 5 and 8) and the supernet has to expand to cover everything between, sweeping in a lot of addresses that aren't yours.
This is the thing that always bites people the first time they try to "summarize their networks." You cannot announce 10.20.3.0/24 and 10.20.4.0/24 as 10.20.3.0/23, because /23 requires alignment to a multiple of 2, and 3 isn't. The smallest honest supernet for those two is 10.20.0.0/21, which pulls in six neighbors you probably don't own. The rule in both directions (VLSM and supernetting) is the same: the line has to fall on a power-of-two boundary, or the math quietly decides for you.
This is the thing that always bites people the first time they try to "summarize their networks." You cannot announce 10.20.3.0/24 and 10.20.4.0/24 as 10.20.3.0/23, because /23 requires alignment to a multiple of 2, and 3 isn't. The smallest honest supernet for those two is 10.20.0.0/21, which pulls in six neighbors you probably don't own. The rule in both directions (subnetting and supernetting) is the same: the line has to fall on a power-of-two boundary, or the math quietly decides for you.
The practical consequence is that address plans are designed, not discovered. If you intend to aggregate later, you allocate now in a way that lets the aggregation work: consecutive sites get consecutive, aligned blocks. Put one site in 10.1.0.0/20 and the next in 10.1.16.0/20, and later you can advertise 10.1.0.0/19 and every router on the internet silently thanks you.
## Reserved and special ranges
Not every address is fair game. The IANA has set aside a list of blocks for specific purposes, and a few are worth knowing by heart.
Not every address is fair game. The [IANA](https://www.iana.org/) keeps the [IPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml), which is the authoritative list of blocks set aside for specific purposes. Below are the ones that come up often enough to be worth knowing by heart.
- **10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16** are [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) private space. Route them inside your network, NAT them at the edge, never let them leak out. The internet at large will not route them back.
- **127.0.0.0/8** is loopback. The whole /8 works, not just 127.0.0.1, but everyone pretends it's only the one address because the other 16.7 million feel wasteful and are.
- **169.254.0.0/16** is [link-local](https://datatracker.ietf.org/doc/html/rfc3927). A host that fails to get a DHCP lease gives itself an address in this range and can at least talk to its neighbors on the same link. If you ever see a machine with a 169.254 address, its DHCP server is not well.
- **224.0.0.0/4** is multicast, used for routing protocols (OSPF, PIM) and for any application that wants one-to-many delivery without sending N copies.
- **255.255.255.255** is the limited broadcast address, which means "everyone on this link right now." DHCP clients use this before they know their own address.
- **10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16** are [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) private space. Route them inside your network, [NAT](https://datatracker.ietf.org/doc/html/rfc3022) them at the edge, never let them leak out. The internet at large will not route them back.
- **127.0.0.0/8** is [loopback](https://datatracker.ietf.org/doc/html/rfc1122#section-3.2.1.3). The whole /8 works, not just 127.0.0.1, but everyone pretends it's only the one address because the other 16.7 million feel wasteful and are.
- **169.254.0.0/16** is [link-local](https://datatracker.ietf.org/doc/html/rfc3927). A host that fails to get a [DHCP](https://datatracker.ietf.org/doc/html/rfc2131) lease gives itself an address in this range and can at least talk to its neighbors on the same link. If you ever see a machine with a 169.254 address, its DHCP server is not well.
- **224.0.0.0/4** is [multicast](https://datatracker.ietf.org/doc/html/rfc5771), used for routing protocols ([OSPF](https://datatracker.ietf.org/doc/html/rfc2328), [PIM](https://datatracker.ietf.org/doc/html/rfc7761)) and for any application that wants one-to-many delivery without sending N copies. The [IANA multicast registry](https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml) carves this further for specific protocols.
- **255.255.255.255** is the [limited broadcast](https://datatracker.ietf.org/doc/html/rfc919) address, which means "everyone on this link right now." DHCP clients use this before they know their own address.
- **0.0.0.0** is "this host, this network" in some contexts and "any address" in others, depending on where you're listening. A service bound to 0.0.0.0 is listening on every interface the host has.
- **100.64.0.0/10** is [RFC 6598](https://datatracker.ietf.org/doc/html/rfc6598) shared address space, introduced so that ISPs could do carrier-grade NAT without stepping on RFC 1918 space that their customers were probably already using.
- **100.64.0.0/10** is [RFC 6598](https://datatracker.ietf.org/doc/html/rfc6598) shared address space, introduced so that ISPs could do [carrier-grade NAT](https://datatracker.ietf.org/doc/html/rfc6888) without stepping on RFC 1918 space that their customers were probably already using.
There's a longer list, but these are the ones that come up in real troubleshooting. If a packet surprises you, the surprise usually involves one of these ranges showing up somewhere you didn't expect it.
The [regional internet registries](https://www.iana.org/numbers) (ARIN, RIPE, APNIC, LACNIC, AFRINIC) hand out the rest of the space to ISPs and end users under delegation from IANA. If you want to know who owns a given public address, look it up in the matching registry's [whois](https://www.rfc-editor.org/rfc/rfc3912) service. If a packet surprises you, the surprise usually involves one of the reserved ranges above showing up somewhere you didn't expect it.
## Same subnet or gateway: the decision a host makes on every packet

View file

@ -291,7 +291,7 @@
}
// ============================================================
// Scene 2: VLSM carving of a /22
// Scene 2: CIDR carving of a /22
// ============================================================
function sceneVLSM() {
// Predefined request lists. The scene greedy-allocates in order from the parent /22.
@ -318,7 +318,7 @@
{ key: 'wasted', label: 'Unused' },
{ key: 'fit', label: 'Requests honored' },
],
caption: 'Greedy VLSM allocation: largest subnet first, each aligned to its own size boundary. Hover or read the labels to see each subnet\'s prefix, network address, and usable host count. The slider on the right lets you change the parent block size so you can see when the same strategy runs out of room.',
caption: 'Greedy allocation: largest subnet first, each aligned to its own size boundary. The labels show each subnet\'s prefix, network address, and usable host count. The slider on the right lets you change the parent block size so you can see when the same strategy runs out of room.',
});
if (!s) return;
@ -662,7 +662,7 @@
{ key: 'covered', label: 'Covered' },
{ key: 'wasted', label: 'Collateral' },
],
caption: "Supernetting is the inverse of VLSM: take several contiguous subnets and find the smallest single prefix that covers them all. The only time this works cleanly is when the subnets are adjacent AND the group starts on a boundary aligned to its own combined size. When they aren't, the supernet balloons up to include every address in between, which is why you can't just 'summarize' any two subnets you happen to own.",
caption: "Supernetting is subnetting run in reverse: take several contiguous subnets and find the smallest single prefix that covers them all. The only time this works cleanly is when the subnets are adjacent AND the group starts on a boundary aligned to its own combined size. When they aren't, the supernet balloons up to include every address in between, which is why you can't just 'summarize' any two subnets you happen to own.",
});
if (!s) return;