Subject: Errata #5933 for RFC8200

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 17:07:36 -0300

Suresh,

Two months ago I filled an errata on RFC8200 regarding the processing of 
IPv6 extension headers. The errata is available here: 
https://www.rfc-editor.org/errata/eid5933

While I believe that folks with a knowledge of Internet Protocols would 
be able to interpret what is in RFC8200, given recent discussions on the 
topic, and upon a re-read of the text, I believe a clarification is 
warranted, such that we allow all sorts of curious interpretations of 
the text.

I send a heads-up on the 6man mailing list 
(https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/), 
and the proposed text received the review of at least Brian Carpenter, 
Ron Bonica, and Mark Smith. Their reviews are available on such thread.

In the light that some folks seem to be pretending to leverage "the lack 
of clarify" in RFC8200 (an Internet Standard) to violate it, I'd 
appreciate that the reported errata be processed.

Processing the aforementioned errata is key to many of the discussions 
this and other WGs are having.

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

---

From: Mark Smith <[email-masked]>
Date: Fri, 28 Feb 2020 08:09:57 +1100

Hi Fernando, Suresh,

> this and other WGs are having.

I think this text in the RH section also needs to be updated:

"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
   +*final* destination.  This function is very similar to IPv4's Loose Source
   and Record Route option."

I think this text may also further support which type of destination
is being referred to by the earlier EH text that Fernando is proposing
to clarify:

"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."

If this text is implicitly saying that an operation at all is
permitted on EHs when the packet is at the device holding the packet's
DA, intermediate or final in the case of a Routing Header, then I
think it is also saying, due to the "(or each of the set of nodes, in
the case of multicast)" text, that intermediate DAs in an RH can be
multicast addresses.

Would it ever be useful or valid to have an RH that is listing
multicast addresses as the intermediate DAs for the packet to visit?

I think that would also mean that at those intermediate multicast DAs,
if there are downstream interested listeners, the packet would be
duplicated per multicast operations. Are there any applications for
that sort of thing? I think it is a possible packet amplification
attack vector (two intermediate multicast node addresses that point
towards each other could create an amplification loop I think).

If we came to the conclusion that it is impossible or too dangerous
for RH intermediate node DAs to be multicast addresses, and that
intermediate node addresses must be unicast addresses, then I think
that then further clarifies and supports that the earlier EH text -
"Extension headers [...] are not processed, inserted, or deleted [...]
identified in the Destination Address field of the IPv6 header." - is
only referring to the final destination address, not intermediate ones
in an RH, because only final DAs can be multicast addresses.

It might sound a bit like clutching at straws, however the RH text is
unambiguous about intermediate verses final node DAs, and that clarity
helps clarify what type of DA is being referred to in the earlier EH
no insertion, deletion etc. text.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Feb 2020 16:32:00 -0500

Hi Fernando,

> On Feb 27, 2020, at 3:07 PM, Fernando Gont <[email-masked]> wrote:
> 
> Suresh,
> 
> Two months ago I filled an errata on RFC8200 regarding the processing of IPv6 extension headers. The errata is available here: https://www.rfc-editor.org/errata/eid5933
> 
> While I believe that folks with a knowledge of Internet Protocols would be able to interpret what is in RFC8200, given recent discussions on the topic, and upon a re-read of the text, I believe a clarification is warranted, such that we allow all sorts of curious interpretations of the text.

I think this would be fine to clarify, but IMHO the errata process is not the right way to do it. 

Based on the IESG Statement about processing of RFC Errata for the IETF Stream (https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/ <https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/>)

"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."

