> Other EH’s allow for different forms of modification, for example SRH allows for TLV modification, see Section 2.1.
Section 2.1 talks about segment endpoint and that is where IPv6 outer header destination address matches the node address doing the modification. If you stating that it can be modified by any via node - that's pretty cool. Regarding Hop-by-Hop - of course. For Destination Options to allow to define fields which can be modified by non outer IPv6 destination network elements - good to know. Thx, R. On Tue, Dec 10, 2019 at 10:45 PM Bob Hinden <bob.hin...@gmail.com> wrote: > Robert, > > > On Dec 10, 2019, at 12:42 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > > > > > The issue is that RFC8200 forbids even modification to any EH unless the > node is a destination node in top most IPv6 header. > > I don’t think that is true. The options in the Hop-by-Hop Options header > and the Destination Options Header allow the definition of options that > support modifications. See Section 4.2, specifically: > > The third-highest-order bit of the Option Type specifies whether or > not the Option Data of that option can change en route to the > packet's final destination. When an Authentication header is present > in the packet, for any option whose data may change en route, its > entire Option Data field must be treated as zero-valued octets when > computing or verifying the packet's authenticating value. > > 0 - Option Data does not change en route > 1 - Option Data may change en route > > Other EH’s allow for different forms of modification, for example SRH > allows for TLV modification, see Section 2.1. > > Bob > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
