Filtering prefixes longer than /24

[Pekka Savola]

On Tue, 10 Jul 2001 itojun@iijlab.net wrote:

> >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.
>
> 	two comments:
> 	- core routers need to carry both IPv4 full routing table and IPv6
> 	  full routing table, until we phase out IPv4.
> 	  (or you need to babysit separate routers, separate fibers...)
> 	- routing table in IPv6 will eat 4 times more memory than IPv4
> 	  if the # of entries is the same.
> 	so I believe it is not a "non-issue" (or it is safer to think that way).

You're right; it's not a complete non-issue, but I feel it's very safe to
assume that at least 10,000 routes can be handled just fine.  Building
IPv6 routing archtitecture on the fact that aggregation is very aggressive
and DFZ has only e.g. less than 500 routes or the like would probably lead
to some sort of CIDR disaster.

> 	does anyone have performance measurement/whatever with big big big
> 	IPv6 routing table installed onto a router?  what is the routing table
> 	size vendors use for toture-test?

This would be interesting to know.

>From Dorian's mail:
> All good and valid points. Furthermore, real concern regarding routing
> table size now, as was in mid 90s isn't so much to do with handling the
> memory requirements related to prefix table, but rather scaling the
> computational power necessary to do path computation in an Internet
> whose path diverity is increasing rapidly along with prefix table size.

Calculating these once doesn't appear to be a big problem, and the
effect of more consistent changes are reduced by flap dampening.

> >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.
>
> 	we can *potentially* have a lot of routes if you advertise /48 to
> 	worldwide.  compare 2^(48-16) and 2^(24-8).

Well, you can get a lot of routes if you advertise every address as it's
own route; this is what I feel is the equivalent in ipv4 world of of
advertising /48's.

Current multihoming mechanisms deal with one site.  You cannot use these
to multihome a (non-pTLA) ISP the address space of which is allocated to a
dozen sites.  Only thing you could do, I suppose, is getting your pTLA and
some foreign pTLA do some peering (doesn't work in the real world) to
protect against your physical link to pTLA ISP failing.

On the other hand, currently:

 - 6bone MUST: ~2^(28-16) = 2^12
 - 6bone idea: 2^(32-16) = 2^16
 - IPv6 RIR (effective): 2^(25-16) = 2^9
 - IPv6 RIR (theoretical): 2^(32-16) = 2^16

In addition, the allocations are not as dense as in IPv4.

-- 
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