Well I take it as a joke ... as I am sure you are aware that SRH already contains those verbatim.
PS. Note that SRm6 would require a local mapping database to decipher those in CRH. On Tue, Dec 10, 2019 at 10:02 PM Mark Smith <markzzzsm...@gmail.com> wrote: > Perhaps we need to update RFC8200 and eliminate the source address field, > or at least update it so that it can hold a multicast address, indicating > the packet has multiple source devices. > > On Wed, 11 Dec 2019, 07:54 Erik Kline, <ek.i...@gmail.com> wrote: > >> Ah right. >> >> Still, in terms of the things that could be relaxed in 8200, allowing the >> SRH to be treated more like a Hop-by-Hop header might be more palatable >> than things that change the effective MTU. >> >> On Tue, 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. >>> >>> >>> 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 >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
