Thanks Bob for sharing your opinion. I fully agree with that, and I either don’t have any problem if an intermediate node decides to parse extension headers and modified one based on the definition of the specific EH.
Regards, Jingrong -----Original Message----- From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Bob Hinden Sent: Wednesday, December 11, 2019 8:57 AM To: Robert Raszuk <rob...@raszuk.net> Cc: spring@ietf.org; 6...@ietf.org; Bob Hinden <bob.hin...@gmail.com> Subject: Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function) Robert, > On Dec 10, 2019, at 2:05 PM, Robert Raszuk <rob...@raszuk.net> wrote: > > > > 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. I think it is clear that the intent is that destination options are only modified by the destination, that’s how destination options, routing header, etc., etc. work. The Hop-by-Hop option extension header can be modified by any node as defined by a specific option. > If you stating that it can be modified by any via node - that's pretty cool. > > Regarding Hop-by-Hop - of course. The same option format is used for destination and hop-by-hop option extension headers. The option text definition about changing en route doesn’t make any distinction between destination and hop-by-hop options. Personally, I don’t have a big problem if an intermediate node decides to parse extension headers and modified one based on the definition of the specific EH. I am not sure why that is very useful, but I don’t think it would break anything. Unlike inserting or deleting. Bob > 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
