Home page logo

nanog logo nanog mailing list archives

Re: subnet prefix length > 64 breaks IPv6?
From: Alexandru Petrescu <alexandru.petrescu () gmail com>
Date: Thu, 29 Dec 2011 15:55:40 +0100

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

My point here is that IPv6 is still defined as "longest prefix

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


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]