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.
When RFC 4302 was published, nobody questioned the assumption that the payload
length and next header fields of the IPv6 header are immutable. Therefore, we
can assume that it was a commonly held belief.
Some argue that none of this is a problem because the SRH is incompatible with
the IPv6 Authentication header (see Section 7.5 of
draft-ietf-6man-segemnt-routing-header-26).
Others argue that PSP may break more than IPv6 AH. Other applications may, may
concur with the RFC 4302 reading of RFC 8200. If they rely on payload length
and next header fields of the IPv6 header being immutable, they will also break.
Ron
Juniper Business Use Only
-----Original Message-----
From: spring <spring-boun...@ietf.org> On Behalf Of ????
Sent: Wednesday, February 26, 2020 2:40 PM
To: Fernando Gont <ferna...@gont.com.ar>
Cc: bruno.decra...@orange.com; SPRING WG List <spring@ietf.org>; 6...@ietf.org;
Lizhenbin <lizhen...@huawei.com>; draft-ietf-spring-srv6-network-programming
<draft-ietf-spring-srv6-network-programm...@ietf.org>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC -
draft-ietf-spring-srv6-network-programming
At Wed, 26 Feb 2020 11:45:14 -0300,
Fernando Gont <ferna...@gont.com.ar> wrote:
> So... is the plan to ship a document that violates RFC8200?
Please forgive me asking some clarification question that seems to be obvious
for others: which part of
draft-ietf-spring-srv6-network-programming-10 violates RFC8200? From a quick
read of it, Section 4.16 seems to describe the removal of an extension header
from an IPv6 packet at a forwarding node. Is that the one referenced as a
violation? Or is it something else, or are there others in addition to 4.16?
--
JINMEI, Tatuya
_______________________________________________
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!X7yacQY8b6Y0TpWJZiqa09s9YN5jOWOtfAZJteY4jOHczN4U3b7fl6FDtYPDLknI$
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
