Plan for reuse and renumbering
04Two independent enterprises may both use the same private address. Combining their networks can turn valid local names for hosts into an ambiguous destination.
B’s host, DNS entry and a peer’s stored destination all change to 10.30.0.8; updating one field alone is not a complete migration.
Source for this drawing: RFC 1918 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Local uniqueness does not survive a merger automatically.
- Using addresses from within the reserved pool needs no IANA or registry coordination. Addresses must still be unambiguous within one enterprise or a cooperating private internet.
- If independently numbered private networks merge, overlapping addresses can require renumbering. Random selection of internal sub-blocks is strongly recommended in §5 to reduce risk; it does not guarantee no collisions.
- Renumbering changes relevant addresses, DNS entries and configurations on other hosts that reference those addresses (§3). Tools such as DHCP can mitigate work, but do not guarantee that every hard-coded reference is updated.
A and B are fictional administrative scopes. Both initially have 10.20.0.8; after a chosen renumbering B uses 10.30.0.8 from a coordinated, non-overlapping sub-block. This is one addressing-plan example, not an automatic renumbering protocol or a guarantee that 10.30/16 is free in a real network. Changing private/public connectivity can also require renumbering.
Read the RFC section ↗