Contain routes and private packets
03Private addresses have no global meaning. Border policy must distinguish ordinary internal routing from exporting a private route or forwarding a private-addressed packet outside.
The enterprise does not install a received outside route for its private prefix; rejection is not a routing-protocol error.
Source for this drawing: RFC 1918 · Read RFC section 3 ↗
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.
Apply filters; the address prefix is not an automatic security barrier.
- RFC 1918 says private routing information “shall not” propagate on inter-enterprise links, and packets with private source or destination addresses “should not” be forwarded across them (§3).
- Routers not using private space, especially providers, are expected to reject private route advertisements. Rejecting such an advertisement shall not be treated as a routing-protocol error.
- Section 5 strongly recommends suitable packet and routing filters at both link ends, including inbound private-route filtering to avoid routes to your own private space pointing outside.
Separate cases share a configured boundary filter: an internal packet, an attempted route export, private-source and private-destination packets, and an inbound route advertisement. Arrows stop at the filter for rejected cases. The coordinated encapsulation exception appears later. Filtering here is configured behavior, not encryption or proof that a private host is trustworthy.
Read the RFC section ↗