On Jan 18, 2014, at 23:19 , Frank Habicht <ge...@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 <n...@foobar.org> wrote:
>>> extension headers are a poor idea because it's troublesome to process them
>>> on cheap hardware.
>>
>> Have you found them to be more troublesome to process than IPv4 options
>> are/were?
>
> 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
