Re: subnet prefix length > 64 breaks IPv6?

[Alexandru Petrescu <alexandru.petrescu () gmail com>]

Le 28/12/2011 16:45, sthaug () nethelp no a écrit :
> > 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",

:-) yes agree, except that it's not known what "longest prefix match" is
precisely.  It is widely implemented in often closed source code, there
is books about it and lectures to first-year students.  I have heard it
named "crown jewels" of some companies.  High value and no specification
== speculation.

Alex

> 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