subnet prefix length > 64 breaks IPv6?

Wed Dec 28 15:57:12 UTC 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
made.

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
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111228/824d5984/attachment.sig>