[168334] in North American Network Operators' Group
Re: Experiences with IPv6 and Routing Efficiency
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Jan 21 04:17:41 2014
From: Owen DeLong <owen@delong.com>
In-Reply-To: <52DB7C79.1020808@geier.ne.tz>
Date: Tue, 21 Jan 2014 01:13:15 -0800
To: Frank Habicht <geier@geier.ne.tz>
Cc: "<nanog@nanog.org>" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 18, 2014, at 23:19 , Frank Habicht <geier@geier.ne.tz> wrote:
> On 1/19/2014 7:00 AM, Mukom Akong T. wrote:
>> On Sat, Jan 18, 2014 at 4:22 PM, Nick Hilliard <nick@foobar.org> =
wrote:
>>> extension headers are a poor idea because it's troublesome to =
process them
>>> on cheap hardware.
>>=20
>> Have you found them to be more troublesome to process than IPv4 =
options
>> are/were?
>=20
> at what position in the packet is the tcp port?
> a) in v4
Depends on the IPv4 options.
> b) in v6
Assuming (based on (c) below), that this means in v6 without extension =
headers, then it will be at n+40 octets into the packet where n is the =
position of the desired port number (where desired is one of {source, =
destination} within the TCP header. Most of the (cheap) hardware that =
processes IPv4 punts packets with options to the slow path. In general, =
it depends on the IPv4 packet not containing options.
> c) v6 with a few extension headers
In this case, it will be at 40+o+n octets into the packet where o is the =
number of octets contained in headers prior to the TCP header and n is =
defined as in (b) above.
> now program a chip to filter based on this port number...
I think you might want to be more specific. After all, an ARM 9 is a =
chip which can easily be programmed to do so (in fact, I can point to =
iptables/ip6tables as running code which does this on the ARM 9).
So... I suppose that whether your complaint has merit depends entirely =
on whether or not extension headers become more common on IPv6 packets =
than options have become on IPv4 packets or not and also on how hard it =
is to build fast-path hardware that bypasses extension headers that it =
does not care about. Since you only need to parse the first two fields =
of each extension header (Next Header Type and Header Length) to know =
everything you need to bypass the current header, it shouldn't be too =
hard to code that into a chip...
Owen
