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