Subject: Errata on EH-processing (bis)

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 03:01:45 -0300

Folks,

Once errata 5933 had been announced on this mailing list (Dec 2019), 
some of you catched other bugs in the original text from RFC8200, and 
also made other proposals to improve the text I had crafted.

I took a look at our discussions, and came up with a more polished 
proposal to replace the discussion on EH-processing in Section 4 of RFC8200:

The text is as follows:
---- cut here ----
    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 origin 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.
---- cut here ----

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.

Comments & corrections are welcome.

Thanks!

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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 2 Mar 2020 11:23:17 -0500

<no hats>
While I agree that the text in RFC8200 is problematic (well, duh!),
and that clarifications are *dearly* needed I don't think that it is
appropriate to be done as an Errata, without clear consensus on the
change.

"These are strong guidelines and not immutable rules. Common sense and
good judgment should be used by the IESG to decide what is the right
thing to do. Errata are meant to fix "bugs" in the specification and
should not be used to change what the community meant when it approved
the RFC. "
and:
"7. 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 must admit that I was not carefully following all of the discussions
around this test when it was approved, but I don't know that the
consensus was *clearly* what you have documented (I think it should
have been, and that other interpretations are wrong, but that is my
*opinion*).

ADs are supposed to use judgement, and "do the right thing", but also
must not use their power to change / override WG consensus - ADs are
servants of the community / process, not rulers.

As this is (IMO) more than just a simple clarification, and as there
is not full agreement (AFAICT!), if I were the responsible AD[0], I
would:
1: want this done as a -bis / update to the RFC (gulp) or
2: if processing it as an Errata, ask the WG / WG chairs to declare
consensus, and then clearly document this in the notes field of the
Errata.

W
[0]: ... and every morning, when waking up and rolling over, the first
thing out of my mouth is: "Thank the gods that I'm not Suresh... oh,
or responsible for 6MAN / RFC8200"... :-P

</no-hats>

On Mon, Mar 2, 2020 at 1:03 AM Fernando Gont <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 13:46:35 -0300

Warren,

> changes can be Hold for Document Update. "

If this erratum would need consensus because it is a change to the 
intended consensus, then the obvious questions to respond are:

* What is this document changing?
* What was the intended consensus?

With respect to eh insertion/removal, this document clarifies that it is 
forbidden. Then, if this is seen as a change in the spirit of the spec, 
it follows that the assumption is that such behavior is *allowed* in 
RFC8200.

If it was indeeed allowed, may I ask:
* How does PMTUD work?
* How does IPsec AH work?
* How does error reporting work?

Because if RFC8200 doesn't explain that (which it doesn't), then it 
couldn't possibly allow such behavior.

(Put another way, I'm trying to figure out what's your logic here)

> have been, and that other interpretations are wrong, but that is my

The consensus was indeed to clarify that en-route eh-insertion/removal 
was forbidden. That's even stated in Appendix B.

Of course, I can't (and wouldn't) claim that the wg had consensus on the 
exact wording I used in my erratum. -- but that's also the case any 
erratum that is approved (e.g., https://www.rfc-editor.org/errata/eid5945)

> consensus, and then clearly document this in the notes field of the

Let's, for the sake of argument consider this:
We have a broken specification when it comes to EH processing (as noted, 
it's not only the EH-insertion part, but there are others). Let's assume 
that there was a consensus call, and there was no consensus?  So what? 
Broken spec forever?

(I do agree this should be the desired outcome if fixing the spec would 
require a change. BUt I don't think this would be the desired outcome 
when the intent of the wg was clear, but we just crafted sloppy text in 
the spec.

Thanks,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 2 Mar 2020 16:51:24 +0000

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Warren Kumari <[email-masked]>
   <no-hats>

  ...%<....%<....
    
    </no-hats>

At least some humor in this heavy discussion ;-)

More seriously, ***and without any hat***, when the 2460-bis was discussed, I remember that there were a lot of discussions around the 'infamous' paragraph even if that was for real inflight insertion/deletion (i.e. even between two segments in the RH and not only at the DA/segment hop), so, this topic was heavily discussed and the last calls ended with the current text.

All RFC can be updated of course based on the community requests but fixing the "infamous" paragraph via an errata sounds really a bad idea to me.

Finally, I am sure that all members of this 6MAN WG want both to prevent the Internet ossification and keep it running (sometimes those two objectives contradict each other).

Regards

-éric

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 14:02:05 -0300

On 2/3/20 13:51, Eric Vyncke (evyncke) wrote:
> More seriously, ***and without any hat***, when the 2460-bis was discussed, I remember that there were a lot of discussions around the 'infamous' paragraph even if that was for real inflight insertion/deletion (i.e. even between two segments in the RH and not only at the DA/segment hop), 

Well, routing headers are specified as:

    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.

so any insertion/deletion you do anywhere other than the final 
destination (which is the only thing considered "destination" in the 
aforementioned text) is real in-flight insertion/deletion ;-)

> so, this topic was heavily discussed and the last calls ended with the current text.

FWIW, IIRC, the text itself wasn't subject of as much discussion, since 
it was crafted as a result of IETF LC.

(a lesson from rfc8200 is that reviewing diffs as opposed to complete 
re-reads does not work that well. And that you need to be able to look 
at the document with fresh eyes in order to spot problems.)

Cheers,

---

From: John Scudder <[email-masked]>
Date: Mon, 2 Mar 2020 17:16:25 +0000

Hi Eric,

> On Mar 2, 2020, at 11:52 AM, Eric Vyncke (evyncke) <evyncke=[email-masked]> wrote:
> 

I don’t see how this remark relates to the rest of the conversation. Can you elucidate?

Thanks,

—John

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 14:27:45 -0300

> I don’t see how this remark relates to the rest of the conversation. Can you elucidate?

My try: when you encourage middleboxes to mangle with packets, and they 
really screw up, then only a very limited subset of protocols/features 
work properly, and you have no other choice that rely only on them.

So if we're into the game of encouraging middleboxes such as 
SRv6-routers to mangle with packets, we're probably well on the way to 
ossification ;-)

