subnet prefix length > 64 breaks IPv6?
bicknell at ufp.org
Wed Dec 28 09:57:12 CST 2011
In a message written on Wed, Dec 28, 2011 at 10:19:54AM -0500, Ray Soucy wrote:
> 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.
> I expect that most hardware and software implementations store IPv6 as
> either a group of 4 32-bit integers or a pair of 64-bit integers, and
> a [ 7 or ] 8-bit prefix length field. I haven't read anything about a
> new 128-bit ASIC for IPv6, at least.
> In this context, it is perfectly reasonable, and expected, that the
> use of longer prefixes will have a higher cost.
The routers are already having to do a 128-bit lookup under the
hood. Consider you have a /48 routed in your IGP (to keep things
simple). When you look up the /48 in a router you will see it has
a next hop. A 128 bit next hop. This may be a link local, it may
be a global unicast (depending on your implementation). This next
hop has to be resolved, in the case of Ethernet as an example to a
48 bit MAC address.
So a typical forwarding step is already a two step process:
Look up variable length prefix to get next hop.
Look up 128 bit next hop to get forwarding information.
Once the vendor has built a 128-bit TCAM for step #2, there's no
reason not to use it for step #1 as well. AFAIK, in all recent products
this is how all vendors handle the problem (at a high level).
Sadly, this is all a case where mind share is hobbled by a few early
adopter problems. If you look at the first IPv6 images for platforms
like the Cisco 7500 (in the VIP-2 days) that hardware was built to
IPv4 criteria, and had 32 bit TCAM's. To make IPv6 work they did
multiple TCAM lookups, some the simple 32 bits x 4, others fancy
things trying to guess prefix lengths that might likley be used.
All took a substantial line rate hit moving IPv6 as a result.
Those problems simply don't exist in modern gear. Once products
were designed to support native IPv6 rational design decisions were
I don't know of any _current generation_ core router that has any
performance difference based on prefix length. That's why prefix length
isn't in the test criteria, it simply doesn't matter.
I say this as a proud user of /128's, /126's, and /112's in a
multi-vendor network, as well.
Leo Bicknell - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 826 bytes
Desc: not available
More information about the NANOG