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
>
>
> If there were no resolution to the insertion question vis a vis RFC 8200,
> then would it then suffice to recommend that ingress nodes should include
> some padding for these non-SR midpoints to play with (iff. the network has
> such midpoints), and otherwise abide by RFC 8200?
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
