Follow topology and trust
05Aggregation works best when address delegation and network connectivity line up. Multihomed or moved customers need more-specific routes, and an accepted more-specific route can also divert traffic maliciously.
Separate security example: an unauthorized .192/26 has been accepted into the table and wins for .200 over a legitimate /25. Traffic is diverted. Route-policy validation/filtering is a separate control; CIDR itself does not prove authority.
Source for this drawing: RFC 4632 · Read RFC section 4.1 ↗
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.
A shorter routing table must not hide required paths; longest-prefix matching does not establish route authority.
- When a customer has multiple providers, all paths to that multihomed site must be explicitly advertised into the higher-level domain (§5.1 Rule 1; §4.1). It cannot simply disappear under one provider’s aggregate. Further aggregation may be possible when paths share a suitable upstream.
- A customer moving providers while keeping addresses out of its old provider’s allocation needs a more-specific route through the new provider (§4.1). That exception defeats some aggregation. Renumbering into the new provider’s block is encouraged, not an unconditional MUST to change addresses instantly.
- If the moved site’s more-specific route is absent, the old provider’s aggregate can attract traffic and discard it at a hole. Do not depict fallback to the old provider as proof of working reachability.
- §12 warns that more-specific routes can override aggregates and enable route hijacking. Longest-prefix matching can be mathematically correct while an accepted route is unauthorized. CIDR syntax supplies no cryptographic origin authentication.
- Filtering decisions should specify exact prefixes and masks (§5.3). Permitting exactly 192.0.2.0/24 differs from permitting its /25s or longer prefixes. §12 also discusses limiting received prefix counts; this guide invents neither a universal maximum prefix length nor a universal count limit.
Independent examples: legitimate dual attachment, provider move, missing exception and unauthorized route. Lines depict routes/traffic, not a full BGP exchange.
Read the RFC section ↗