verio arrogance

Tue Jul 30 00:33:15 UTC 2002

> This is all great and wonderful, except for one thing - the RIR allocation
> boundaries were never really meant to be used as "official" filtering prefix
> length limits. I certainly support Verio's right to filter on whichever
> boundaries make business sense to them. However, there is no denying that
> they have long been on the conservative side of filtering, and that this has
> caused problems for their peer's customers. Their policy causes a certain
> amount of difficulty for smaller multihomers, who may not have a RIR
> allocation.

It only causes problems, under the majority of circumstances, when people
fail to announce their largest aggregate. If they announce their RIR provided
aggregates, then there is no problem. The RIRs provide lists of their
smallest allocation sizes, which facilitates locking into a certain expected
prefix-length. While it may not be "official", it is certainly a good
cross-pollination of data, which is probably why the RIRs send notifications
here when they change their allocation policies.

Everyone I've seen who bases their filters off of RIR allocation guidelines
does so slightly more loosely than the guidelines themselves.

IMHO, this is better than simply drawing a one-size-fits-all line in the
sand. If you permit /24 across the board, you may as well not filter, as
that is where the greatest amount of crap is (according to what I've seen).
If you permit /23 across the board, you'll filter out those folks living
in chunks where the RIRs have assigned /24s leading to blackholes of
the cluefull.

As such, some correspondence to RIR policy is advantageous in fine-tuning
the filtering to make sure you don't filter out legitimate folks for
which there is no greater aggregate, while filtering out those who
(un)intentionally abuse BGP. If the RIRs were to begin allocating space
from specially designated "multihomer" blocks, for such small multihomers,
I don't see that those who presently filter based upon RIR policy would have
a problem. Also, the small multihomer wouldn't have a problem, and the
present degree of dishonesty expressed to get "large PI blocks" would
hopefully subside. I believe RIPE is presently doing just this type of
thing. However, RIR policy is up to the RIRs.

The only drawback I've seen is the unfortunate case where a small multihomer
can be partitioned away when their connectivity to the provider who allocated
them some PA space goes away. However, there are means through which the
small multihomer may use to rectify that situation (which don't involve
dishonesty). RFC2260 is one such way. Again, if there were a range dedicated
purely to the small multihomer, the filters could be updated to account
for that policy, and there would be no issue even outside steady-state.

Between permitting small PI blocks to small multihomers, and slightly
looser than RIR guidelines for the remainder, there would be few innocent
victims, there would still be controls over folks attempting to use
BGP to offset their TE, and well the clueless would remain clueless, but
there's not much you can do about them.

> Currently, RIR's will issue an AS and will allow the issuance of a /24 to a
> multihomed enterprise, simply on the basis of being multihomed. From this
> point of view, it's easy to make the case that the proper "RIR-approved"
> boundary for prefix filtering should be at the /24 level. At any rate, Verio
> has been slowly liberalizing their filtering policy, and bring it into line
> with the rest of the industry.

If the RIR is issuing /24s, then they denote such on their minimum allocation
lists, allowing providers to accept /24s from such blocks.