If there are folks who ignore the hop by hop options field then it makes the 
entire discussion about not supporting 
http://tools.ietf.org/html/draft-ietf-6man-exthdr-01 moot. Given this, it makes 
all the more sense to either proceed with this draft as it is or change it to 
define a standard format for all IPv6 extension headers that get defined in 
future (which is precisely what it did in its first version).

Cheers, Manav 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Joel M. Halpern
> Sent: Friday, February 04, 2011 8.41 AM
> To: Christopher Morrow
> Cc: [email protected]
> Subject: Re: Hop-by-Hop Extension Header processed in Slow Path?
> 
> Lets be a little careful here:
> 1) If we say "No Extension Headers for intermediate 
> processing", and "No 
> Hop By Hop Options", then we are saying that we do not want any 
> extensions intended to be processed in intermediate routers.  While I 
> personally like that, I want to make really sure that we 
> understand that 
> is what we are saying.
> 
> 2) I have been told that many large rotuers have a setting 
> that causes 
> them to ignore the hop by hop options field.  To the degree 
> that is both 
> true and turned on, then we need to allow for that in our think (both 
> positive and negative.)
> 
> Yours,
> Joel
> 
> On 2/3/2011 9:57 PM, Christopher Morrow wrote:
> > On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (Kam) 
> Lam<[email protected]>  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?
> >>
> >> 
> http://www.cisco.com/en/US/technologies/tk648/tk872/technologi
> es_white_paper0900aecd8054d37d.html
> >>
> >> If Yes, then we should not add support for more sub 
> options with HBH header.
> >
> > yes, see notes from me (in particular) about this from the last 2+
> > years... no more HBH header options pls... OR understand that these
> > may/will get dropped (probably the whole packet actually) at some
> > provider edges.
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email protected]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to