On 23/9/20 21:22, Erik Kline wrote:
(5) This point is for the IESG to discuss.
§4.16.1.2 <http://4.16.1.2>:
The End, End.X and End.T behaviors with PSP do not contravene
Section 4 of [RFC8200] because the destination address of the
incoming packet is the address of the node executing the
behavior.
The spring WG's interpretation of rfc8200 was a central point in the
appeal
presented against the WG consensus on this document. The text above, I
believe, reflects that consensus.
However, given that the document relies on the spring WG's
interpretation of
rfc8200, I think it would be better if the text is explicit.
Suggestion: to add at the end of the paragraph>
This conclusion represents the consensus interpretation of the
spring WG.
This seems like an important -- and entirely reasonable -- thing to note.
FWIW, one would expect that, if anything, if a matter is subject to
interpretation, it would be for the group that published the spec or the
IETF as a whole to discuss the topic.
I did my share of reading on how the text in RFC8200 ended up being what
it currently is and, if anything, one may say the text is far from
perfect -- but the interpretation that this document is making seems to
go against the IPv6 architecture, and even contradict the text from
previous revisions of the IPv6 specification (before we made the
relevant text sloppy in RFC8200).
Namely:
IPv6 has always forbidden en-route insertion and removal of IPv6 EHs.
RFC2460 contains this text (very similar to what's in its predecessor
RFC1883):
With one exception, extension headers are not examined or processed
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.
There, normal demultiplexing on the Next Header field of the IPv6
header invokes the module to process the first extension header, or
the upper-layer header if no extension header is present. The
contents and semantics of each extension header determine whether or
not to proceed to the next header.
[....]
The exception referred to in the preceding paragraph is the Hop-by-
Hop Options header, which carries information that must be examined
and processed by every node along a packet's delivery path, including
the source and destination nodes.
The text highlights that HBH options are processed by every node on the
path, and that other EHs are only processed when the packet reaches the
address in the "Destination Address" field. Indeed, RHs are processed
when the packets get to such destination address, and other EHs and
upper layer protocols are processed when the packet reaches the
Destination Address. For packets that employ a RH, these later EHs and
upper layer protocols will get processed by the node(s) identified in
the Destination Address when Segments Left==0 -- that is, by the final
destination.
In the same timeframe that the rfc2460bis effort (that eventually lead
to RFC8200) was being pursued, an individual internet-draft
(draft-previdi-6man-segment-routing-header) was proposing to perform
en-route header insertion/removal. When this later draft appeared in the
radar of 6man participants, there were many objections to such proposal,
as it was violating existing standards.
The proponents of draft-previdi-6man-segment-routing-header argued that
RFC2460 didn't explicitly forbid en-route EH-insertion/removal, and
hence their proposal was not violating any specifications. Some of them
claimed that the use of the term "processing" was ambiguous.
While it was clear to the vast majority of the 6man wg that the IPv6
architecture and the ipv6 specification didn't allow for EH
insertion/removal, participants felt that, since the rfc2460bis effort
was ongoing, rfc2460bis should take the chance to be crystal clear on
this point, to avoid possible future claims that such behavior was allowed.
While the document was still in the 6man wg, the proponents of
draft-previdi-6man-segment-routing-header resisted any clarifications in
this respect (please see
<https://mailarchive.ietf.org/arch/msg/ietf/j1O11x4ICMUWGJmzlJfCx0y0-c8/>),
and hence 6man shippoed for publication a version of the document that
didn't spell out the prohibition of en-route EH insertion/removal.
During the IETF LC for the document, there was a strong push to have
rfc2460bis be explicit about the prohibition of en-route
insertion/removal of extension headers, and some subset of the
participants crafted the text that eventually made it into RFC8200.
Essentially, they spelled out all the prohibited actions, as explicitly
sa possible, and added them along the existing text. The resulting text was:
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.
While the intent was to be more explicit about the things that were
prohibited, the addition of these extra terms alongside the existing
text ended up introducing a bug in the specification since, as crafted,
the text suggests that nodes that get to process EHs also get to e.g.
insert and remove EHs. This is why I consider this a bug, and why I've
submitted Erratum 6003 on RFC8200.
RFC8200 contains, in Appendix B, a summary of the changes from RFC2460,
and notes that:
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.
This spells out the intent of the corresponding text.
draft-ietf-6man-rfc2460bis-13 (the last internet-draft version of
RFC8200), it spells out the intent of the specification with even more
detail:
01) Added text that Extension headers must never be inserted by
any node other than the source of the packet.
Finally, draft-ietf-6man-rfc2460bis-08, the document that was shipped by
the 6man wg to the IESG for publication, was indeed very explicit about
the serious problems with en-route insertion/removal of EHs:
The insertion of Extension Headers by any node other than the source
of the packet causes serious problems. Two examples include breaking
the integrity checks provided by the Authentication Header Integrity
[RFC4302], and breaking Path MTU Discovery which can result in ICMP
error messages being sent to the source of the packet that did not
insert the header, rather than the node that inserted the header.
This very same problems are caused when the node inserting or removing
EHs is a node listed in an RH.
It is also worth noting that RFC8200 elevated the status of IPv6 to
"Internet Standard". Since RFC2460 by no means allows for en-route
header insertion/removal/deletion, the incorporation of this "feature"
in RFC8200 would have prevented the elevation of IPv6 to Internet
Standard. This is yet another indication that Erratum 6003 refers to a
bug in the specification, as opposed to an intended protocol behavior
that would be a change from the preceding revision of the standard, RFC2460.
As per the above, it would seem to me that before a Spring documents
makes any arbitrary interpretation of RFC8200 that happens to represent
a change to the IPv6 Architecture, 6man should clarify the topic, and if
the IPv6 architecture is to be changed, the IETF as a whole should be
involved (since that would probably be even out of the scope of 6man).
Thanks,
--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
