Yes, I guess my concern is close to the second meaning.
It seems so simple. Currently annoucement of /24 seems to be okey, most upstream providers accept this.
However I wonder if there is any ground rule based on any standard or official recommandation.
If there is some standardized rule about prefix length to be annouced, I will make my bgp & IP allocation policy of
each data center of my company, and I will be able to more fairly and squarely speak to my customer like this
"You have to change your server's IP address if you want move your server to other place"
If you are allocated a /22, announce the /22. Do not announce anything longer unless you have a requirement to (such as a different origin AS). If you are further allocating a subset of that to a downstream, then a /24 out of that is acceptable as the origin will be different.
Even if a longer prefix like a /24 is announced, chances of people
accepting it is slim. Especially, as you say, if the RIR allocation
is something larger than /24
And I have a feeling acceptance /24 route announcements of anything
other than legacy classful space, infrastructure space like the root
servers is going to be patchy at best.
But if general rules did exist, they might say 1) not to announce smaller than a /24 to external parties without agreement, and 2) not to carve up registry assigned address blocks into individual announcements.
1 - You might announce your registry assigned block, AND deaggregated blocks to upstreams or peers for traffic engineering purposes, but you need to work closely with them to make sure that they don't filter the deaggs from your session, and also to make sure they don't onwardly announce the deaggs).
2 - The default free routing table is 270,000 entries large, and this is too big for lots of kit, so networks ARE FILTERING TODAY on registry boundaries. If you don't understand the implications of this do not deaggregate the addresses that the registry assign you.
Good luck with your project. Drop me a note offlist if you need specific advice.
If you are worried about /24s (and I really don't think you need to worry that much), just announce the covering CIDR somewhere and the few places that don't hear the /24 will send packets "at" the shorter prefix. Since routing is hop-based, as soon as the packet reaches an AS that hears the /24, the packet will be forwarded to the correct destination. I know from personal experience this works perfectly well today.
But in all seriousness, /24s are close to universally heard. Networks used to filter them, but by and large, they went away or changed their policy. Of course, there are hold-outs, but most corporations which own networks realize that the Internet is a tool to make money, not prove or disprove some random technical argument on NANOG. Listening to /24s make most networks money (either directly by giving them more traffic for which they charge their downstreams, or indirectly by having networks - like mine - stop using them if they don't), ... well, the rest is left as an exercise for the reader.
As for routing table size, no router which can handle 10s of Gbps is at all bothered by the size of the global table, so only edge devices or stub networks are in danger of needing to filter /24s. And both of those can (should?) have something called a "default route", making it completely irrelevant whether they hear the /24s anyway.
Even if a longer prefix like a /24 is announced, chances of people
accepting it is slim. Especially, as you say, if the RIR allocation
is something larger than /24
And I have a feeling acceptance /24 route announcements of anything
other than legacy classful space, infrastructure space like the root
servers is going to be patchy at best.
Even if a longer prefix like a /24 is announced, chances of people
accepting it is slim. Especially, as you say, if the RIR allocation
is something larger than /24
I think in practice that's over-stating the problem.
If an RIR assigns you a /22, the chances are good it has been assigned from some larger block which is also used to assign longer prefixes, down to whatever the RIR's minimum is (e.g. /24 under common critical infrastructure policies).
While it's possible to imagine someone re-parsing a full set of all RIR data every day and rolling out martian filters to all border routers based on precisely what assignments have been made, that someone would incur that operational cost in the face of what is a fairly slim benefit seems unlikely.
More likely that someone would filter based on the longest assignment made in a particular /8 (e.g. in 202/7, 199/8 we might expect to see /24s, in 76/8 not so much, etc).
Even more likely than that is that people might filter out obvious RFC3330-style martians and permit everything else up to a /24.
And I have a feeling acceptance /24 route announcements of anything
other than legacy classful space, infrastructure space like the root
servers is going to be patchy at best.
We're both speculating, of course.
It'd be nice if some grad student somewhere with friends in the operations community was to experiment with /24s carved out of larger blocks from all over the planet and present some empirical data.
More likely that someone would filter based on the longest assignment
made in a particular /8 (e.g. in 202/7, 199/8 we might expect to see /
24s, in 76/8 not so much, etc).
This matches my past experience, and it is often the case that an
entity is slow to revist specific /8s when RIR policies change...
[snip]
It'd be nice if some grad student somewhere with friends in the
operations community was to experiment with /24s carved out of larger
blocks from all over the planet and present some empirical data.
We do know that filters come and filters go, and the policies most
likely reflect who can afford what level of RIB storage across how
large a DFZ folks maintain within their own ASN. I wonder if like
hemlines, RIB storage capacity is an indirect economic indicator...
In lieu of detailed data reporting, being as conservative as you can
about contributing to the mess while being liberal as you can [fit
into your budget cycles] in receiving the mess is a long-honoured,
functional ops stance.
We don't need a student. We have actual networks doing this every day without any issue, so we know it works.
A research project could verify every last corner of the 'Net is accessible to /24s carved out of larger blocks, but the 'corners' tend to be more forgiving of things, it's the people in the "middle" who think they are too big or too important to listen to the little guys which cause problems. Little guys tend to not be so .. uh .. well, you can figure out what I mean.
I believe there was a project on reachability of /24s which were _not_ carved out of larger blocks, although I can't find it right now. That might be more interesting.
