Subject: Re: Errata 5170, 5171, 5172 on RFC8200

From: Fernando Gont <[email-masked]>
Date: Mon, 5 Aug 2019 19:42:38 +0300

Hi, Bob,

On 31/7/19 04:55, Bob Hinden wrote:
> Hi,
> 
> During the 6man session on Thursday at IETF 105 in Montreal, we presented a proposed solution to Errata 5170, 5171, 5172 that have been filed on the Fragment Header section in RFC8200.   The presentation is available at:
> 
> https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessa-ipv6-rfc8200-fragmentation-errata-00
> 
> The three errata can be found at:
> 
> https://www.rfc-editor.org/errata_search.php?rfc=8200
> 
> The problem indicated in Errata 5170, 5171, 5172 is a real issue with the text in Section 4.5.   As discussed in the 6man session the plan is to update the errata with the corrected text.  The first step is to review the proposed corrected text that was shown in the w.g. session.
> 
> Three files are attached:
> 
> sec4-5-orig.txt                  The original section 4.5 from RFC8200
> sec4-5-new.txt                   The proposed section 4.5 replacement

I reviewed this one.

Some comments:

* Text says:
     The Per-Fragment headers of the reassembled packet consists of all
      headers up to, but not including, the Fragment header of the first
      fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

s/consists/consist/

* Text says:
      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.

s/different fragments/different fragment packets/

Note: I haven't slept well enough (much needed to review a text with
many nuances :-) ), so I will review the text again tomorrow. That said,
two additional comments:

* I'm not sure if "Fragmentable Part" is a good term for coalescing the
(Ext Heeders + ULP header + rest of original packet), since the
requirement in RFC7112 is that the ipv6 header chain is not fragmented.

* This definition:
           Extension headers are all other extension headers that are
           not included in the Per-Fragment headers part of the packet.

..seems to be a circular definition.I suggest to use a modifier for this
EHs, such as "Per Datagram Extension Headers" (no, it doesn't read nice,
but recognizes that both the per-fragment EHs and these other EHs are
*all* EHs). Put another way, in the context of fragmentation, "Extension
Headers" should be used as defined elsewhere in RFC8200, and based on
their position in the packet they can be per-fragment (i.e., each
fragment carries them) or per-datagram (only once per fragmented
datagram) -- one might be tempted to call them "Fragmetable EHs", but
this would be an error, as per the previous bullet.

Thanks!

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 8 Aug 2019 21:53:13 +0200

Hi Fernando,

>      zero), with the following two changes:

I believe the plural "consists" refers to the "Per-Fragment headers" not the packet.

> s/different fragments/different fragment packets/

There is this text above:

"a source node may divide the packet into
 fragments and send each fragment as a separate packet, to be
 reassembled at the receiver."

I think the use of just "fragments" would be consistent with that.

> requirement in RFC7112 is that the ipv6 header chain is not fragmented.

Yes, this part is tricky.
I was thinking of doing bullet 4:
s/The first fragment./The remainder of the first fragment./

> ...seems to be a circular definition.I suggest to use a modifier for this

It's recursive. This is not changed text, only moved.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Aug 2019 13:21:27 +0300

> I believe the plural "consists" refers to the "Per-Fragment headers" not the packet.

Exactly. But "consists" is singula, not plural. :-)  -- hence the
proposed change.

> I think the use of just "fragments" would be consistent with that.

What I've seen all over the fragmentation section is that "fragment"
refers to "chunks of the original packet that are fragmentable". -- look
at the figure for the reassembled packet, for instance.

> s/The first fragment./The remainder of the first fragment./

Yep, but "Fragmentable part" is also used in the figure for the original
packet. -- i.e., I'd consider getting rid of it completely.

RFC2460-wise, the frag mechanism would allow you to fragment anything
part of the fragmentable part. Post 7112, not all that is mechanism-wise
possible to fragment is "fragmentable". So the term is now ambiguous.

> It's recursive. This is not changed text, only moved.

I think the term should be avoided. "Extension Headers" should be used
for, well, all extension headers, as per the registry. For the
per-fragment and per-[whatever] EHs, some other term should be used.

( -- yes, I know what the text means. But I'm not a newcomer to the text).

(Among all the possible options, one option would be to keep the frag
section as in RFC2460, and import the necessary bits from RFC7112. NO
ideal, but does the job)