Mark, Good point. I think that "The Devil's Paragraph" in RFC 8200 may be ambiguous. We should tighten it us using whatever mechanism the AD's suggest.
Clearly, this will take time. Until then, we should probably hammer out some compromise so that the bulk of the network programming draft can progress. I suggest such a compromise in https://mailarchive.ietf.org/arch/msg/ipv6/Cj_I28dpXQ1uKPhdGsSaYgMeOo0/. Ron Juniper Business Use Only -----Original Message----- From: Mark Smith <markzzzsm...@gmail.com> Sent: Thursday, February 27, 2020 5:57 PM To: Ron Bonica <rbon...@juniper.net> Cc: 神明達哉 <jin...@wide.ad.jp>; Fernando Gont <ferna...@gont.com.ar>; SPRING WG List <spring@ietf.org>; 6...@ietf.org; 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 Hi Ron, On Fri, 28 Feb 2020 at 08:30, Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> 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. > Some other text that is relevant to the above Section 4 from Section 4.4, "Routing Header": "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." Can intermediate node DAs ever be multicast IPv6 addresses? If the answer was no, then that means that "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." can only be referring to final unicast or final multicast DAs, not the intermediate node DAs in an RH. I wondered if SIDs in the the SRH could be multicast. 'draft-ietf-spring-srv6-network-programming-10' doesn't mention the word 'multicast' at all, and neither does 'draft-ietf-6man-segment-routing-header-26'. Regards, Mark. > 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/spri > ng__;!!NEt6yMaO-gk!X7yacQY8b6Y0TpWJZiqa09s9YN5jOWOtfAZJteY4jOHczN4U3b7 > fl6FDtYPDLknI$ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6 > __;!!NEt6yMaO-gk!UjKW8iONc2cSqHE0v27Zk_LKJsFFkan6BYM_bKFHbu3oCjMb7IAgB > qDifsVU8B_i$ > -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
