RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Ron Bonica <[e-mail]>]

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 <[e-mail]> On Behalf Of ????
Sent: Wednesday, February 26, 2020 2:40 PM
To: Fernando Gont <[e-mail]>
Cc: [e-mail]; SPRING WG List <[e-mail]>; [e-mail]; Lizhenbin <[e-mail]>; draft-ietf-spring-srv6-network-programming <[e-mail]>
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 <[e-mail]> 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
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!X7yacQY8b6Y0TpWJZiqa09s9YN5jOWOtfAZJteY4jOHczN4U3b7fl6FDtYPDLknI$