Filtering prefixes longer than /24

[Pekka Savola]

On Mon, 9 Jul 2001, Robert J. Rockell wrote:
> If this makes multi-homing difficult, or the like; that is sort of the
> point. This is all supposed to be aggregatable at the most fundamental
> levels, thus putting a top limit on the number of non-customer routes a TLA
> will have to carry. Violating this just adds factors of 2 to the routing
> table size, in theoretical limit.  I agree there is problems, specifically
> in multi-homing.  The goal was to fix the problems with multi-homing, and
> this was a good way to bring the problems out.  IMHO, I don't want to fix
> the symptoms.

This might lead to a trend where organizations not really needing pTLA
assignment apply for one, instead of getting a fragment from an existing
pTLA -- if this is the only way to avoid multihoming considerations.  I'm
not sure about the multihoming status, but I don't think it's really
scales up to 6bone /32's and the like, connecting dozens of sites which
would also need to multihome or renumber -- the maximum unit is a /48 site
at most I think.

Ie. this probably leads to an increase of pTLA or equivalent
"non-filtered" organizations which may not be good from the aggregation
point of view either.

The scaling of IPv6 wrt. routing table size is IMO a big non-issue; a
remnant from the '95 when people started to get worried about the growth
of DFZ.

Nowadays 100,000 routes is no big deal.  Any "core" router which should be
able to get full internet table can deal with this without problems.  You
shouldn't be participating with your old 4500 Cisco with 16 MB of memory.
Thus, I don't see what's the point of trying to minimize the size with all
costs.

Currently, the effectively changing IPv6 prefix size is smaller than with
IPv4, and the population of it going to be sparser.  Also remember a big
problem of current IPv4 routing table size are small advertisements,
like /24 and /23 -- with IPv6 these are all within one /48, and are thus
automatically very effectively aggregated.


What's more worrying is complete fragmentation wrt. RIR allocations.
Suppose all dial-up's and DSL's etc. are all given /48 as IESG requires.
In effect, this requires RIR's take back (or assign new ones) all the
current /35 allocations, and use a much sparser mode, like:

really huge ISP's: /16
basic block for an ISP participating in DFZ: /24
smaller ISP: /32
small ISP: /40
site: /48

Without this, the current scheme is bound for disaster, and not because of
someone is filtering a little longer than /24 when /24 is a basic
allocation.

> If you are announcing
> pTLA A's /32 to pTLA B, and this caused a problem when you moved, then you
> have violated rfc2772 already.

This is the case, but I fail to see the big problem with this.

In a "perfect world", organizations in this situation would renumber, use
multihoming or whatever; in real world both are diffcult and the problem
is avoided by getting a pTLA on your own.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords