Bruno, On 5/12/19 12:15, bruno.decra...@orange.com wrote: [....]> > This email starts a two weeks Working Group Last Call on > draft-ietf-spring-srv6-network-programming [1]. > > > > Please read this document if you haven't read the most recent version, > and send your comments to the SPRING WG list, no later than December 20. > > > > You may copy the 6MAN WG for IPv6 related comment, but consider not > duplicating emails on the 6MAN mailing list for the comments which are > only spring specifics. > > > > If you are raising a point which you expect will be specifically debated > on the mailing list, consider using a specific email/thread for this point. > > This may help avoiding that the thread become specific to this point and > that other points get forgotten (or that the thread get converted into > parallel independent discussions)
Penultimate Segment Popping describes/specifies the removal of a SRH at a place other than the final destination of the packet. Such behavior violates RFC8200, which specifies: 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. Note, of course, that the reference of "Destination Address" in RFC8200 is clearly the final destination of the packet -- for instance, RFC8200 does not specify any routing header type, and hence the meaning is unambiguous (there's no destination other than the final destination of the packet). This is of course in line with IPv6 being and end-to-end protocol, and crucial for other related mechanisms to work as expected (such as IPsec AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful. So, in order to proceed with the document, there are multiple options forward: 1) Just remove the corresponding text/behavior 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g., re-encap) 3) Do the necessary standards work to update RFC8200, such that it allows this sort of behavior, and only ship the network-programming draft for publication when at least 6man has consensus to proceed on that path. P.S.: I will go through the document once again... but the same reasoning should be applied to any EH-insertion/removal at a place other than the source of the packet or its final destination. Thanks, -- 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
