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

["C. M. Heard" <[e-mail]>]

[ TSVWG added to solicit advice on implementation of RFC 3186 Section 5.3 ]

On Sat, Apr 15, 2017 at 11:50 AM, Bob Hinden wrote:
> On Apr 15, 2017, at 4:53 AM, C. M. Heard <[e-mail]> wrote:
>> 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.
>
> 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.

Since I lack the expertise to answer that question, I'm hoping that someone
in TSVWG will see this message and do so.

Regardless of the answer to that question, my position would be that since
2460bis already defers to RFC 2474 and RFC 3168 regarding the handling of
the Traffic Class field, the following modification to 2460bis Section 4.5
would be an appropriate way to deal with Mirja's comment:

OLD:
      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.
NEW:
      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; however, nodes that support Explicit
      Congestion Notification [RFC3168] may use information in the
      Traffic Class field from all fragment packets to reconstruct the
      Traffic Class field in the reassembled packet.

Note that this would not cause 2460bis itself to levy an additional
requirement on how IPv6 nodes reassemble fragmented packets. It would
simply be making note of a requirement that is already levied by
RFC 3168.

Thanks and regards,

Mike Heard