Quote from RFC8200: Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, *until the packet reaches the node* (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
So now please provide the quote from RFC8200 or any other IPv6 RFC that says explicitly: "You only get to create EHs if you are sourcing the packets. Period." While there I am still waiting for an answer to the other question ... if IPv6 packets can be legally encapsulated or not. Is encapsulation not an event of sourcing effectively a new packet with some payload ? Many thx, R. On Thu, Sep 5, 2019 at 4:35 PM Fernando Gont <fg...@si6networks.com> wrote: > On 5/9/19 17:28, Robert Raszuk wrote: > > > > > > 3) Now there's at least one I-D in spring that ignores RFC8200, and > > proposes EH-insertion as if it was allowed, essentially circumventing > > RFC8200, and IETF consensus. > > > > > > Incorrect. RFC8200 makes it black on white clear that insertion, > > deletion and mangling is allowed in IPv6 if destination is yourself in > > the packet's IPv6 outer header. > > You only get to create EHs if you are sourcing the packets. Period. > > Either you are sourcing packets -- and hence you are not doing insertion > --, or you are not sourcing the packets, and hence are doing insertion. > > And EH insertion is prohibited by RFC8200. > > > -- > Fernando Gont > SI6 Networks > e-mail: 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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
