Excellent. Thanks for the insight. One comment - you did mention an "empty h-b-h header". I would not expect to see an empty one - right - only if I have options would I attach the extension header to carry them.
Spence >-----Original Message----- >From: Elwyn Davies [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 02, 2005 12:04 AM >To: John Spence >Cc: ipv6@ietf.org >Subject: Re: Question about the need for a "Router Alert >Option" (RFC 2711) within a Hop-By-Hop Option Extension Header >(RFC 2460) ... > >The router alert option has a rather more drastic effect than >simply having a h-b-h extension header. The intention of the >h-b-h header (as has been discussed recently in connection >with a proposed QoS related >option) is that h-b-h options should, by default, not need to >be diverted to the 'slow path' and there should be generally >no need to look at the rest of the packet. (see s2.0 of >RFC2711 and the words about processing order in s4 of RFC2460). > >The router alert option is intended to provide an override for >this by forcing the router to look more deeply into the packet >while putting minimal overhead into the h-b-h option >processing. The value in the option is intended to help >decide what should happen at the earliest moment in processing >in the router. > >So, for example, an empty h-b-h header *should* not divert the >packet from the fast path because there is no need to inspect >the rest of the packet - this of course depends on the router >implementation but that is the intention. The only other >example of a h-b-h option that is defined at the moment is the >jumbo packet option which carries the packet length when it >doesn't fit into 16 bits. This fits the bill because the >router needs to know how big the packet ought to be but >doesn't need to look at the rest of the packet.. effectively >it is just the packet length field in a different place. > >The main users of the router alert option are path-coupled >network layer signaling protocols which need to intercept >signaling messages at on-path middleboxes. RSVP is the >current example and the nsis transport protocol also uses >them. There has been discussion in nsis about what >router alert values should be used. The view is that it >would be good >if routers were able to discriminate on the router alert value >and only divert packets with 'interesting' (to that middlebox) >values, ignoring other values. This would allow middleboxes to >intercept just the signaling sub-protocols that are relevant >to their function and bypass any others (e.g., a QoS gateway >would generally not be interested in NAT signaling). It would >also minimize the effect of the DoS attack that has been >discussed on this thread. > >Hope this helps. > >Regards, >Elwyn > > > >John Spence wrote: > >> Hello; >> >> If the H-B-H extension header means "all intermediate nodes >must look >> in here for options to process", why is the "Router Alert" option >> needed? As I read the text of the two RFCs, the Router Alert Option >> is redundant - just including a H-B-H header means >"intermediate nodes >> must look at this packet even if it is not addressed to them", which >> seems to be the same meaning as Router Alert. >> >> I must be missing something. Can someone provide a quick >answer, or a >> pointer to the answer so I can research it myself? >> >> Thanks very much. >> >> John Spence >> >>-------------------------------------------------------------- >--------- >>- >> >>--------------------------------------------------------------- ----- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>--------------------------------------------------------------- ----- >> >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
