Re: subnet prefix length > 64 breaks IPv6?

[sthaug () nethelp no]

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

My point here is that IPv6 is still defined as "longest prefix match",
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 equipment.

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