> End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01 will > insert a new SRH in the received IPv6 packet, which results in two SRHs in > one IPv6 packet. It is contradict with RFC8200 that says Each extension > header should occur at most once, except for the Destination Options header. > > In draft-voyer-6man-extension-header-insertion-06, an intermediate node > executes the insert function to implement a sub-50 milliseconds FRR operation > upon link failure. It is contradict with RFC8200 that says 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.
I think how you look at the host stack may influence how you view these restrictions. Take the example of GSO where an application asks the NIC to do TCP segmentation on its behalf. Or IPsec inserts headers at L3. Likewise the originator of a packet could "offload" this function further down the stack or even to another entity. Bump in the stack, Bump in the wire. Best regards, Ole _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
