More-specifics: the double-edged knife

A more-specific prefix is a longer BGP announcement for a slice of a larger block, such as a /24 taken from a /22. Networks prefer the longer match, so that slice can pull traffic your way even when a covering aggregate is still advertised. The same pattern can look like a hijack if origin, ROA, or filters do not line up, which is why length and authorization need careful planning.

How a more-specific prefix steers traffic

BGP installs the most specific matching route. Traffic for addresses inside your longer prefix follows that announcement instead of a shorter covering route elsewhere. You can use that behavior to bring a customer /24 home or to avoid a poor path for part of a block. An attacker can abuse the same rule if RPKI and route filters allow a false origin. Before you create a ROA, sketch the covering aggregate and the more-specific side by side and write the origin ASN on each. If those ASNs differ, validators and operators will expect a clear, consistent story on the wire.

When the length never reaches the global table

A valid ROA does not guarantee that other networks will install your route. Many providers still treat /24 as the minimum useful IPv4 length in the default-free zone, so a /25 may never appear widely even when it is RPKI-valid. IPv6 has similar practical ceilings; a /64 is rarely accepted as a global unicast route. Inside a private interconnect or a tight peering relationship, a longer prefix can still work. At the public edge, it can simply vanish. Confirm acceptance with several looking glasses before you build traffic engineering on an unusual length.

Checks before you announce

Set ROA maxLength so your planned more-specific prefix is allowed, but not so loose that arbitrary longer slices become valid under your name. Keep IRR origin AS data aligned with the ROA; drift between them costs hours in debugging. If the covering aggregate is one origin and the more-specific is another on purpose, document that, ROA both correctly, and avoid a covering maxLength so tight that the slice becomes invalid. Verify reachability from multiple looking glasses, not only from a neighbor that sees a private interconnect. If you do not need to steer traffic, announce the covering length alone. The plain aggregate is usually the safest default and the least likely to look like a hijack.