Subject: Upleveling discussion (was Re: Alvaro Retana's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT))

From: Suresh Krishnan <[email-masked]>
Date: Tue, 11 Apr 2017 04:01:27 +0000

Hi all,
  Since this discussion has started deteriorating into rehashing of previous arguments, I would like to try to take a step back and look at this discussion to see if we can find some common ground. For this I would like to start by providing an example of something that was clearly not allowed in IPv6 (as of RFC2460).

When RFC2460 was written zero UDP checksums were clearly disallowed. See the following text in Section 8.1 of RFC2460

That is, whenever originating a UDP packet, an IPv6 node must compute a UDP
checksum over the packet and the pseudo-header, and, if that
computation yields a result of zero, it must be changed to hex
FFFF for placement in the UDP header.  IPv6 receivers must
discard UDP packets containing a zero checksum, and should log
the error.

A bunch of people felt that this restriction was not always needed in certain limited environments and zero UDP checksums could be made to work well (and even be beneficial) in such environments. They went ahead and wrote up their proposals for the Applicability Statement and the mechanism and these went through the 6man process to update RFC2460

draft-fairhurst-tsvwg-6man-udpzero/draft-ietf-6man-udpzero that became RFC6936 
draft-ietf-6man-udpchecksums became RFC6935 and updated RFC2460 to allow zero UDP checksum in the context of applicability

I am struggling to understand why things are any different now with header insertion. I am expecting the proponents of header insertion to do exactly what the proponents of zero UDP checksums did and do the groundwork for updating RFC2460bis. There is no “speak now or forever hold your peace” moment here. We are not closing off any avenues of future extensibility. The future extensibility proposals will be judged on their own merits. Given that there is existence proof, I would like to better understand why this same strategy will not work in the header insertion case. I believe that would be a good starting point for a constructive discussion going forward.

Thanks
Suresh

P.S.: As an individual contributor, I agree with Alvaro that the text break regarding the exception reduces the readability of the text. I think this is something that can be fixed by rewording as long as we do not reopen all discussions on all topics due to this rewording.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Apr 2017 13:06:45 +0900

On Tue, Apr 11, 2017 at 1:01 PM, Suresh Krishnan <
[email-masked]> wrote:

> I am struggling to understand why things are any different now with header
> insertion. I am expecting the proponents of header insertion to do exactly
> what the proponents of zero UDP checksums did and do the groundwork for
> updating RFC2460bis. There is no “speak now or forever hold your peace”
> moment here. We are not closing off any avenues of future extensibility.
> The future extensibility proposals will be judged on their own merits.
> Given that there is existence proof, I would like to better understand why
> this same strategy will not work in the header insertion case. I believe
> that would be a good starting point for a constructive discussion going
> forward.
>

Hear, hear. Frankly I'm surprised we're even still talking about this.
Anything we'd like to do on this topic is achievable via an update to
whatever document RFC2460bis becomes. The sooner we start work on such an
update, the sooner it will be published.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Apr 2017 13:47:14 +0100

Suresh,

I appreciate your email below, and even agree with it.

My question is: why are we having this dicsussion durig IESG review?

Thanks,
Fernando

On 04/11/2017 05:01 AM, Suresh Krishnan wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2017 01:40:36 +1200

> update, the sooner it will be published.

Violent agreement.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Apr 2017 16:35:06 +0100

>> update, the sooner it will be published.

Agredd. That's why I argue that there's no need for changes to
rfc2460bis as a result of this discussion (except for the clarification
of HBH insertion/delation not being allowed).

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Tue, 11 Apr 2017 11:30:54 -0700

At Tue, 11 Apr 2017 04:01:27 +0000,
Suresh Krishnan <[email-masked]> wrote:

> I am struggling to understand why things are any different now with
> header insertion. I am expecting the proponents of header insertion
> to do exactly what the proponents of zero UDP checksums did and do
> the groundwork for updating RFC2460bis. There is no “speak now or
> forever hold your peace” moment here. We are not closing off any
> avenues of future extensibility. The future extensibility proposals
> will be judged on their own merits. Given that there is existence
> proof, I would like to better understand why this same strategy will
> not work in the header insertion case. I believe that would be a
> good starting point for a constructive discussion going forward.

I personally agree with you, but if I were a "proponent of header
insertion", I might say "the difference from the UDP checksum is that
we're adding new text that explicitly mentions the header insertion
case".  So, assuming we're at least done with "eliminating ambiguity"
itself, I think the main questions are:

- whether we should add any supplemental text to explain that the
  added text in 2460bis is not intended to deny future extensibility
- if so, how we phrase it

Frankly, I don't see the need for the additional explanation (in which
sense I'm with Fernando), but if the "proponents" are so worried about
the new text with a stamp of Internet Standard being interpreted as an
"outright ban", I'm also okay with adding a note as a kind of
compromise for moving forward.  And, in that case, I'm okay with
Brian's proposal, and if it's even considered too vague I'm also okay
with stating it more explicitly.

--
JINMEI, Tatuya

---

From: Tim Chown <[email-masked]>
Date: Wed, 12 Apr 2017 08:37:30 +0000

> On 11 Apr 2017, at 05:06, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Apr 11, 2017 at 1:01 PM, Suresh Krishnan <[email-masked]> wrote:
> Hear, hear. Frankly I'm surprised we're even still talking about this. Anything we'd like to do on this topic is achievable via an update to whatever document RFC2460bis becomes. The sooner we start work on such an update, the sooner it will be published.

Agreed. RFC2460 as it stands has been updated by 9 RFCs in 19 years since publication. And it’s highly probable there will be future updates to the published 2460bis as new IPv6 innovations are defined in the IETF over the coming 5, 10 or 20 years. We don’t now what those innovations are yet, beyond the proposed work on EH insertion, but they will come; 2460bis is not set in stone just because it has an IS stamp on it.

Tim