Thank you all for your insightful responses (please keep them coming). On Sat, Jan 18, 2014 at 9:51 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:

It could (as a function of raw traffic).

What's the concern, unless we misunderstand?

Was just trying to get more info from large networks about whether how some of the things that make theoretical logical sense actually work out in practice that way e.g. whether fixed header size and the fewer headers required to decode to read an IPv6 packet (with respect to IPv4) really may provide some signifiant performance advantages. I do realise that question might be difficult to prove on a real network that runs dual stack. Since the existence of IPv4 on both control and data planes may have consequences that we don't immediately understand. -- Mukom Akong T. http://about.me/perfexcellence | twitter: @perfexcellent ------------------------------------------------------------------------------------------------------------------------------------------ “When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran -------------------------------------------------------------------------------------------------------------------------------------------

On Sun, Jan 19, 2014 at 1:58 AM, <sthaug@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 vulnerability. 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 congested. .

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

-- -Mysid