Subject: Re: Hop-by-Hop Extension Header processed in Slow Path?

From: Ran Atkinson <[email-masked]>
Date: Fri, 4 Feb 2011 19:22:22 -0500

On Friday 4th February 2011, at 06:39:51 +0530, Hing-Kam Lam wrote:
> The below white paper from Cisco asserts that most vendors including
> Cisco process Hop-by-Hop extension headers in CPU (slow path). 
> Is this correct?

In general, it is not wise to trust any vendor X when they are
talking about some different vendor Y's products or implementations.   
Business pressures can impede clear and complete communications 
in that situation.  Of course, it is quite reasonable to trust 
vendor X when talking about their own products/implementations.

I know of vendors that have shipped (and customers have deployed) 
IPv6-capable routers with silicon (not necessarily an NP, think 
about Verilog/gates) that can process existing IPv6 hop-by-hop 
options in silicon (again, not necessarily an NP, think Verilog/gates).

It appears that the author of the document you mention 
might not be aware of those other implementations.

ANY (optional header or option) that has a **hop-by-hop behaviour**
clearly can be problematic in some very common circumstances
(e.g. transit routers within the global Internet that neither
ignore such options nor process such options at line-rate).  

RFC-5570 demonstrates that in some very unusual circumstances, 
an IPv6 Hop-by-Hop Header can be both useful and sensible to deploy.

Some network operators on this list have indicated that their
IPv6 routers at present simply drop packets containing hop-by-hop 
headers (and possibly some other optional headers).   There
are credible reports that in some other deployments, IPv6 routers 
are configured to *ignore* the presence of IPv6 Hop-by-Hop 
options when forwarding IPv6 packets.

The net result of this is that EVEN IF someone specified a
new (optional header or option) with hop-by-hop behaviour, 
THEN the actual real-world public Internet behaviour 
likely would be different than the option designer expected,
at least within "public" segments of the global Internet.

There is substantial evidence that the IESG already believes
that adding more options with hop-by-hop behaviour ought not
be allowed except in special, very limited, circumstances.
[RFC-5570, Page 1, "IESG Note"]

Yours,

Ran

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Sat, 5 Feb 2011 12:33:43 +0530

> vendor X when talking about their own products/implementations.

This article also includes Cisco's behavior for their products and
implementations.

Kam

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 5 Feb 2011 11:53:14 -0500

On 05  Feb 2011, at 02:03 , Hing-Kam (Kam) Lam wrote:
> This article also includes Cisco's behavior
> for their products and implementations.

Yes.  I read the article.  Thank you for posting the full URL.

I do not doubt the article's description of cisco products was
accurate -- as of the date it was written.  However, the article
says explicitly that it is over 4 years old (towards the top
of the web page):

	"Last updated: October 2006"

So the article does not claim to cover all of cisco's current
router products.  It only claims to cover their products as
of October 2006, which is over 4 years ago.

Please don't misunderstand.  The document you cited was
interesting, and having the full URL made it easy to find.
Unfortunately, it is a bit out of date by now, which limits
its value for this WG.

Separately, information from some other vendors contradicts the 
claims the Cisco page makes about other vendors' products and 
implementations.

Cheers,

Ran