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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
