Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

["Xiejingrong (Jingrong)" <[e-mail]>]

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:[e-mail]] On Behalf Of Bob Hinden
Sent: Wednesday, December 11, 2019 8:57 AM
To: Robert Raszuk <[e-mail]>
Cc: [e-mail]; [e-mail]; Bob Hinden <[e-mail]>
Subject: Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Robert,

> On Dec 10, 2019, at 2:05 PM, Robert Raszuk <[e-mail]> 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 <[e-mail]> wrote:
> Robert,
> 
> > On Dec 10, 2019, at 12:42 PM, Robert Raszuk <[e-mail]> 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
>