As you said above, some people might interpret the text in RFC8200 to mean the replacement text you provided in the errata but others might read the text exactly as written ("until the packet reaches the node identified in the Destination Address field of the IPv6 header”). Given that the text in RFC8200 had consensus (and I don’t think you said otherwise) and it is impossible to tell after the fact if the proposed replacement text would have achieved consensus, I think this erratum falls under the above category. 

> 
> I send a heads-up on the 6man mailing list (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/), and the proposed text received the review of at least Brian Carpenter, Ron Bonica, and Mark Smith. Their reviews are available on such thread.
> 
> In the light that some folks seem to be pretending to leverage "the lack of clarify" in RFC8200 (an Internet Standard) to violate it, I'd appreciate that the reported errata be processed.
> 
> Processing the aforementioned errata is key to many of the discussions this and other WGs are having.

I will process this and move it to the “Hold for Document Update” state with the following note

“The change proposed by this erratum has to be evaluated for correctness and consensus if and when there is an update of RFC8200."

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 18:48:12 -0300

On 27/2/20 18:32, Suresh Krishnan wrote:
> Hi Fernando,
> 
>> On Feb 27, 2020, at 3:07 PM, Fernando Gont <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Suresh,
>>
>> Two months ago I filled an errata on RFC8200 regarding the processing 
>> of IPv6 extension headers. The errata is available here: 
>> While I believe that folks with a knowledge of Internet Protocols 
>> would be able to interpret what is in RFC8200, given recent 
>> discussions on the topic, and upon a re-read of the text, I believe a 
>> clarification is warranted, such that we allow all sorts of curious 
>> interpretations of the text.
> 
> Based on the IESG Statement about processing of RFC Errata for the 
> IETF Stream 
> (https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/)
> 
> "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."

I have been part of the rfc2460bis/RFC8200 effort, and clearly the 
consensus was the IPv6 extension headers are not added/removed along the 
packet delivery path.

For instance, Appendix B of RFC8200 says:
    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.

> As you said above, some people might interpret the text in RFC8200 to 
> mean the replacement text you provided in the errata but others might 
> read the text exactly as written ("until the packet reaches the node 
> identified in the Destination Address field of the IPv6 header”). Given 
> that the text in RFC8200 had consensus (and I don’t think you said 
> otherwise) and it is impossible to tell after the fact if the proposed 
> replacement text would have achieved consensus, I think this erratum 
> falls under the above category.

Can you please, as AD, answer these questions:

* Does IPv6 support IPv6 header insertion/removal along the packet 
delivery path?

* If you assume so, then, How does it play with core IPv6 functionality 
like:
     IPsec AH
     PMTUD
     error reporting

> I will process this and move it to the “Hold for Document Update” state 

This would clearly be incorrect. This is not a proposal for new 
behavior, but a clarification of the intended behavior of IPV6/RFC8200.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:08:26 -0300

> the intended consensus, or involve large textual changes, should be 

The intent of the spec is on the spec itself:

Appendix B:

Routing Headers, for instance, are 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.

Just to be clear, I believe that your stated decision of processing this 
errata as "Hold for document update" is not only incorrect, but also 
doesn't represent the consensus this working group got during the 
rfc2460bis effort -- now RFC8200.

It is also unfortunate to have a second instance of this, because, at 
the time the same group was pushing other IPv6 insertion/removal ideas, 
I also objected 6man shipping rfc2460bis as such. And we only got to 
improve on that during IETF LC.

As such, I will formally Appeal your decision.

Thanks,

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Feb 2020 17:19:19 -0500

Hi Fernando,

> On Feb 27, 2020, at 5:08 PM, Fernando Gont <[email-masked]> wrote:
> 
>>> On Feb 27, 2020, at 3:07 PM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Suresh,
>>> 
>> Based on the IESG Statement about processing of RFC Errata for the IETF Stream (https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/)

Correct. This was to clarify the "extension headers are not examined or processed by any node” text in RFC2460 which some people claimed would allow insertion and deletion. And the right way to do that was to do exactly as we did. Waited for the revision of RFC2460 and get WG consensus to make the change. If you had submitted an Erratum on RFC2460 to make the same change on RFC2460 we would have had the same result.

> Just to be clear, I believe that your stated decision of processing this errata as "Hold for document update" is not only incorrect, but also doesn't represent the consensus this working group got during the rfc2460bis effort -- now RFC8200.

> 
> It is also unfortunate to have a second instance of this, because, at the time the same group was pushing other IPv6 insertion/removal ideas, I also objected 6man shipping rfc2460bis as such. And we only got to improve on that during IETF LC.
> 

Please do go ahead. I stand by my assessment that this is a misuse of the Errata process and it is not a simple clarification as you claim.

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:26:52 -0300

On 27/2/20 19:19, Suresh Krishnan wrote:
> Correct. This was to clarify the "extension headers are not examined or processed by any node” text in RFC2460 which some people claimed would allow insertion and deletion. And the right way to do that was to do exactly as we did. Waited for the revision of RFC2460 and get WG consensus to make the change. 

That's not what we did. Nobody waited for RFC2460 to be revised. I 
submitted an errata about that, indeed.

Besides, please let me ask: How can you possibly argue that this:
        https://www.rfc-editor.org/errata/eid5945
is acceptable

but this:

errata #5933 isn't?

This post 
<https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/> 
says:

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

This is exactly the case: clearly folks are confused about how they read 
RFC8200, and are implementing and deploying boxes based on such 
confusion, which may result in deployment problems -- because eh 
insertion and removal breaks so many things.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:30:19 -0300

[...]
> Please do go ahead. I stand by my assessment that this is a misuse of the Errata process and it is not a simple clarification as you claim.

For Jinmei's latest email 
(https://mailarchive.ietf.org/arch/msg/ipv6/ZsOetWf61OERYavsTmCMLcu9TJE/):

Yes, purely "literally", it
could read that way (it's amazing human-written text can be always
ambiguous to some extent, no matter how hard we try to clarify it), but
that doesn't make sense if we recall a larger context.  If the phrase
"Destination Address field of the IPv6 header" could justify the
deletion (or even insertion, for that matter) of an EH at a node like
that, then changing this text in 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.

to the above one in RFC8200 shouldn't have caused the painful debate
regarding the implication of SRv6.  We should have known this change
would make the SRv6-style insertion/deletion a violation of the RFC
even more clearly than RFC2460 at that time, and that's why we needed
that discussion.

And that's why I'm surprised at seeing this argument now.  Perhaps
those making this just because they forgot the previous discussion or
simply weren't involved in it.  But combining this point and other
signals that indicate the reluctance to take on the tedious
reconciliation between RFC8200 and this spec (which would be most
likely to require an update to the RFC), it wouldn't be unreasonable
if one suspects it may be an attempt of easily circumventing the
process rather than a genuine misunderstanding of the text.  I guess
this suspicion is somewhat commonly shared by those raising concerns
(including myself).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:31:27 -0300

[....]
> Please do go ahead. I stand by my assessment that this is a misuse of the Errata process and it is not a simple clarification as you claim.

For the third time, may I ask:

Thanks,

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Feb 2020 17:47:49 -0500

Hi Fernando,

> On Feb 27, 2020, at 5:31 PM, Fernando Gont <[email-masked]> wrote:
> 

Personally, it is immaterial what I think as AD but I will answer your question below. The issue I have is you are claiming the WG had consensus on your proposed text while I clearly remember the consensus was extremely tenuous and I cannot make a determination *today* if the WG could have formed consensus around this text at that time. Please do read the shepherd writeup on RFC8200 to see how difficult the current text was to achieve.

> 
> * Does IPv6 support IPv6 header insertion/removal along the packet delivery path?

No. I would not implement that personally as I believe in the strictest reading possible (Postel principle: “Be conservative in what you do…”) but I can see how somebody can have a more liberal interpretation of it.

> 
> * If you assume so, then, How does it play with core IPv6 functionality like:
>    IPsec AH
>    PMTUD
>    error reporting

Thanks
Suresh

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:51:27 -0300

> Correct. This was to clarify the "extension headers are not examined or processed by any node” text in RFC2460 which some people claimed would allow insertion and deletion. And the right way to do…

No. That was menat to clarify that routers don't get to mangle with packets.

Seriously...

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 20:04:32 -0300

On 27/2/20 19:47, Suresh Krishnan wrote:
>> On 27/2/20 19:19, Suresh Krishnan wrote: [....]
>>>> 
>>>> Just to be clear, I believe that your stated decision of
>>>> processing this errata as "Hold for document update" is not
>>>> only incorrect, but also doesn't represent the consensus this
>>>> working group got during the rfc2460bis effort -- now RFC8200.
>>>> 
>>>> It is also unfortunate to have a second instance of this,
>>>> because, at the time the same group was pushing other IPv6
>>>> insertion/removal ideas, I also objected 6man shipping
>>>> rfc2460bis as such. And we only got to improve on that during
>>>> IETF LC.
>>>> 
>>> Please do go ahead. I stand by my assessment that this is a
>>> misuse of the Errata process and it is not a simple clarification
>>> as you claim.
>> 
> Personally, it is immaterial what I think as AD but I will answer
> your question below. The issue I have is you are claiming the WG had
> consensus on your proposed text while I clearly remember the
> consensus was extremely tenuous and I cannot make a determination
> *today* if the WG could have formed consensus around this text at
> that time. Please do read the shepherd writeup on RFC8200 to see how
> difficult the current text was to achieve.

There was IETF-wide consensus regarding the clarification. There were 
folks that meant to pretend that the text was ambiguous, simply to 
prepare some playground for what we are having nowadays.

IPv6 never supported header insertion/removal. So we were not proposing 
new behavior. Just making the existing behavior clear.

> No. I would not implement that personally as I believe in the
> strictest reading possible (Postel principle: “Be conservative in
> what you do…”) but I can see how somebody can have a more liberal
> interpretation of it.

Exactly. In fact, Bob himself noted that a while ago (could dig the 
email archive, if you wish).

NOw, if IPv6 has never meant to support that, and folks pretend to claim 
that it does, the clarification is warranted.

That's what the errata I've submitted is all about.