In IPv4 routing, one network advertises 192.168.16.0/20 and another advertises 192.168.17.0/24; where does traffic to 192.168.17.100 go, and when is that legitimate?
answer
- length beats everything else
- a hole punched in a summary
- multihomed and moved sites
- the same rule, used by an attacker
basics
~20 sTraffic to 192.168.17.100 goes to whoever advertises the /24, wherever that route is accepted, because routers forward on the longest matching prefix. That is legitimate for multihoming, moved sites and traffic engineering, and a hijack when someone else announces it.
solid answer
~40 sIPv4 routers must use the most specific matching route (RFC 1812), and RFC 4632 makes longest match the first rule of CIDR. `192.168.17.100` matches both, so the `/24` wins in every router holding it; the `/20` still carries the rest of `192.168.16.0` to `192.168.31.255`. Route preference and metrics only break ties between routes of the same length. Legitimate uses: a multihomed site announced explicitly by each provider, a site that changed provider without renumbering punching a hole in the old aggregate, and traffic engineering with more-specific halves under a covering summary. RFC 4632's own security section uses this very pair as the hijack example: an attacker's /24 diverts the host's traffic, which border filters and prefix-length limits exist to stop.
go deeper
Recall the rule: the longest matching prefix wins, so a /24 inside a /20 takes the traffic for its own addresses only.
Work the table: which destinations use the /24, which fall to the /20, which match neither, and why metrics never compare a /20 with a /24.
Use more-specifics deliberately for multihoming and traffic engineering, explain the hijack in the same terms, and say which defences sit in filters versus in the address arithmetic.
Weigh how much you deaggregate for traffic control against the global table cost and the exposure a summary-only announcement leaves to more-specific hijacks.
## The rule: longest match, not best summary When a router holds several routes matching a destination, it must use the most specific one, the route with the **longest matching prefix**. RFC 1812 requires this of every IPv4 router, and RFC 4632 makes it the first rule of CIDR route advertisement. The route's age, its origin and whether it is a summary do not enter into it. Preference between route sources, and each protocol's metrics and attributes, only choose among routes for the **same** prefix; a /20 and a /24 are different destinations as far as that choice is concerned. With `192.168.16.0/20` and `192.168.17.0/24` both installed: | Destination | Matches | Route used | Why | |---|---|---|---| | 192.168.17.100 | /20 and /24 | /24 | 24 matching bits beat 20 | | 192.168.31.200 | /20 only | /20 | the /24 covers only third octet 17 | | 192.168.32.1 | neither | default, if any | the /20 ends at 192.168.31.255 | The /20 has 12 host bits, 2^12 = 4,096 addresses, `192.168.16.0` to `192.168.31.255`; the /24 sits inside it. Traffic to `192.168.17.100` goes wherever the /24 points, in every router that has accepted the /24, and falls back to the /20 the moment the /24 disappears. ## Legitimate uses A more-specific inside someone's summary is normal, and CIDR depends on it: - **Multihoming.** RFC 4632 requires a site reachable through two providers to be announced explicitly by each. If its primary provider carried it only inside an aggregate while the other announced it on its own, longest match would send all its traffic to the other. - **Changing provider without renumbering.** The new provider announces the site's block on its own; it is a longer match than the old provider's aggregate, so it "punches a hole" in it. RFC 4632 recommends such a site eventually renumber into its new provider's space. - **Traffic engineering.** A network announces its `192.168.16.0/20` on two links, plus `192.168.16.0/21` on one and `192.168.24.0/21` on the other. Each half arrives over its own link; if a link fails, its /21 vanishes and that half falls back to the /20 on the surviving link. - **Layered summaries.** A summary backed by a discard route, with more-specifics only where detail matters, is the standard shape of an aggregated network. ## The hijack: the same rule, used against you RFC 4632's security considerations use this very pair. A popular host at `192.168.17.100` sits behind a provider that announces `192.168.16.0/20`. A malicious operator announces `192.168.17.0/24`. Because forwarding prefers the longer match, every router that accepts the /24 sends the host's traffic to the attacker, however legitimate and long-standing the /20 is. RFC 4632 notes that CIDR made hijacking somewhat worse: before it, a false route that exactly matched a network number won only in some parts of the network, while a more-specific is preferred by all traffic that sees it. What the owner and its neighbours can do: 1. **Filter at borders.** Accept from each neighbour only the prefixes it is entitled to announce; the policy tooling for this belongs to the routing protocol. 2. **Bound prefix length.** RFC 4632 notes many providers reject prefixes longer than registry allocation sizes; in practice IPv4 announcements longer than /24 are widely dropped, an operational convention rather than a protocol rule. 3. **Counter-announce.** The owner can announce the same /24, which turns the contest into ordinary route selection between equal prefixes; a /25 to outbid it is usually filtered by the convention above. 4. **Validate origins** cryptographically, which is a routing-security subject rather than arithmetic. ## Common misreadings - **"The summary was there first."** The order in which routes were learned plays no part in the lookup. - **"The /20 has the better metric."** Metrics compare routes for one prefix, never a /20 against a /24. - **"The more-specific replaced the summary."** Both stay installed, and each serves only the addresses it alone matches best. - **"Withdrawing the /24 stops the traffic."** It moves back to the /20 and whoever announces it. ## Reading a table of nested routes Nested prefixes behave like a tree: each route owns the addresses its more-specific children do not claim. When a child disappears, its addresses fall back to the parent, not to nothing. That is why withdrawing a more-specific moves traffic instead of stopping it, why a hijack ends the moment the bogus route is withdrawn, and why the originator of a summary needs a discard route for the addresses no child covers.
- If a router learns the /20 with a better metric than the /24, which one does it use for 192.168.17.100?Still the `/24`. Metrics, protocol attributes and the preference between route sources only compare routes for the same prefix. A `/20` and a `/24` are different entries, and the forwarding lookup takes the longest match among everything installed. A better metric on the /20 matters only for addresses the /24 does not cover.
- Why can't the owner of a hijacked /24 simply announce two /25s to win it back?Longest match would favour the /25s wherever they are accepted, but many networks drop IPv4 announcements longer than /24, an operational convention rather than a protocol rule. So the /25s often never propagate. The owner can announce the same /24, which turns the contest into ordinary route selection, while border filters and origin validation remove the bogus route.
A sorting office has a rule sending everything for district 16 to 31 to van A, and a rule sending everything for street 17 to van B. Clerks always apply the most specific rule that fits the address, whoever wrote it and whenever, so street 17's post rides van B. Remove that rule and the post quietly rejoins van A.
saying these in an interview costs you the question
- The summary wins because it was learned first or has a better metric.
- Routers compare route-source preference before they compare prefix length.
- A more-specific route inside a summary causes the summary to be withdrawn.
- A hijack only works if the attacker's path is shorter than the owner's.
- Withdrawing a more-specific makes its addresses unreachable.