Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Apr 2017 04:53:13 -0700

On Fri, 14 Apr 2017 14:28:44 +1200 Brian E Carpenter wrote:
>On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:
>...
>>>>>> ----------------------------------------------------------------------
>>>>>> COMMENT:
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> One question because I'm not sure if I interpret this correct to make it
>>>>>> part of my discuss:
>>>>>> Section 4.5: "The number and content of the headers preceding the
>>>>>> Fragment
>>>>>>   header of different fragments of the same original packet may
>>>>>>   differ.  Whatever headers are present, preceding the Fragment
>>>>>>   header in each fragment packet, are processed when the packets
>>>>>>   arrive, prior to queueing the fragments for reassembly.  Only
>>>>>>   those headers in the Offset zero fragment packet are retained in
>>>>>>   the reassembled packet."
>>>>>> Does this mean the ECN codepoint (part of the Traffic Class field) is
>>>>>> copied from the first fragment? This doesn't seem to be correct, however,
>>>>>> also not sure what the correct answer is. I know this was not changed in
>>>>>> this revision but maybe we can still get this right.
>>>>>
>>>>> When fragments are created most of the fields are copied from the IPv6
>>>>> headers (e.g., Source Address, Destination address, flow label, traffic
>>>>> class, hop limit).  Some like payload length, next header, and hop limi
>>>>>t are modified.
>>>>>
>>>>> If I understand your question, the answer is yes, the ECN code point is
>>>>> copied from the first fragment, but should be the same from all of the
>>>>> fragments.

That is inconsistent with the following guidance in RFC 3168 (see
https://tools.ietf.org/html/rfc3168#section-5.3):

5.3.  Fragmentation

   ECN-capable packets MAY have the DF (Don't Fragment) bit set.
   Reassembly of a fragmented packet MUST NOT lose indications of
   congestion.  In other words, if any fragment of an IP packet to be
   reassembled has the CE codepoint set, then one of two actions MUST be
   taken:

      * Set the CE codepoint on the reassembled packet.  However, this
        MUST NOT occur if any of the other fragments contributing to
        this reassembly carries the Not-ECT codepoint.

      * The packet is dropped, instead of being reassembled, for any
        other reason.

   If both actions are applicable, either MAY be chosen.  Reassembly of
   a fragmented packet MUST NOT change the ECN codepoint when all of the
   fragments carry the same codepoint.

>>>> My concern is that the ECN code point could be changed on one of the
>>>> fragmented packets to signal congestion of a intermediate node and
>>>> then when you reassemble this information gets lost. That seems wrong.
>>>
>>> That is an interesting idea, but I think out of scope for advancing this
>>> document to Internet Standard.  Then there is the question of how to
>>> encode n of m fragments experienced congestion.  Interesting future work.
>>
>> Yes there might be some more further work needed but that still makes the
>> guidance in this text wrong. Maybe we can add some text that the Traffic
>> Class may be handled differently because it could be changed on the path.
>
>Good point. It's not only ECN that can change; the DSCP can change too.
>Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical
>for 2460bis to note this issue.

It seems that we (6man WG) missed this because RFC 3168 was not marked
as updating RFC 2460. But in effect it did so for IPv6 implementations
of ECN, even though it was not written in an IP version-agnostic manner.

At the very least text should be added to the description of the
reassembly process that points the reader to RFC 3168 or its
successor document.

Mike Heard

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 15 Apr 2017 15:38:00 +0200

Hi Mike,

thanks a lot! I’ve missed that rfc3168 actually discusses fragmentation. I think in this case it clear what to do for the ECN case. Thanks!

Mirja

> Am 15.04.2017 um 13:53 schrieb C. M. Heard <[email-masked]>:
>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 15 Apr 2017 11:50:44 -0700

Mike,

> On Apr 15, 2017, at 4:53 AM, C. M. Heard <[email-masked]> wrote:
> 

Do we have any evidence that the guidance in RFC 3168 regarding reassembling IPv6 fragments is implemented?  I don’t know, but think if it there is evidence I agree some text should be added to rfc2460bis, if not, then maybe not.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Apr 2017 10:07:25 +1200

> Do we have any evidence that the guidance in RFC 3168 regarding reassembling IPv6 fragments is implemented?  I don’t know, but think if it there is evidence I agree some text should be added to rfc…

In any case, somebody needs to submit an erratum for RFC 3168, since it lacks "Updates: 2460".

Regards
   Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 17 Apr 2017 09:15:19 -0700

On Sat, Apr 15, 2017 at 3:07 PM, Brian E Carpenter wrote:
>> Do we have any evidence that the guidance in RFC 3168 regarding
>> reassembling IPv6 fragments is implemented?  I don’t know, but think if
>> it there is evidence I agree some text should be added to rfc2460bis, if
>> not, then maybe not.
>

I started to do that and then noticed that RFC 3168 also lacks "Updates: 791".
Instead, RFC 3168 updates RFC 2474, which in turn obsoletes RFC 1349, which
in turn updates RFC 791 (and several other IPv4 RFCs). But RFC 2474 itself
lacks "Updates: 2460". So maybe the erratum should be filed against RFC 2474.
On the other hand, all that RFC 2460 Section 7 does with respect to the
Traffic Class field is to define a set of general requirements and defer all
the details to future RFCs. So tt's not clear to me whether RFC 2474 does, in
fact, update RFC 2460. I'll leave the decision on whether to file the erratum
to someone else who has better skills at navigating these tangled webs.

Mike Heard

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Apr 2017 08:21:38 +1200

> to someone else who has better skills at navigating these tangled webs.

RFC 2474 adds to RFC 2460; it doesn't change any of the behaviour defined by
2460, so it isn't IMHO a case for "Updates". If we had a tag "Extends", then
"Extends: 2460" would be appropriate.

RFC 3168 changes the RFC 2460 algorithm for reassembly, so IMHO it's an "Updates: 2460".

    Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 17 Apr 2017 14:20:48 -0700

> RFC 3168 changes the RFC 2460 algorithm for reassembly, so IMHO it's an

I buy that and I just submitted the erratum.

Thanks

//cmh