Hi, > As we mentioned in the draft, only Jumbo-gram and MLd options apart > from the padding options can be inserted in Hop-By-Hop header.
I don't understand this statement. MLD is a subset of Router Alert, and various other HbH options are defined: 0x26 Quick-Start [RFC4782] 0x7 CALIPSO [RFC5570] 0x63 RPL [RFC-to-be draft-ietf-6man-rpl-option] 0x1e (etc.) Experimental [RFC4727] I don't think we can assert that none of these need to be processed at the source without analysis, which is of course impossible for the experimental values or for unknown future options. I also think that stating that Router Alert doesn't need to be processed at the source is dubious. If the source is acting as both a host and a router (e.g. in an Internet Connection Sharing scenario), you would be courageous to state that there is no case in which node in its role as a router should look at a Router Alert that it set in its role as a host. It seems reasonable to state that implementors MAY omit processing at the source, if and only if they know by construction that no HbH option that requires local processing is created elsewhere in the host stack. But even so, they need the code to skip over the HbH extension header if present. We cannot replace if HbH header present, skip to next header by No-op Regards Brian Carpenter -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
