Subject: [Errata Rejected] RFC8200 (6003)

From: RFC Errata System <[email-masked]>
Date: Sun, 10 May 2020 11:41:12 -0700 (PDT)

The following errata report has been rejected for RFC8200,
"Internet Protocol, Version 6 (IPv6) Specification".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6003

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Fernando Gont <[email-masked]>
Date Reported: 2020-03-02
Rejected by: Erik Kline (IESG)

Section: 4

Original Text
-------------
   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.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   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.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

Corrected Text
--------------
   The source node of a packet, identified by the source address, may
   include extension headers in a packet when it is created. Extension
   headers must not be inserted or removed or have their length altered
   by any node for the lifetime of the IPv6 packet. Note that it follows
   from these requirements that the length of an IPv6 packet cannot
   change once the packet has been created by the source node. The
   aforementioned rules apply to all IPv6 extension headers.

   Extension headers (except for the Hop-by-Hop Options header, a
   Routing Header, or a Destination Options header preceding a Routing
   Header) are not processed by any node along a packet's delivery path,
   until the packet reaches the final destination node (or each of the
   set of final destination nodes, in the case of multicast).

   For packets that do not include a Routing Header, the final
   destination node is identified by the Destination Address field of
   the IPv6 header. For packets that include a Routing Header, the final
   destination node is identified by the Destination Address field of
   the IPv6 header only when the Segments Left field of the Routing
   Header is 0.

   The Hop-by-Hop Options header may be examined or processed by any
   node along a packet's delivery path, until the packet reaches the
   final destination node (or each of the set of final destination
   nodes, in the case of multicast). The Hop-by-Hop Options header, when
   present, must immediately follow the IPv6 header.  Its presence is
   indicated by the value zero in the Next Header field of the IPv6
   header.

   A Destination Options header preceding a Routing Header is processed
   only by the destination node (or each of the set of destination
   nodes, in the case of multicast) identified by the Destination
   Address field of the IPv6 header. This means that a Destination
   Options header preceding a Routing Header will be processed by the
   first destination of the packet (specified by the Destination Address
   field of the IPv6 header at the source node) and by each node listed
   in the Routing Header.

   A Routing Header is processed only by the destination node (or each
   of the set of destination nodes, in the case of multicast) identified
   by the Destination Address field of the IPv6 header. This means that
   a Routing Header will be processed by the first destination of the
   packet (specified by the Destination Address field of the IPv6 header
   at the source node) and by each node listed in the Routing Header. 

Notes
-----
This erratum addresses the following problems from RFC8200:

* It clarifies that IPv6 does not support en-route insertion/removal
  of IPv6 Extension Headers

* Clarifies the the processing rules for Routing Headers and Destination
  Options headers preceding a Routing Header.

RATIONALE:

IPv6 never supported the en-route insertion/removal of IPv6 Extension Headers, since it would have broken a number of IPv6 core components, including:

* IPsec Authentication Header (AH)

* Path-MTU Discovery for IPv6 (RFC8201)

* Error reporting based on ICMPv6 error messages (RFC4443), since hosts
  validate that received error messages correspond to packets sent by
  the host receiving the error message.

It was the intent of RFC8200 to clarify this behavior, as noted by Appendix B ("Changes Since RFC 2460") 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.

however, the resulting text was far from perfect. This erratum means to more closely reflect and respect the intent of RFC8200.

The corrected text has benefited from the review and input from Ron Bonica, Brian Carpenter, and Tom Herbert.
 --VERIFIER NOTES-- 
Section 3 clearly highlights for the reader when the IPv6 Destination Address in the header might differ from the IPv6 address of the ultimate destination.

As such, all references in the document to "Destination Address" lacking further qualifying text should be read bearing this in mind.  The text in section 4 is no exception.  The key text has remained unchanged since RFC 1883.

Though it may be fraught with operational peril, including impeding the correct processing by the source node of a received ICMPv6 error message's encapsulated packet payload, a strict literal reading of the existing text affords any node in the header's Destination Address field a (possibly surprising) degree of flexibility in the handling of extension headers.

If IPsec AH (RFC 4302) were in use, the overall IPv6 header Payload Length field would need to remain intact, but the contents of certain types of extension headers between the IPv6 header and the AH header may not need to be preserved.  If AH is not in use, it is not clear that any AH-related requirements need apply at all.