---

From: Mike Simpson <[email-masked]>
Date: Mon, 2 Mar 2020 20:22:09 +0000

Ok but (inline)

> On 2 Mar 2020, at 16:24, Warren Kumari <[email-masked]> wrote:
> 
> <no hats>

There clearly are bugs in the document because on reading them closely, every few years, an engineering group decides that rather than encapsulate the native packet in whatever new layer 3 they are using, they can save a minuscule amount of bytes by mangling the native packet at some point in its journey instead. 

This is problematic for reasons well versed but the argument recurs. 

So the spec is meant to not be equivocal yet the evidence is that it can be read as such. 

> changes can be Hold for Document Update. "

This doesn’t modify the existing protocol. The people looking to use EH insertion/deletion in flight are looking to modify the working of the protocol. This just tightens the specification in order to meet both the criteria of end to end with AH/no fragmentation by routers and also to reflect the expected behaviour of the millions of boxes using or passing ipv6 now for quite some time. 

> have been, and that other interpretations are wrong, but that is my

And had the people involved at the time when so much thought had gone into countering the extra header hell of ipv4 known that this would come up then I suspect the wording of the paragraphs in question would be what Fernando is proposing. 

> consensus, and then clearly document this in the notes field of the

1 would seem more likely to allow for interested parties to try and put their thumb on the scale. The threads are long now, I can’t imagine the stuff that would come up as an update discussion. Maybe the “why 128b for address” will come back...

Seriously, it seems that the original ipv6 discussion is no longer within the Institutional memory of the vendor world so an update to RFC8200 at this point would be both torturous and unhelpful for those with ipv6 deployed. 

> or responsible for 6MAN / RFC8200"... :-P

Good opportunity to close that bug in the spec that seems to entice people away from just going with encap/decap. 

Pretty certain it would brighten all our days :)

Mike

---

From: John Scudder <[email-masked]>
Date: Mon, 2 Mar 2020 20:46:25 +0000

Hi Mike,

On Mar 2, 2020, at 3:22 PM, Mike Simpson <[email-masked]<mailto:[email-masked]>> wrote:

1 would seem more likely to allow for interested parties to try and put their thumb on the scale. The threads are long now, I can’t imagine the stuff that would come up as an update discussion. Maybe the “why 128b for address” will come back…

That might happen with a bis, which I imagine is why Warren included the “/ update to the RFC” option as well. It’s entirely feasible to publish and (attempt to) progress a small spec that’s substantially the same as the proposed erratum, but in I-D/RFC form that updates 8200. I can point to various worked examples. It’s less desirable than a bis in some ways since it leads to a larger document set, but it does make it possible to avoid scope creep.

Regards,

—John

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 18:11:44 -0300

On 2/3/20 17:46, John Scudder wrote:
>> 1 would seem more likely to allow for interested parties to try and 
>> put their thumb on the scale. The threads are long now, I can’t 
>> imagine the stuff that would come up as an update discussion. Maybe 
>> the “why 128b for address” will come back…
> 
> That might happen with a bis, which I imagine is why Warren included the 
> “/ update to the RFC” option as well. It’s entirely feasible to publish 
> and (attempt to) progress a small spec that’s substantially the same as 
> the proposed erratum, but in I-D/RFC form that updates 8200. I can point 
> to various worked examples. It’s less desirable than a bis in some ways 
> since it leads to a larger document set, but it does make it possible to 
> avoid scope creep.

It certainly could. However, if the erratum respects the spirit of the 
spec, I don't think that's actually needed.

In fact, the whole fragmentation section of RFC8200 with an errata (see: 
https://www.rfc-editor.org/errata/eid5945). So I'm not sure why we 
should proceed differently in this case.

Thanks,