On 27/2/20 18:29, Ron Bonica wrote:
Jinmei,
The current discussion is about Penultimate Segment Popping (PSP) (Section
4.16). Normally, when an IPv6 node processes a packet that includes a Routing
header with Segment Left equal to 1, the node decrements Segments Left and
forwards the packet, with the Routing header intact. In PSP, when an IPv6 node
processes a packet that includes a Routing header with Segment Left equal to 1,
the node removes the Routing header and forwards the packet, without the
Routing header.
The question is whether PSP violates the following clause from Section 4 of RFC
8200:
"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."
A literal reading of this text suggest that any segment endpoint (i.e., any
node referenced in the Routing Header) can process, insert, or delete any
extension header. This is because when a packet arrives at a segment endpoint,
one of its addresses appears in the IPv6 Destination Address field.
At least one RFC contradicts this literal reading. Section 3.3.3.1.1.2 of RFC
4302 says that the payload length and next header fields of the IPv6 header are
immutable. PSP would change both of these and break AH processing.
The intent is grasped in Appendix B of RFC8200:
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.
We might have done a poor job polishing the text. That doesn't change
anything. And that's what Errata's are for.
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