Given the continuing discussion, whether this text (and its strict literal interpretation) is a feature or a bug appears to lack consensus.

In fact, considering the apparent lack of substantive progress toward resolution on this issue in the working group since https://www.rfc-editor.org/errata/eid5933 previously attempted to revise this text, continuing use of the erratum report process for this could risk the appearance of bypassing the working group consensus process.

The text from Section 3 makes it clear that making the kind of change proposed would require a consensus change; this is not a matter to be address by an erratum alone.

--------------------------------------
RFC8200 (draft-ietf-6man-rfc2460bis-13)
--------------------------------------
Title               : Internet Protocol, Version 6 (IPv6) Specification
Publication Date    : July 2017
Author(s)           : S. Deering, R. Hinden
Category            : INTERNET STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Fernando Gont <[email-masked]>
Date: Sun, 10 May 2020 16:28:01 -0300

Erik,

I have some questions about the processing of this erratum, which I'd 
like to ask, if anything, for the sake of transparency.

Based on the errata processing rules 
(https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/), 
it would seem that one of these two would apply:

1 Only errors that could cause implementation or deployment problems or 
significant confusion should be Verified.

[....]

2. Changes that modify the working of a protocol to something that might 
be different from the intended consensus when the document was approved 
should be either Hold for Document Update or Rejected. Deciding between 
these two depends on judgment. Changes that are clearly modifications to 
the intended consensus, or involve large textual changes, should be 
Rejected. In unclear situations, small changes can be Hold for Document 
Update.

I'd argue that the erratum I filed belongs to "1.". But based on the 
result of the processing of this erratum, it would seems that you've 
considered it belongs to "2", as in the submitted erratum changing the 
intent of the specification and/or the working of the protocol. -- or, 
put another way, you seem to suggest that RFC8200 allows for EH header 
insertion/removal/mangling in any intermmediate hop that is listed in a 
Routing Header.

In that light, and for the sake of transparency and understanding the 
processing of this erratum, my questions are:

1) Is the current state of the IPv6 standard that nodes listed in a 
Routing Header can insert, remove, process, or (more generally) mangle 
with the packet structure?

2) If that's the assumption, how does IPv6 operate with respect to
AH, PMTUD, and error reporting?  Allowing intermmediate nodes (such as 
those listed in a RH) can certainly break AH, PMTUD, and (ICMPv6) error 
reporting.   Whereas nono of these core functionalities break if 
EH-mangling on the delivery path is forbidden -- as I personally think 
it is.

3) RFC8200 also contains the following text, as one of the intended 
clarifications:

?

If the argument is that nodes listed in a RH can mangle with EHs, then, 
in order for this sentence to make any sense, is your interpretation 
that the noes listed in a RH are not part of the packet delivery path?

4) The very RH is specified as:
   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.

Where there's no use of destination vs final destination -- indeed, this 
text implies that the "destination" is the final destination of the 
packet. In that light, why would one specific interpretation of one part 
of the current standard (RFC8200) be considered to override or take 
precedence over other parts of the standard?  And, in particular, when 
one of such parts and interpretations break several protocol mechanisms, 
and the other doesn't?

5) Based on a literal reading of RFC8200, the processing of a 
Destinations OPtions Header preceding a RH is not allowed. As such, 
should we also consider that nodes must ignore the DOH preceding a RH in 
IPv6 packets?

I believe the above should be considered a clear indication that while 
the text is precise, the intent of the original spec is in-line with the 
erratum that I have submitted. That said, at the very least a 
clarification of my questions about might help me to understand the 
processing of this erratum.

Thanks,
Fernando

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Erik Kline <[email-masked]>
Date: Sun, 10 May 2020 18:57:24 -0700

[ moved IESG and RFC Editor to bcc ]

> with the packet structure?

I think the text is pretty clear that the extent of the
"mangle-ability" is limited to HbHs and DOs between the IPv6 header
and the RH.

> EH-mangling on the delivery path is forbidden -- as I personally think

[AH]

