On 2/3/20 11:52, Darren Dukes (ddukes) wrote:
What follows has been made clear on the list for a while,
I am re-stating it.
The draft-ietf-spring-srv6-network-programming PSP behavior
strictly follows the letter of RFC 8200.
RFC8200 section 4 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.*
That is certainly not the intended behavior of RFC8200.
In fact, you may see that Appendix B says:
o Clarified that 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.
and the routing headers (Section 4.4) are specified as:
The Routing header is used by an IPv6 source to list one or more
intermediate nodes to be "visited" on the way to a packet's
destination.
As it may be obvious, teh wording in RFC8200 is indeed prone to
confusion, and hence should be fixed (this is not the only bug in the
EH-processing part of RFC8200, as noted by Brian, myself, and others).
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
