Re: Experiences with IPv6 and Routing Efficiency

[Owen DeLong <owen () delong com>]

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.
> >
> > 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