skip to content

Which IPv4 address blocks does RFC 1918 reserve for private networks, and why are they not routed on the public internet?

level: juniorimportance: must knowfreq 78%

answer

  1. three blocks, three sizes
  2. one /8, one /12, one /16
  3. the middle block's second octet
  4. no global meaning, so filtered at borders

basics

~10 s

RFC 1918 reserves 10.0.0.0/8, 172.16.0.0/12 (172.16.0.0 to 172.31.255.255) and 192.168.0.0/16. Anyone may reuse them without registration, so they are not unique, and routes and packets for them are kept off inter-network links.

solid answer

~40 s

RFC 1918 sets aside three IPv4 blocks: `10.0.0.0/8` (16,777,216 addresses), `172.16.0.0/12` (172.16.0.0 to 172.31.255.255, 1,048,576 addresses) and `192.168.0.0/16` (65,536 addresses). Any organisation may number hosts from them without asking a registry, which means thousands of networks reuse the same addresses and none of them is globally unique. Because an address with no global meaning cannot be routed globally, the RFC says routing information about private networks shall not be propagated on inter-enterprise links, packets with private source or destination addresses should not be forwarded across them, and providers are expected to filter such routes. A host with only a private address therefore needs a translator or an application-level proxy to reach the internet. `100.64.0.0/10` and `169.254.0.0/16` are reserved too, but they are not RFC 1918 space.

go deeper

for a junior

Recall the three blocks with their prefix lengths, and say plainly that the 172 block runs from 172.16 to 172.31. Interviewers often start with exactly that boundary.

for a middle

Explain why reusable addresses cannot be routed globally, what RFC 1918 tells border routers to do with private routes and packets, and why a private host needs a translator or proxy to reach outside.

for a senior

Show the operational edges: overlapping private plans after mergers or VPNs, code that equates reserved with private and misses 100.64.0.0/10, and why private addressing is not an access-control boundary.

for a principal

Frame the tradeoff an address plan makes: private space buys freedom from registries at the cost of global uniqueness, so plan prefixes per site and region early to keep future interconnection cheap.

## The three blocks **RFC 1918** (Best Current Practice, 1996) asked the address registry to reserve three blocks of IPv4 space for **private internets**: networks whose hosts do not need to be reachable by their own address from outside the organisation. | Block | Range | Prefix length | Addresses | RFC 1918's own name | |---|---|---|---|---| | `10.0.0.0/8` | 10.0.0.0 to 10.255.255.255 | /8 | 2^24 = 16,777,216 | 24-bit block | | `172.16.0.0/12` | 172.16.0.0 to 172.31.255.255 | /12 | 2^20 = 1,048,576 | 20-bit block | | `192.168.0.0/16` | 192.168.0.0 to 192.168.255.255 | /16 | 2^16 = 65,536 | 16-bit block | The RFC's names count the **host bits** left after the prefix, which is why the /8 is the "24-bit block". In pre-CIDR terms the first block is one class A network, the second is 16 contiguous class B networks and the third is 256 contiguous class C networks. ## Reading the /12 boundary The middle block is where answers go wrong, because /12 does not end on an octet boundary. Work it out from the bits: 1. A /12 fixes the whole first octet (8 bits) plus the top 4 bits of the second octet. 2. The second octet of 172.16.0.0 is 16, which is `0001 0000` in binary; the fixed top four bits are `0001`. 3. The free low four bits run from `0000` to `1111`, so the second octet runs from 16 (`0001 0000`) to 31 (`0001 1111`). 4. The block is therefore 172.16.0.0 to 172.31.255.255: sixteen /16s. So 172.20.14.3 and 172.31.0.10 are private, while 172.15.0.1 and 172.32.0.1 are ordinary public addresses that somebody else may hold. ## Why the blocks are not routed globally An organisation may use RFC 1918 space **without any coordination** with the registry. The price is that the addresses are unique only inside that organisation, or among organisations that agree to share a plan. A route to 10.1.0.0/16 means a different network in every company that uses it, so it cannot be advertised on the internet. RFC 1918 Section 3 spells out the consequences: - routing information about private networks **shall not** be propagated on inter-enterprise links; - packets with private **source or destination** addresses **should not** be forwarded across those links; - routers in networks not using private space, especially service providers', are expected to **reject** routing information about private networks, and such a rejection **shall not** be treated as a routing protocol error; - indirect references, such as DNS records pointing at private addresses, should be contained within the enterprise. The filtering works in both directions. A packet that leaks out with a private **source** address cannot be answered properly: the reply is addressed to a private destination with no global route, so it is dropped at the first filtering border or, worse, delivered into whichever network happens to use that prefix nearby. A private host can still talk to every host inside the organisation, public or private. To reach outside it needs a **mediating gateway**: the RFC names application-layer gateways, and in practice most networks translate the private source address to a public one on the way out. Translation is a separate subject; the point here is that the address itself never travels as a usable route beyond the border. ## What private space does not mean - **Not a security boundary.** A private address is unreachable from outside only while no route, tunnel or translation exposes it. Access control is a filtering decision, not a property of the block. - **Not every reserved block.** `100.64.0.0/10` is RFC 6598 **shared address space** for carrier-grade NAT, `169.254.0.0/16` is RFC 3927 **link-local**, `127.0.0.0/8` is loopback. None of them is RFC 1918 space, and code that treats "private" as "reserved" will misclassify them. - **Not collision-free.** Because everyone reuses the same blocks, two organisations that merge, or a laptop whose home network and VPN both use 192.168.1.0/24, can end up with overlapping prefixes. RFC 1918 Section 4 lists exactly this renumbering pain as a disadvantage. ## The registry view The IANA special-purpose registry (RFC 6890, updated by RFC 8190) lists each RFC 1918 block as **Private-Use**: valid as source and destination, **forwardable** by routers inside a network, but **not globally reachable**. That combination is the formal statement of the paragraph above: routers inside your network forward these addresses normally; nothing beyond your administrative domain should.

  • Is 172.32.0.1 a private IPv4 address under RFC 1918?
    No. `172.16.0.0/12` fixes the top four bits of the second octet to `0001`, so the block covers second-octet values 16 to 31 only. 172.32.0.1 has `0010 0000` there, which is outside the block: it is ordinary public space that may belong to someone, and a filter or route that assumes otherwise is wrong.
  • Two companies that both number from 10.0.0.0/8 merge their networks. Why is that painful, and what does RFC 1918 say about it?
    Each company chose its subnets independently, so the same prefixes now mean two different networks and cannot both be routed in one table. Either one side renumbers, or traffic between them has to be translated at the boundary. RFC 1918 Section 4 names this as the main cost of private space: moving hosts or joining networks forces address changes, DNS changes and configuration changes.
  • What should a service provider's router do when a customer advertises a route for 192.168.0.0/16?
    Reject it. RFC 1918 expects routers in networks not using private space, especially providers', to filter routing information about private networks, and states that the rejection shall not be treated as a routing protocol error. The session stays up; the route is simply not accepted or passed on.

saying these in an interview costs you the question

  • The middle private block is 172.16.0.0/16 only.
  • The private 172 range runs from 172.16 up to 172.32.
  • 169.254.0.0/16 is one of the RFC 1918 private blocks.
  • 100.64.0.0/10 is just another RFC 1918 private range.
  • Private addresses are secure because nobody outside can reach them.
  • You must register a private range with a registry before using it.