[ppml] Longer prefixes burden the FIBs of DFZ routers

Leo Bicknell bicknell at ufp.org
Sun Aug 19 23:33:11 EDT 2007

One item I see missing from your post is the effect of "internal
prefixes".  Most ISP's carry a number of shorter prefixes in their
IGP (or in iBGP), which of course has to be pushed down into the
forwarding engines of the routers.

In the IPv4 world we have /32's for loopbacks, /24-/29's for "critical
infrastructure", nameservers, management servers, and the like.  In
some cases /30 or /31's may be carried throughout some of the network
depending on how it's broken up internally.

Most IPv6 networks have some similar situations.  It may be /64's
for critical infrastructure, /128's for loopbacks, and the like.

It would be possible to assign /48's minimum everywhere to make
this work, but if a company has a 1000 routers (as a very large ISP
might), that would require them to use another 10 bits for router
loopbacks alone, meaning we've assigned a /38 just out of loopbacks.
If you're getting a /32 that's 1/64th of the space they received
just for loopback addresses.

The way I boil down what you're saying is that "more bits of address
space require more expensive hardware".  That's surely true.  We
also have a nice history of manufacturers getting caught on the
wrong end of an assumption, vendors in the past who had lookups or
cache's built around sizes that did not end up matching real world

We're also early in IPv6's life.  While we can't make it too expensive
to deploy, we have to keep in mind the technology to foward it is
going to get cheaper and cheaper over time.  I can only imagine the
discussions back in 1986-1988 over how you forward a /32 bit address
space when 32 bit CPU's were brand new, memory cost a fortune, etc.

At the end of the day, the thing I worry about most is locking into
particular sizes.  If the vendors are told by the IETF, the RIR's,
and/or their customers "we only assign /48's, lookups longer than
that can be "expensive" and some event happens in the future to
change that assumption the results can be deadly.

       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/20070819/7966f4c2/attachment-0001.sig>

More information about the ARIN-PPML mailing list