Robert, On 11-Dec-19 21:29, Robert Raszuk wrote: > > RFC 2473 > > Quotes have been already provided to the lists. > > When encapsulating a packet I can put whatever EH is defined and when > decapsulating the packet I can remove any EH I inserted before. I "own" the > new IPv6 header. Very simple. It is like taking the cars on a ferry. > > Your original packet (call it end to end ... call it original src going to > final/ultimate destination) is just a payload. > > I can not believe that anyone can not grasp such basic concept.
I think everyone grasps it. I think the problem is that the SRH proponents use the word "insert" a little ambiguously. In IPv6-land, it's been assumed to mean "insert an SRH header in the middle of an existing IPv6 packet header". I suspect that in SRH-land, and in the IPv6 data plane context, it's mainly being used to mean "encapsulate an IPv6 packet in a new IPv6 packet that includes an SRH header." And in the MPLS data plane context it means "prepend an additional MPLS label." Right or wrong? Brian > > > > On Wed, Dec 11, 2019 at 3:29 AM Fernando Gont <fg...@si6networks.com > <mailto:fg...@si6networks.com>> wrote: > > On 10/12/19 18:50, Robert Raszuk wrote: > > > > By your books does RFC 2473 or RFC 4798 or 100s of other RFCs which > > encapsulate IPv6 packets all violate Internet Standard I presume IPv6 > > spec ? > > > > One of us clearly is missing the point. I will let list members judge > > which one :) > > Could you please point at any RFC that inserts EHs or deletes EHs at any > place in the network other than the source or the ultimate destination? > > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com <mailto:fg...@si6networks.com> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
