[ppml] Longer prefixes burden the FIBs of DFZ routers

[Leo Bicknell]

In a message written on Mon, Aug 20, 2007 at 07:14:32PM +1000, Robin Whittle wrote:
> I didn't mention these, because I assume - perhaps wrongly - that
> these don't carry the burden of Internet traffic.  It is my
> impression that when an FIB in a router is handling a packet which
> matches a /32 prefix which is for that router's IP address, or some
> other router's IP address, that the packet is most likely to be a
> BGP message between the routers or some configuration, logging
> traffic etc.

I am rather sure this assumption is wrong, at least for IPv4.  I'm
not sure we have enough IPv6 experience to know if it is wrong for
IPv6 as well.

In IPv4 it would not be uncommon for an ISP to use a /32 "virtual
address" to hit a pile of load balancers for a Usenet farm, or a
VoIP switch farm, webmail front ends, or a streaming video farm.
Many people put their caching resolvers all on virtual IP's and
anycast them internally with BGP to provide more resiliency.

/32's are used in IPv4 because the hardware can handle it, and we're
all taught from birth to conserve space.  In IPv6 could those all
become /64's or /48's?  On most of the IPv6 networks I've seen today
people are at least playing with /128's for similar concepts, /126's
and /127's for P2P links, and /112's for small lans.  Will they
survive the "test stage", who knows.

But even if your assumption was right, it's wrong.  That is to say
if the only "expensive" operation was packets to my router loopbacks
for iBGP it might look ok to have those lookups take more time in
steady state.  However all it takes is an attacker finding those
addresses and DDoSing them with packets to make that not work.  If
the lookups are more expensive, the result is a much more attractive
attack target.

> If I was designing a router - which I am not - I would want to know
> what length prefix to optimise the performance for.  It would be no
> good saying "Sometimes the router needs to handle /128 so the router
> must be optimised to forward packets to /128 prefixes" when in
> reality, most of the traffic would be to /32 to /48.

I'm quite afraid this sounds like early IPv4 routers.  They did
Class A's, B's, and C's quite well, and some of them when you put
in other length prefixes fell over.  I suppose it looked like a
good trade off for the software and hardware of the day; and in
fact it might have been the right choice to get us where we are
today.  Those designs didn't last well though, and got fork lifted
out when a problem occurred.

> I think it would be a very good idea for the IETF and the RIRs to
> decide, very carefully on something exactly like this.  I think the
> IETF and the RIRs should be able to decide that under no
> circumstances would IPv6 address policy in the next decade or two
> require DFZ routers to look at any more than 48 bits of address for
> Internet traffic.

A very interesting idea.  I think a "decade or two" may be too long,
but given we are in the early phases it may be worth considering
your idea.  I'm afraid it would have to be a global policy to mean
something to the vendors, but perhaps a "under no circumstances
will RIR's require prefixes longer than /XX before 2015" might be
a way to reduce deployment costs.  Of course, the trap is that if
that assumption is built into hardware, and 2015 comes in a lean
time there will be great pressure to keep it for economic reasons...

From my own talking to vendor reps they are trying to may some hay
with the fact that IPv6 routes are quite sparse relative to the
address space.  In particular, even if you cut off at /112, there
are likely to be no routes in the /64-/112 space as currently
deployed.  Also, I believe the largest current allocation is a /21,
so it's probably unlikely to have a route < /18.  If we look just
at those ranges, we're down to a space of 54 bits that are likely
to be present in routes (18-64, 112-128).  54 bits is a lot more
tractable than 128, and fits well within the 72 bit TCAM space.

With a good method of hashing (in hardware) this could be done, and
leave a pretty good chance that prefixes of the "unlikely lengths"
would not cause significant problems until there were a lot of them.

I would love to have reps from Cisco and Juniper (Foundry, Extreme,
Force 10?) come to an ARIN meeting and give some information on how they
handle forwarding IPv6 packets, and if ideas like your prefix length
limit help them in a significant way or not.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070820/aab1de20/attachment.sig>