What does the IPv4 special-purpose address registry (RFC 6890) record about each reserved block, and how does it separate documentation, shared and private space?
answer
- five booleans per block
- valid as source, valid as destination
- forwardable versus globally reachable
- documentation never on the wire
basics
~20 sFor each block the registry records whether its addresses are valid as source and as destination, forwardable by routers, globally reachable and reserved by IP itself. Documentation blocks are invalid as either; RFC 1918 and 100.64.0.0/10 are forwardable but not globally reachable.
solid answer
~50 sRFC 6890 (BCP 153) set up the IANA IPv4 Special-Purpose Address Registry and gives each entry five booleans: **Source** and **Destination** (is an address from the block valid in that field of a datagram that crosses two devices), **Forwardable** (may a router forward it between external interfaces), **Global** (may it be forwarded beyond an administrative domain; RFC 8190 renamed this **Globally Reachable**) and **Reserved-by-Protocol** (must every IP implementation treat it specially). If Destination is false, the next two must be false. The documentation blocks `192.0.2.0/24`, `198.51.100.0/24` and `203.0.113.0/24` are false across the board: they belong in text, not packets. RFC 1918 space and `100.64.0.0/10` shared address space are valid and forwardable but not globally reachable. The difference between those two is who uses them: enterprises for RFC 1918, service providers between carrier-grade NAT and customer equipment for RFC 6598.
go deeper
Remember that a registry lists every reserved IPv4 block, and that the three TEST-NET /24s are the addresses to use in examples and documentation.
Explain the five booleans, the rule that a false Destination forces false Forwardable and Globally Reachable, and why private and shared space have the same booleans but different users.
Use the registry as the source of truth for any address-classification code, and know what it leaves out: multicast lives in its own registry and deprecated entries change over time.
Decide how address-classification logic stays current: derive it from the live registries with an owner and a review trigger, instead of hard-coding a list someone remembered.
## Why a registry exists Reserved IPv4 blocks were once scattered across many RFCs. **RFC 6890** (Best Current Practice 153, 2013) consolidated them into two IANA registries, one for IPv4 and one for IPv6, and obsoleted the older catalogue RFC 5735. **RFC 8190** (2017) updated it. The IANA registry is the live list; the RFCs define what its columns mean. Each entry records the block, a name, the RFC that requested it, allocation and termination dates, and five booleans that say how the block behaves. ## The five booleans - **Source**: is an address from the block valid as the source of a datagram that transits two devices? - **Destination**: is it valid as the destination of such a datagram? - **Forwardable**: may a router forward a datagram with this destination between external interfaces? - **Global**, renamed **Globally Reachable** by RFC 8190: may such a datagram be forwarded beyond a specified administrative domain? The rename removed an ambiguity between "globally allocated" and "globally routable". - **Reserved-by-Protocol**: does the defining RFC require every compliant IP implementation to treat the block specially? One consistency rule: if **Destination** is false, **Forwardable** and **Globally Reachable** must also be false. ## The IPv4 entries | Block | Name | Src | Dst | Fwd | Global | By protocol | |---|---|---|---|---|---|---| | `0.0.0.0/8` | This host on this network | T | F | F | F | T | | `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` | Private-Use (RFC 1918) | T | T | T | F | F | | `100.64.0.0/10` | Shared Address Space (RFC 6598) | T | T | T | F | F | | `127.0.0.0/8` | Loopback | F | F | F | F | T | | `169.254.0.0/16` | Link Local (RFC 3927) | T | T | F | F | T | | `192.0.0.0/24` | IETF Protocol Assignments | F | F | F | F | F | | `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24` | Documentation, TEST-NET-1 to 3 (RFC 5737) | F | F | F | F | F | | `198.18.0.0/15` | Benchmarking | T | T | T | F | F | | `240.0.0.0/4` | Reserved | F | F | F | F | T | | `255.255.255.255/32` | Limited Broadcast | F | T | F | F | T | Notes on the table: loopback's falses carry a footnote, because a few protocols were granted exceptions. `192.0.0.0/24` is unusable except through more-specific entries inside it, such as `192.0.0.0/29` for DS-Lite, which have their own values. Limited broadcast's Reserved-by-Protocol was changed from false to true by RFC 8190. ## Documentation, shared and private, side by side - **Documentation** (`192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, RFC 5737): for examples in text. They should not appear on the public internet, operators should list them as non-routable, and packet filters should drop them. They are **not for local use** either, which is why their Destination value is false. Using them in examples guarantees that a copied configuration never collides with someone's real network. - **Shared Address Space** (`100.64.0.0/10`, RFC 6598): for a service provider to number the links between a carrier-grade NAT and customer equipment. It behaves like private space for routing, valid and forwardable but not globally reachable, and RFC 6598 says such packets must not cross provider boundaries. It is deliberately **not** RFC 1918 space, so it cannot collide with whatever the customer uses inside. - **Private-Use** (the three RFC 1918 blocks): for enterprises' own networks, same booleans as shared space. Two blocks with identical booleans can therefore have different intended users; the booleans say how routers treat an address, the name says who may number with it. ## What is not in this registry 1. **Multicast**, `224.0.0.0/4` (224.0.0.0 to 239.255.255.255, RFC 1112), has its own IANA registry described by RFC 5771. Inside it, `224.0.0.0/24` is the Local Network Control Block, used for control traffic that is not forwarded off link, and `239.0.0.0/8` is administratively scoped. 2. **The 6to4 relay anycast prefix**, `192.88.99.0/24`, was listed by RFC 6890 but RFC 7526 deprecated it; IANA removed its booleans, and the prefix may be reassigned only by IETF Standards Action. 3. **Ordinary unicast space** is not listed at all. Space absent from both registries is ordinary unicast, allocated through the address registries for global use.
- Why does the registry mark 169.254.0.0/16 as valid destination but not forwardable?Link-local addresses are real, usable addresses on one link, so a datagram may legitimately be sent to one. RFC 3927 forbids routers from forwarding them, which is exactly what Forwardable = false records; Globally Reachable is false as a consequence.
- Which IPv4 block should you use for example addresses in documentation, and why not RFC 1918 space?Use `192.0.2.0/24`, `198.51.100.0/24` or `203.0.113.0/24` from RFC 5737. RFC 1918 space is live space that someone's network uses, so a copied example can clash with a real deployment. Documentation blocks are marked invalid as source and destination, so an example address can never be a real host.
saying these in an interview costs you the question
- Documentation ranges are fine to use as a lab's internal addressing.
- 100.64.0.0/10 is listed in the registry as RFC 1918 Private-Use space.
- Forwardable and globally reachable mean the same thing in the registry.
- Multicast 224.0.0.0/4 is one entry in the special-purpose registry.
- Anything in the special-purpose registry is dropped by every router.