subnet prefix length > 64 breaks IPv6?

Ray Soucy rps at
Wed Dec 28 15:19:54 UTC 2011

It's fairly common knowledge that most of our systems work on 64-bit
at best (and more commonly 32-bit still).

If every route is nicely split at the 64-bit boundary, then it saves a
step in matching the prefix.  Admittedly a very inexpensive step.

I expect that most hardware and software implementations store IPv6 as
either a group of 4 32-bit integers or a pair of 64-bit integers, and
a [ 7 or ] 8-bit prefix length field.  I haven't read anything about a
new 128-bit ASIC for IPv6, at least.

In this context, it is perfectly reasonable, and expected, that the
use of longer prefixes will have a higher cost.

However, I think the number of routes, and your network architecture
play a significant factor.

It is a fairly standard practice to have different routes for your WAN
connections (e.g. the routers you use BGP on and need to support
thousands of routes) than the routers you use internally, where the
routing table can be considerably smaller (and for which you can
summarize).  For these routers, the cost of routing is generally a
non-factor as the tables are much smaller.

I think a greater concern than simple routing and forwarding, would be
additional services, such as queuing, or filtering.  These may be
implemented in hardware when a 64-bit boundary is used, but punted to
CPU otherwise.  Though this would be implementation specific and is
something you would want to research for whatever hardware you're

So far, the biggest performance problem I've encountered is related to
neighbor discovery.  It seems that in most implementations the
neighbor discovery process is implemented in software.  It doesn't
have much to do with the boundary, but rather just that the process
(e.g. solicitation for unknown entries) is expensive enough that
sweeping through available address space can easily use all available
CPU capacity.

One [somewhat effective] solution to this is to attempt to use longer
prefixes so there is much less address space where such an attack
would be valid.  It is much less costly for a router to discard a
packet that it has no route for than it is to issue thousands of
neighbor discovery solicitations per second.

There are a few solutions that vendors will hopefully look into.  One
being to implement neighbor discovery in hardware (at which point
table exhaustion also becomes a legitimate concern, so the logic
should be such that known associations are not discarded in favor of
unknown associations).

I do think, despite these limitations, that hardware is quickly
catching up to IPv6, though.  I don't think it will be long before we
see the major vendors have solid implementations.  Some of them
already may; I haven't had a chance to play with the newest stuff out

On Wed, Dec 28, 2011 at 9:50 AM,  <sthaug at> wrote:
>> > Can you please name names for the "somewhat less efficient" part? I've
>> > seen this and similar claims several times, but the lack of specific
>> > information is rather astounding.
>> Well, I do know if you look at the specs for most newer L3 switches,
>> they will often say something like "max IPv4 routes 8192, max IPv6
>> routes 4096". This leads one to believe that the TCAMs/hash tables are
>> only using 64 bits for IPv6 forwarding, and therefores longer prefixes
>> must be handled in software.
> It might lead you to believe so - however, I believe this would be
> commercial suicide for hardware forwarding boxes because they would no
> longer be able to handle IPv6 at line rate for prefixes needing more
> than 64 bit lookups. It would also be an easy way to DoS such boxes...
>> This may very well not be true "under the hood" at all, but the fact
>> that vendors publish so little IPv6 specification and benchmarking
>> information doesn't help matters.
> Cisco actually has published quite a bit of info, e.g.
> "Delivering scalable forwarding Performance: up to 400 Mpps IPv4 and
> 200 Mpps IPv6 with dCEF"
> They have also published EANTC tests which include IPv6 forwarding rates.
> Steinar Haug, Nethelp consulting, sthaug at

Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System

More information about the NANOG mailing list