Experiences with IPv6 and Routing Efficiency

Jimmy Hess mysidia at gmail.com
Sun Jan 19 08:57:58 UTC 2014

On Sun, Jan 19, 2014 at 1:58 AM, <sthaug at nethelp.no> wrote:

>Some of the other claims (e.g. more secure because IPsec is always
>available) are simply wrong - there is plenty of IPv6 equipment that
>doesn't offer IPsec.

The claim of more secure would really be wrong, even if all IPv6 equipment
supported IPsec.

Aside from: Encrypting the transport between all the LAN hosts does not
assure security in general -----  not against common attacks.

Aside from:  Encrypting the transport between hosts on a LAN can mask
malicious activity from  Intrusion Detection Systems,  that would otherwise
capture packets between hosts,  and check against a signature database;
showing possible signs of compromise, or possible attempts to exploit a

The problem is; most users don't have any understanding of IPsec, AND it
requires manual configuration ----   IPv6 and IPsec standards don't provide
any method of automatic configuration interoperable between various hosts,
 AND  users are unlikely to take the steps to manually configure IPsec.


> So far, all indications are that the fixed header size means nothing,

in terms of speed, but the *extension* headers are a significant
> complication and source of problems.

I believe this is correct;      The important thing is that specific
 pre-defined bit positions in the header   correspond to specific items,
and therefore, as few bits as possible need to be inspected,  before the
decision is made -- which buffer to copy the packet into.

And....  the removal of some headers to extensions are more like  a minor
reduction in bandwidth overhead,  in exchange for a large amount of extra
work,  processing any packets that use the extension headers.

On the other hand; Given Moore's law,  and the much quicker rate that CPU
power is expanding at cost $X than network bandwidth -----  it could
actually make a great deal of sense though to take on the extra complexity
and sacrifice  router CPU efficiency,  in exchange,  for lower  header
 overhead sizes.

"Problems" are due to vendors with buggy implementations.

The extension headers add complexity., but it could still be a lot better
than the alternative -- larger total header size, resulting in  fewer bytes
of useful data payload per IP packet.

Fewer  bytes of payload per packet =  Fewer user databits per second that
can be sent over a link of a particular bitrate,  before the link is

> Steinar Haug, Nethelp consulting, sthaug at nethelp.no


More information about the NANOG mailing list