Home page logo
/

nanog logo nanog mailing list archives

Re: subnet prefix length > 64 breaks IPv6?
From: sthaug () nethelp no
Date: Wed, 28 Dec 2011 16:45:44 +0100 (CET)

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


  By Date           By Thread  

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