Subject: [conex] Fwd: Hop-by-Hop Extension Header processed in Slow Path?

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 04 Feb 2011 08:53:19 +0100

I recommend people to take a look at this thread going on on 6man.
It seems apparent from this thread that we either manage to code the 
conex info in some bits in the main IPv6 header or conex is out of luck.

-------- Mensaje original --------
Asunto: 	Hop-by-Hop Extension Header processed in Slow Path?
Fecha: 	Fri, 4 Feb 2011 06:39:51 +0530
De: 	Hing-Kam (Kam) Lam <[email-masked]>
Para: 	[email-masked]

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?

http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html

If Yes, then we should not add support for more sub options with HBH header.

Kam
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 04 Feb 2011 16:47:53 +0000

Marcelo,

As I have said before, there is one more option than everyone thinks 
there is. ConEx could be encoded within an existing v6 extension 
header (rather than a new one). This is much more feasible than the 
main v6 header, where there's v little flex.

Bob

At 07:53 04/02/2011, marcelo bagnulo braun wrote:
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design