If a router in the dest addr field attempted to alter a packet with an
AH, the implementation would be faced with a choice:

  (a) break things such that AH validation detects the tampering (AH
is "working as intended"),

  (b) only tamper with things that AH does not cover,

  (c) don't tamper at all, or

  (d) other: e.g., discard, punt to an SDN controller, phone a friend, ...

(b) and (c) would probably be better than (a).  But there might be
uses for (a) and (d).

By analogy, perhaps we could consider the choice faced by by a NAT'ing
router implementation that receives an IPv4 packet with AH (though
perhaps there is specific guidance in a document somewhere for this
case -- I don't know).  Regardless of behaviour in the presence of an
AH, "NAT's gonna NAT" when an AH is absent.

[ PMTUD ]

Header removal does not cause a PMTUD problem.

Header "swap", such that the IPv6 Payload Length remains unmodified,
does not cause a PMTUD problem.

Header insertion could cause a PMTUD, but there are some circumstances
where it also might not, i.e. if the router doing the insertion were
also the router forwarding onto a link where the MTU would be
exceeded: it could instead generate a PTB.

[ ICMPv6 error reporting ]

I called out this case in particular because I also think it could
complicate a sending node's implementation.  However:

  (a) the additional processing complexity is only incurred by sending
nodes that insert RHs ("no Routing Header, no cry"),

  (b) if the ICMPv6 error originator filled the packet out to 1280
bytes per RFC 4443 S2.4 (c) then it seems possible that things could
all still work, and

  (b) even RFC 4443 acknowledges that sometimes ICMPv6 error messages
just can't be properly processed; the 2nd paragraph of RFC 4443 S2.4
(d) is a partial list of when a node invokes the "shrug emoji handling
routine".

> that the noes listed in a RH are not part of the packet delivery path?

This text you've excerpted is from Appendix B that summarizes changes
from RFC 2460.  Its brevity elides *all* the truly relevant details in
the rest of the document and I fail to see how it can be used to
supersede the real, detailed text.

> one of such parts and interpretations break several protocol mechanisms,

Because, as has been stated, the text in Section 3 goes out of its way
to identify when the Destination Address field may not be that of the
ultimate destination, and Section 4 defines the node in the
Destination Address field as the one able to modify headers.

> should we also consider that nodes must ignore the DOH preceding a RH in

I'm afraid I don't quite follow you here.  Section 4.1 discusses this
in detail, and note 1 identifies this use case explicitly.

Cheers,
-ek

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 11 May 2020 18:57:11 -0700

I don't have a strong opinion on how this errata should be handled,
but I'd like to make a remark on one specific point:

At Sun, 10 May 2020 11:41:12 -0700 (PDT),

> As such, all references in the document to "Destination Address" lacking further qualifying text should be read bearing this in mind.  The text in section 4 is no exception.  The key text has remai…

Does "the key text" mean the definition of "Destination Address" in
Section 3?

      Destination Address 128-bit address of the intended recipient of
                          the packet (possibly not the ultimate
                          recipient, if a Routing header is present).
                          See [RFC4291] and Section 4.4.

then that's true.  And, I agree that the text in question in Section 4
intentionally uses the term "Destination Address" precisely in this
sense until RFC2460:

   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.

This "Destination Address" *must* include an intermediate destination
specified in a routing header, since there can be an extension header
(other than hop-by-hop options headers) before a routing header, and
such a routing header would have to be "examined" or "processed" at
each destination specified in that routing header.

Now, RFC8200 changes this text in a non-trivial way, and in that sense
"a key text" has changed, which is in fact the point of the "error":

The phrase "inserted, or deleted" was added as a result of the
discussion regarding whether "examined or processed" includes
insertion or deletion.  If it doesn't, it means that an arbitrary node
in a packet's delivery path (whether or not the nodes' address can
appear in the Destination Address field of the IPv6 packet due to a
routing header) can insert or delete an extension header.  In
particular, such an arbitrary node can insert a routing header into a
packet even if that node itself doesn't appear in the Destination
Address field.  That would be particularly convenient for the
"insertion/deletion" mode of SRv6, and that interpretation ("examined
or processed" does NOT include insertion or deletion) were mainly
supported by those developing the SRv6 protocol.  Other people opposed
that interpretation and argued that "examined or processed" should
include insertion or deletion, since otherwise it would break some
existing standard protocols such as PMTUD or AH and make error
handling less robust (the same argument we're still seeing today).

So far I hope I simply explained the past fact without mixing my own
opinions.  Now this is what I would interpret the new text (which also
matched my memory on how I interpreted it at that time): with this
background history in mind, the intent of the new text should simply
be an attempt to clarify "examined or processed" includes "inserted or
deleted" for any intermediate node in a packet's delivery path.

Unfortunately the resulting text overlooked its implication with the
definition of "Destination Address", that is, accidentally making a
loophole for intermediate nodes specified in a routing header.  But if
the loophole had had been noticed at that time, it wouldn't have been
accepted by those who opposed allowing insertion/deletion, since its
adverse effects such as breaking PMTUD would be almost fully intact.
And the loophole wouldn't have made much sense for the SRv6 developers
either, since it would still prevent an fully arbitrary insertion.

So I believe most people involved in that discussion interpreted the
text as I did, regardless of their position on intermediate
insertion/deletion.  Of course, this interpretation wouldn't be
favorable for those who wanted arbitrary insertion/deletion.  The
"deal" in my memory is that while rfc2460bis (now RFC8200) explicitly
made it more restrictive than RFC2460, 6man and spring WGs would
collaborate on followup work on how we can loosen the condition.  (I
wish I had a more direct reference to this conclusion at that time,
but I couldn't easily find it so I'm writing this largely based on my
own memory and it's quite possible that it's not entirely accurate).

And that's why I believe that this is essentially a simple "bug fix"
of the RFC text and that it's more productive to fix the bug quickly
and focus on the "followup work".  In that sense I sort of agree that
it can be fixed as an erratum.  But I also admit that "purely
literally" the current RFC8200 text could read as if it made the
loophole intentionally, and so I understand the argument that it's not
suitable for errata.  And, in any case, I don't think it's productive
to spend too much time on whether errata are the suitable place for
this fix.  If that level of point is somehow debatable, I'd rather
suggest focusing on draft-bonica-6man-ext-hdr-update (I'd suggest the
same thing even if I don't happen to be a coauthor of the draft).

--
JINMEI, Tatuya

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Tue, 12 May 2020 03:46:18 +0000

Hi Jinmei,

Please see my comments in line below marked with [xjr]:

then that's true.  And, I agree that the text in question in Section 4 intentionally uses the term "Destination Address" precisely in this sense until RFC2460:

This "Destination Address" *must* include an intermediate destination specified in a routing header, since there can be an extension header (other than hop-by-hop options headers) before a routing header, and such a routing header would have to be "examined" or "processed" at each destination specified in that routing header.
[xjr] "Destination address field of the IPv6 header" even have further qualifying text to the "Destination address", so the Section 4 of RFC8200 is even more clear and solid.

Now, RFC8200 changes this text in a non-trivial way, and in that sense "a key text" has changed, which is in fact the point of the "error":

The phrase "inserted, or deleted" was added as a result of the discussion regarding whether "examined or processed" includes insertion or deletion.  
If it doesn't, it means that an arbitrary node in a packet's delivery path (whether or not the nodes' address can appear in the Destination Address field of the IPv6 packet due to a routing header) can insert or delete an extension header.  
In particular, such an arbitrary node can insert a routing header into a packet even if that node itself doesn't appear in the Destination Address field.  
[xjr] No. the text of Section 4 doesn't mean this. Note the "the node identified in the Destination Address field of the IPv6 header." ---- the further qualifying text to the "Destination address".

That would be particularly convenient for the "insertion/deletion" mode of SRv6, and that interpretation ("examined or processed" does NOT include insertion or deletion) were mainly supported by those developing the SRv6 protocol.  
Other people opposed that interpretation and argued that "examined or processed" should include insertion or deletion, since otherwise it would break some existing standard protocols such as PMTUD or AH and make error handling less robust (the same argument we're still seeing today).
[xjr]That may not an encouragement of "insertion" on such nodes, but that I think is a solid consideration in RFC2460bis (see the following of rfc2460bis):
https://www.ietf.org/rfcdiff?url1=draft-ietf-6man-rfc2460bis-09&url2=draft-ietf-6man-rfc2460bis-08
And after that, the rfc2460bis -09 is almost the same as the -00 revision, with "insertion/deletion" added:
https://www.ietf.org/rfcdiff?url1=draft-ietf-6man-rfc2460bis-09&url2=draft-ietf-6man-rfc2460bis-00
Later, the rev-11 change the "With one exception" to "except for the Hop-by-Hop Options header":
https://www.ietf.org/rfcdiff?url1=draft-ietf-6man-rfc2460bis-09&url2=draft-ietf-6man-rfc2460bis-11
[xjr] So finally the main ambiguity fixed by RFC8200 was the "With one exception" changing to "except for the Hop-by-Hop Options header".

So far I hope I simply explained the past fact without mixing my own opinions.  
Now this is what I would interpret the new text (which also matched my memory on how I interpreted it at that time): with this background history in mind, the intent of the new text should simply be an attempt to clarify "examined or processed" includes "inserted or deleted" for any intermediate node in a packet's delivery path.
[xjr] From the history of 2460bis, I did see the concerns about the impact of "insertion" (before rev-09 of 2460bis), but I did not see the concerns about the impact of "deletion".

Unfortunately the resulting text overlooked its implication with the definition of "Destination Address", that is, accidentally making a loophole for intermediate nodes specified in a routing header.  
But if the loophole had had been noticed at that time, it wouldn't have been accepted by those who opposed allowing insertion/deletion, since its adverse effects such as breaking PMTUD would be almost fully intact.
And the loophole wouldn't have made much sense for the SRv6 developers either, since it would still prevent an fully arbitrary insertion.
[xjr] the resulting text overlooked its implication with the definition of "Destination Address" ---- I didn't see this. 
[xjr] Adding the "insertion/deletion" in RFC8200 doesn't change much the RFC2460 text. 
[xjr] The "insertion/deletion" is still in careful discussion when a proposal is passing the 6man review.

So I believe most people involved in that discussion interpreted the text as I did, regardless of their position on intermediate insertion/deletion.  
Of course, this interpretation wouldn't be favorable for those who wanted arbitrary insertion/deletion.  
The "deal" in my memory is that while rfc2460bis (now RFC8200) explicitly made it more restrictive than RFC2460, 6man and spring WGs would collaborate on followup work on how we can loosen the condition.  
(I wish I had a more direct reference to this conclusion at that time, but I couldn't easily find it so I'm writing this largely based on my own memory and it's quite possible that it's not entirely accurate).
[xjr] I didn't found the intension of rfc2460bis to make it more restrictive, maybe one can check the changelog of rfc2460bis for learning.
[xjr] I didn't think either it necessary to make it more restrictive.

And that's why I believe that this is essentially a simple "bug fix"
of the RFC text and that it's more productive to fix the bug quickly and focus on the "followup work".  
In that sense I sort of agree that it can be fixed as an erratum.  
But I also admit that "purely literally" the current RFC8200 text could read as if it made the loophole intentionally, and so I understand the argument that it's not suitable for errata.  
And, in any case, I don't think it's productive to spend too much time on whether errata are the suitable place for this fix.  
If that level of point is somehow debatable, I'd rather suggest focusing on draft-bonica-6man-ext-hdr-update (I'd suggest the same thing even if I don't happen to be a coauthor of the draft).
[xjr] As a core protocol, the RFC8200 should not restrict the possible development of EH that it couldn't foresee. Instead, the development of EH should be left in case-by-case consideration under this core protocol of 8200.
[xjr] I would consider such development as a motivation of IPv6, as stated in RFC8200 -- Improved Support for Extensions and Options.

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of JINMEI Tatuya / 神明達哉
Sent: Tuesday, May 12, 2020 9:57 AM
To: RFC Errata System <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Errata Rejected] RFC8200 (6003)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 May 2020 00:11:54 -0300

> --VERIFIER NOTES-- Section
> 3 clearly highlights for the reader when the IPv6 Destination Address
> in the header might differ from the IPv6 address of the ultimate
> destination.
> 
> As such, all references in the document to "Destination Address"
> lacking further qualifying text should be read bearing this in mind.
> The text in section 4 is no exception.  The key text has remained
> unchanged since RFC 1883.

As noted by Jinmei in 
<https://mailarchive.ietf.org/arch/msg/ipv6/pB5dcr9FBV4vgziWop0kjGLseRU/>, 
this argument is incorrect.

Particularly in the light that it may also affect the discussion 
associated with an Appeal that is currently being processed by the IESG, 
I believe this should be revised.

Please let me elaborate on my claim:

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:

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, af 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:

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.

Thanks,

---

From: [email-masked]
Date: Fri, 15 May 2020 11:10:48 +0200

Fernando,

Can you give a summary of new points, if any, that you bring up in this email?
That is, aspects that havent previously been discussed in detail on the list or is covered in 6003.

Best regards,
Ole

> On 15 May 2020, at 05:11, Fernando Gont <[email-masked]> wrote:
> 
> As noted by Jinmei in <https://mailarchive.ietf.org/arch/msg/ipv6/pB5dcr9FBV4vgziWop0kjGLseRU/>, this argument is incorrect.
> 
> Particularly in the light that it may also affect the discussion associated with an Appeal that is currently being processed by the IESG, I believe this should be revised.
> 
> 
> 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):
> 
> 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:
> 
> 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, af 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:
> 
> 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:
> 
> 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:
> 
> 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.
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 May 2020 14:05:24 -0300

Hello, Ole (and IESG),

(please pay particular attention to bullet #4 bellow)

> That is, aspects that havent previously been discussed in detail on the list or is covered in 6003.

Sure:

1) My email notes that some of the verifier's notes for Erratum 6003 are 
incorrect.

It is irrelevant what the wg may or may have not discussed (besides the 
fact that I don't think these points have been discussed). The 
aforementioned claims have been employed to back the decision to reject 
erratum 6003. However, as these claims have been proven to be incorrect, 
I think reconsideration is warranted.

Specifically, the verifier's notes say:
       "The key text has remained unchanged since RFC 1883"

As it should be evident from my email, it's actually the other way 
around: the key text has been *different* from RFC8200 all the way since 
RFC1883 till the IETF LC of what became RFC8200.

2) Since we are at it, I will also add that the following statement from 
the verifier's notes is incorrect:

     In fact, considering the apparent lack of substantive progress
     toward resolution on this issue in the working group since
     https://www.rfc-editor.org/errata/eid5933 previously attempted
     to revise this text, continuing use of the erratum report process
     for this could risk the appearance of bypassing the working group
     consensus process.

Erratum 5933 was submitted in early December 2019, and was processed 
only in early March 2020. Only a few days later since the erratum was 
processed as "held for document update", an Internet-Draft was posted 
(draft-bonica-6man-ext-hdr-update), and the draft was revised three 
times since then. I don't think the 6man wg could have done any more 
progress on the topic than that, other than requesting the chairs to do 
an adoption call on said draft, which the draft authors did request.

3) Based on item #1 above, any interpretation that RFC8200 allows for 
en-route EH insertion/removal should beg the question that, since this 
would be a major departure from RFC2460, had that been the case, IPv6 
could have never been elevated to "Internet Standard" status.

4) I will point Erik and the rest of the IESG to Suresh Krishnan's 
comment about the outcome of the IETF LC (please see: 
https://mailarchive.ietf.org/arch/msg/ietf/0it68EdnBDs73uxpmzIQqlMw-fE/), 
which clearly states what was the intention of the updated text:

     Thanks to everyone who commented during the IETF Last Call of
     draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for
     this draft was mainly focused around the text in Section 4 that
     discusses the handling of extension headers. The biggest concern
     raised was that the current text is ambiguous on whether header
     insertion is allowed on intermediate nodes or not. There were some
     people arguing that an explicit prohibition is not necessary as the
     text is already clear, while others believed that explicitly
     listing the prohibitions will minimize any misunderstandings in the
     future. There was also a small number of people who wanted to
     explicitly allow header insertion and describe how to do it, but
     this was clearly out of scope for this draft (but may be in scope
     for future work in 6man). Overall, no one argued against the fact
     that the intent of the text in RFC2460 was to forbid insertion of
     extension headers on any other node but the source of the packet.
     The only argument made against adding clarifying text was that the
     text was already clear. Given this, I believe there is consensus to
     add explicit text about header insertion into the draft before it
     progresses further.

As per the above, I do believe the submitted erratum points a bug in the 
spec, and thus should be processed as "Verified".

Besides, since the IESG is processing an Appeal that covers this topic, 
I do expect that this note is considered during their resolution of said 
Appeal.

Thanks,

---

From: Erik Kline <[email-masked]>
Date: Fri, 15 May 2020 13:55:38 -0700

[ IESG to bcc;
  all are welcome to follow on 6man;
  all are welcome to re-cc IESG ]

[1] I began with a reading of the existing and previous text (1883 ->
2460 -> 8200) to see exactly what is said.

RFC 8200 includes a blanket prohibition on on-path nodes doing things
like header insertion or removal.  This text has changed as it evolved
into 8200.

RFC 8200 includes an exemption to this behaviour for nodes whose
address appears in the Destination Address field of the IPv6 header.
This text has not changed from 1883 to 2460 to 8200.

RFC 8200 includes explicit text to remind the reader that when a
Routing Header is present the node in the Destination Address header
may not be that of the ultimate recipient. This text has also not
changed from 1883 to 2460 to 8200.

Jinmei's email of 2020.05.12 presents, IMHO, a fair walk-through of
the evolution of the text.  The final summary of "most people's
interpretation" though is I think possibly a subjective matter.

[2] The consensus achieved on this was rough -- very rough, to quote
Suresh.  In the end, RFC 8200 is the text that we got.

You cite Suresh's email from 2017.03.17.  Alvaro cited, among other
things, the minutes of 6man at IETF 98 on 2017.03.30 in his DISCUSS on
this very text in 2460bis on 2017.04.07.  Indeed, the document and
discussion continued to evolve even further as 2460bis wound its way
through the process.  The final version, draft -13, was uploaded on
2017.05.19.

There were numerous contributions of opinions voiced on all sides when
one goes back through the archives to search for them.  To revise this
contentious point via the erratum report process would:

    [a] necessitate hypothetical re-evaluation of the already rough
consensus from 3 years ago on the new proposed text, and

    [b] risk inappropriately discarding the silent agreement of those
who accept the current text.

I agree with Suresh when, in his handling of erratum report 5933, he wrote:

    "...it is impossible to tell after the fact if the proposed
replacement text would have achieved consensus..."

[3] Understandings of text and their implications may change over
time; that's okay; and we have a process for that.

That process is a new working group document that updates 8200.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 May 2020 18:33:23 -0300

On 15/5/20 17:55, Erik Kline wrote:
[....]
> changed from 1883 to 2460 to 8200.

The base-text has not changed, indeed. But the resulting meaning did 
completely change the words "inserted, removed, etc." were added along 
"processed" in the relevant text.

[....]
> this very text in 2460bis on 2017.04.07. 

I'm not sure how that is relevant. The IETF has no sort of consensus on 
"controlled domains".

[....]
> consensus from 3 years ago on the new proposed text, and

The reference I provided for Suresh comments on the outcome of the IETF 
LC seems to positively describe what the resulting text was meaning.
In his email, he doesn't seem to offer much room for interpretation.

i.e., what I'm saying is that the text that was committed into RFC8200 
doesn't match the crystal-clear intention expressed by Suresh along with 
the proposed text.

If not this, I'm not sure what would be the definition of "bug in a 
specification".

> replacement text would have achieved consensus..."

IMHO, how you craft the specific text, when compared to the agreement on 
what you want to say, is a second order thing (the low bit of it).

> That process is a new working group document that updates 8200.

In that light, has a call for adoption been scheduled for 	
draft-bonica-6man-ext-hdr-update ? It has not been listed in the recent 
email by Bob on the scheduled consensus calls (see: 
https://mailarchive.ietf.org/arch/msg/ipv6/4LYzJPBc-vNoDb-m6KPypfzVPYc/).

Thanks,

---

From: Sander Steffann <[email-masked]>
Date: Sat, 16 May 2020 00:32:57 +0200

Hi Erik,

> This text has not changed from 1883 to 2460 to 8200.

I disagree with your interpretation of the text of 8200. It says:

It mentions _the_ node identified in the DA, singular. It only specifies multiple nodes in the case of multicast. The combination of using singular and only using plural when explicitly talking about multicast reads to me as only referring to the final destination. The use of the word "until" signals the same to me. Using "until" for something that can occur multiple times sequentially in a packets lifetime would be very confusing.

Now, this does pose a problem, because strict reading of that text also means that a node can only learn that it is not the final destination by processing the routing header. As I read it, that node can process the routing header but then has to stop further processing when it finds out it is not the final destination. In blunt English: any further processing of headers is none of its business. As I understand it that is also the reason that a separate destination options header may appear *before* the routing header.

Cheers,
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 16 May 2020 00:53:07 +0200

> It mentions _the_ node identified in the DA, singular.

Lol ...

How can DA contain more then one destination node address (other then
multicast) in the view of RFC8200 ?

Unbelievable what is happening on this WG list.

Have a great weekend,
R.

On Sat, May 16, 2020 at 12:33 AM Sander Steffann <[email-masked]> wrote:

> It mentions _the_ node identified in the DA, singular. It only specifies
> multiple nodes in the case of multicast. The combination of using singular
> and only using plural when explicitly talking about multicast reads to me
> as only referring to the final destination. The use of the word "until"
> signals the same to me. Using "until" for something that can occur multiple
> times sequentially in a packets lifetime would be very confusing.
>
> Now, this does pose a problem, because strict reading of that text also
> means that a node can only learn that it is not the final destination by
> processing the routing header. As I read it, that node can process the
> routing header but then has to stop further processing when it finds out it
> is not the final destination. In blunt English: any further processing of
> headers is none of its business. As I understand it that is also the reason
> that a separate destination options header may appear *before* the routing
> header.
>
> Cheers,
> Sander
>

---

From: Sander Steffann <[email-masked]>
Date: Sat, 16 May 2020 00:59:10 +0200

Hi Robert,

> How can DA contain more then one destination node address (other then multicast) in the view of RFC8200 ?
> 

I would appreciate it if you would be a bit less derogatory in your replies to other working group members.
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 16 May 2020 01:37:04 +0200

Dear Sander,

>  I would appreciate it if you would be a bit less derogatory in your
replies to other working group members.

Let your wish be my command.

The discussions on this list reached levels far beyond real solid technical
debate.

Solid arguments are being ignored (or remain unanswered), voice from
operators and vendors not being taken seriously and proposals without any
merits are being placed in WG adoption status in spite of obvious overlap
with ongoing identical work in other WGs.

Sure this is not the first time in IETF history where ideas turn into RFCs
only to die in the marketplace. Hint: CR-LDP.

With that I decided to unsubscribe from 6man for now. Just do not have time
for this type of IETF WG list.

But what worries me the most is that instead of focusing this WG efforts to
enhance IPv6 to make the deployments easier the WG energy goes to complete
black hole.

It is not a good news for the global Internet infrastructure our
lives truly depend on.

Kind regards,
Robert.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 May 2020 11:49:58 +1200

Sander,
On 16-May-20 10:32, Sander Steffann wrote:
> It mentions _the_ node identified in the DA, singular. It only specifies multiple nodes in the case of multicast. The combination of using singular and only using plural when explicitly talking about multicast reads to me as only referring to the final destination. 

And there's the problem right there. "reads to me" but not to other people.

The text is objectively ambiguous because it can be read either way. (I read it the same as you, but you and I are not the IETF.)

I actually agree with the AD: this is not something we can fix by erratum, because we objectively haven't got consensus about what it means.

We need an "updates" RFC to fix this. And we have a draft for that. And a process to follow to reach rough consensus.

     Brian

The use of the word "until" signals the same to me. Using "until" for something that can occur multiple times sequentially in a packets lifetime would be very confusing.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 16 May 2020 12:00:26 +0900

> replacement text would have achieved consensus..."

Big +1 to this. The erratum process is not the right way to deal with a
contentious issue such as this one with strong opinions on both sides. That
process simply does not allow for enough dialogue to explore the
disagreements and reach consensus. Any outcome arising from that process,
to the people that disagree with it, would almost certainly likely appear
arbitrary and authority-based. It would be very divisive, when in fact what
is needed here is the opposite: a WG discussion to attempt to achieve
consensus on a compromise, or simply to make it clear to all parties that
there is no consensus to be found and that the IETF is unfortunately not
able to recommend any particular outcome.