so unless you *know* that all prefixes are<= 64 bits, you still need
the longer match.
In this context, it is perfectly reasonable, and expected, that
the use of longer prefixes will have a higher cost.
In a way I agree with you. However, if I put my purchasing hat on, I
would refuse to buy equipment that could only forward on the first
64 bits, *or* where the forwarding decision was much slower (hardware
vs software) for prefixes longer than 64 bits. I would not be
surprised if vendors decide that it is a *commercial* necessity to
support full 128 bit matches.
However, I think the number of routes, and your network
architecture play a significant factor.
Absolutely. In our network by far the largest number of IPv6
prefixes are EBGP prefixes in the 32 to 48 bit range. However, we
also have for instance our own 128 bit loopbacks - they are obviously
only in our IGP.
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 running.
Again, that would be an excellent reason *not* to buy such
And yes, we know equipment that cannot *filter* on full IPv6 + port
number headers exists (e.g. Cisco 6500/7600 with 144 bit TCAMs) - my
original point was that I still haven't seen equipment with
forwarding problems for prefixes> 64 bits.
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'm afraid I don't believe this is going to happen unless neighbor
discovery based attacks become a serious problem. And even then it
would take a long time.
Steinar Haug, Nethelp consulting, sthaug () nethelp no