Hi, > Please take a look at draft-herbert-6man-eh-attrib-00, I think it is > very much in line with what you're thinking. > > The basic idea is that we create a new "Attribution" Hop-by-Hop > option. The option serves two purposes: > > 1) If the source host sets the option in a packet then it is giving > permission to intermediate nodes to insert extensions headers (and > Hop-by-Hop options which need to be handled specially). Presumably, > when the source includes the option it is capable of dealing with ICMP > errors with inserted extension headers. > 2) The option indicates the extension headers (and Hop-by-Hop options) > that have been inserted by intermediate nodes. So it's modified by > intermediate nodes when insertion happens. The effect is that for any > given packet at any time it is clear which data is attributed to the > source node, and which is attributed to intermediate nodes. > > The option would also allow intermediate nodes to remove inserted > headers (ones attributed to intermediate nodes)
I haven't read the draft yet, but that sounds about right :) > Receiver handling of inserted headers needs to be considered. > > For making AH work, it would be straightforward simply not include any > inserted headers in the computation, the necessary information to do > that is in the HBH option. In this case, the option can't be ignored > so second high order bit of option type would need to be set. > > If AH isn't present, I believe the HBH option could safely be ignored > if unknown at the receiver. Other than AH, I don't see any other cases > where ignoring the HBH option and processing inserted options leads to > incorrect behavior (if there are possible cases please point them > out). I think both variants would have to be defined, one with the high order bit set and one with it unset. When AH is used then the one with the high order bit set has to be used, in other cases the sender can choose what is most appropriate for them (probably the other one). Sounds like a way forward! I think something like this HbH option would be required before SRv6 NP PSP can move forward. Cheers, Sander
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
