In addition to this, what about cases where the end node does not know how to process an option given in the destination header - this could happen when some new destination option is being introduced and not all boxes are upgraded to understand that? The current proposal provides some extension flags that would help in such scenarios.
Kam On Thu, Nov 18, 2010 at 8:20 AM, james woodyatt <[email protected]> wrote: > On Nov 15, 2010, at 11:02, RJ Atkinson wrote: >> >> I do NOT support this draft, for one quite simple reason: >> >> ** The assumption of this draft is that there exists some IP option type >> that is NEITHER (a) hop-by-hop nor (b) end-to-end in nature. >> >> I have never heard of such an option, but if someone can provide a concrete >> example I'm eager to hear about it. > > My expired I-D.woodyatt-ald defines a new ICMPv6 message code for Listener > Notification packets. If this draft were passed, then I could revise it to > also define a Firewall Alert option, which would be neither hop-by-hop nor > destination-oriented, as firewalls are not necessarily either hosts or > routers. > > > -- > james woodyatt <[email protected]> > member of technical staff, communications engineering > > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
