[147948] in North American Network Operators' Group
Re: subnet prefix length > 64 breaks IPv6?
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Dec 28 10:58:09 2011
Date: Wed, 28 Dec 2011 07:57:12 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <CALFTrnOHam-s-9699nFr_K6M5oOYMgoMJpQv+Ai-QFju2PC4qA@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Y7xTucakfITjPcLV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Wed, Dec 28, 2011 at 10:19:54AM -0500, Ray Soucy wr=
ote:
> 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.
>=20
> 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.
>=20
> 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=20
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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--Y7xTucakfITjPcLV
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBTvs8WLN3O8aJIdTMAQIhPg//ZNAOY6txiZo8si5zbyMA1baksT+dUEx0
NE3pjt0XsG/OatS2MIMzfpTFSXwz/OMZ4Lj32+pwc1Ql4ozpCqcIemo/ZeC2b9eJ
7K4B18M3tuNYCOi6iwg7tbOBp9D2TItiUwOBAQRR6NJGmFvlAR6yoLbMbZ8g2JSv
pgCd3mYCamwTajAyLGHN+4VrSfrSwSgpqJh6DAGGoG+MKeqToUlFJnkQMrObt2Uq
XjmEmmpXA8+oGmQjCypmeKksto5/c+rqAru8ma25FK+verH4XamgXO5JIZKU5IJs
XqijIL7dpB4gsLt/dNueHvJmfPF4ySBNKeNGUoBzK2AehRXD7s/gDR2r/E1/0mZY
qKDaB9uCp9NXQGvMYFD+gfxcPiHBInWl4/NVge75a+uLDkpKIhnzMwFZ9EYsthXK
X804liUAraB6qhS6f3ybRQY/OJVZusSrSkzBf1W8sB03XZ0aBL0Hod4FL7jBtiWQ
chOwTk/kk2tJ3vv4PyIjQQNutk+fd2izXzP4BAOcjKKafV6D7Y2GFL+M15ijsifX
gn8/JqBiYX8ntq7/0vhYGKi2f2rx9oyMKzrfF/Wivf3uutitKlsX5yi+wl1T/gcv
fDVeij69bNnRb7bs+n03H2fdEjlZd3vmypfFUezpkJUt/EPSIRVchRU3+Ba0Ye+0
vsUwRvG6V4I=
=+ITW
-----END PGP SIGNATURE-----
--Y7xTucakfITjPcLV--
