Subject: <draft-ietf-6man-rfc2460bis-06.txt>

From: "C. M. Heard" <[email-masked]>
Date: Sat, 17 Sep 2016 18:42:54 -0700

On Tue, 13 Sep 2016 15:12:18 -0700, Bob Hinden wrote:
> I published the -06 version of 6man working group draft of rfc2460bis.
> Links below.
>
> The changes are based on the review by Tim Chown.  Note no changes
> were made regarding Extension Header insertion, this will be covered
> separately in the near future.  The changes in this draft are:
>
>       Added the Routing Header to the list required extension
>       headers that a full implementation includes.
>
>       Moved the text in Section 4.5 regarding the handling of
>       received overlapping fragments to the list of error
>       conditions

I noticed from the diff that only the first of the two paragraphs
dealing with overlapping fragments was moved; the second was not
and is now out of place. Specifically, the paragraph

      It should be noted that fragments may be duplicated in the
      network.  These exact duplicate fragments will be treated as
      overlapping fragments and handled as described in the previous
      paragraph.  An implementation may choose to detect this case
      and not drop the other fragments of the same packet.

near the bottom of page 19 need to be positioned just past the following
paragraph on page 20:

      If any of the fragments being reassembled overlaps with any other
      fragments being reassembled for the same packet, reassembly of
      that packet must be abandoned and all the fragments that have been
      received for that packet must be discarded.

After re-reading the paragraph that I claim should be moved, I find
the wording somewhat awkward ("… will be treated …" is not really
correct if an implementation "… may choose …"). Would it not be
better to say

      It should be noted that fragments may be duplicated in the
      network.  An implementation may choose to detect this case
      and drop exact duplicate fragments while keeping the other
      fragments belonging to the same packet.

>       Rewrote the text in Section 4.8 "Defining New Extension
>       Headers and Options" to be clearer and remove redundant text.

I can live with the new text, but honestly, I liked the old text better.

>       Editorial changes.

In the following reference:

   [I-D.ietf-6man-rfc4291bis]
              Hinden, R. and D. Deering, "IP Version 6 Addressing
              Architecture", draft-ietf-6man-rfc4291bis-03 (work in
              progress), June 2016.

"S. Deering" was erroneously changed to "D. Deering"

Hope this helps. I look forward to seeing the new text for Extension
Header insertion.

Mike Heard

---

From: Bob Hinden <[email-masked]>
Date: Sun, 18 Sep 2016 15:13:45 +0300

Mike,

> On Sep 18, 2016, at 4:42 AM, C. M. Heard <[email-masked]> wrote:
> 

I agree, I missed the “described in the previous paragraph” text when making the change.  I will move that paragraph to the list of errors.  I may format them using numbers or bullets, to make it clearer that the exact duplicate fragments goes with the overlapping text.

>      fragments belonging to the same packet.

How about:

      It should be noted that fragments may be duplicated in the
      network.  Instead of treating these exact duplicate fragments as an
      overlapping fragment, an implementation may choose to detect
      this case and drop exact duplicate fragments while keeping the other
      fragments belonging to the same packet.

> I can live with the new text, but honestly, I liked the old text better.

OK, I could put it back.  Or how about this, a smaller change:

   New hop-by-hop options are not recommended because nodes may be configured
   to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header,
   or assign packets containing a hop-by-hop header to a slow processing path.
   Designers considering defining new hop-by-hop options need to be
   aware of this likely behaviour.  There has to a very clear
   justification why any new hop-by-hop option is needed before it is
   standardized.

   Defining new IPv6 extension headers is not recommended.  There has to a very clear
   justification why any new extension header is needed before it is
   standardized.  Instead of defining new Extension Headers, it is recommended that the
   Destination Options header is used to carry optional information that
   need be examined only by a packet's destination node(s), because they
   provide better handling and backward compatibility.

> "S. Deering" was erroneously changed to "D. Deering”

I noticed that too, I didn’t change anything, so I think there is a bug somewhere regarding references.  I will report it, but am sure it will be fixed when the RFC Editor get it.

> Hope this helps. I look forward to seeing the new text for Extension

Thanks, me too :-)

Bob

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 18 Sep 2016 05:23:23 -0700

Hello Bob,

Thanks for the reply - I like all of your proposed text.

Mike

On Sun, Sep 18, 2016 at 5:13 AM, Bob Hinden <[email-masked]> wrote:

> I agree, I missed the “described in the previous paragraph” text when
> making the change.  I will move that paragraph to the list of errors.  I
> may format them using numbers or bullets, to make it clearer that the exact
> duplicate fragments goes with the overlapping text.
>
> >
> I noticed that too, I didn’t change anything, so I think there is a bug
> somewhere regarding references.  I will report it, but am sure it will be
> fixed when the RFC Editor get it.
>
> >

---

From: Bob Hinden <[email-masked]>
Date: Sun, 18 Sep 2016 15:29:31 +0300

Mike,

Thanks.

BTW, working on the next version, the problem with the reference is gone.  No idea what happened.

Bob

> On Sep 18, 2016, at 3:23 PM, C. M. Heard <[email-masked]> wrote:
> 
> Hello Bob,
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Sep 2016 11:37:23 +0000

I agree the new text on EHs looks ok.

One might argue that the "No new extension headers that require hop-by-hop behavior should be defined“ at the start of 4.8 should instead say “must be defined”, to be consistent with "New IPv6 extension header(s) having hop-by-hop behavior MUST NOT be created or specified“ in Section 3 of RFC6564.

I noticed in cross-checking that RFC6564 refers to [IANA_IP_PARAM], or http://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml, while 2460-bis refers to [IANA-PN], or https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml for the possible Next Header values in the Uniform IPv6 EH defined in RFC6564, and described in Section 4.8 of 2460-bis. So does RFC6564 need an Errata?

(I’d also argue that RFC6564 should be cited in 4.8, but that’s a separate question of consistency in references.)

Tim

On 18 Sep 2016, at 13:23, C. M. Heard <[email-masked]<mailto:[email-masked]>> wrote:

Hello Bob,

Mike

On Sun, Sep 18, 2016 at 5:13 AM, Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
Mike,

> On Sep 18, 2016, at 4:42 AM, C. M. Heard <[email-masked]<mailto:[email-masked]>> wrote:
>

How about:

Thanks, me too :-)

Bob

> Mike Heard

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Sep 2016 15:20:21 +0300

Tim,

> On Sep 19, 2016, at 2:37 PM, Tim Chown <[email-masked]> wrote:
> 

How about:

      New extension headers that require hop-by-hop behavior must not
      be defined because as specified in Section 4 of this document, the
      only Extension Header that has hop-by-hop behavior is the
      Hop-by-Hop Options header.

> I noticed in cross-checking that RFC6564 refers to [IANA_IP_PARAM], or http://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml, while 2460-bis refers to [IANA-PN], or https://www.iana.org…

I agree, it seems that the reference in RFC6564 is pointing to the wrong IANA registry.

Thanks,
Bob

>> On 18 Sep 2016, at 13:23, C. M. Heard <[email-masked]> wrote:
>> 
>> Hello Bob,
>> 
>> [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Tue, 20 Sep 2016 13:05:00 +0000

Hi,

> On 20 Sep 2016, at 13:20, Bob Hinden <[email-masked]> wrote:
> 
> Tim,
> 

Looks fine, and more consistent with RFC6564.

> I agree, it seems that the reference in RFC6564 is pointing to the wrong IANA registry.

OK, I’ll put an errata in, as minor as it is.

Tim

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Sep 2016 23:32:18 +0300

Tim,

> On Sep 20, 2016, at 4:05 PM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 

Good.

> OK, I’ll put an errata in, as minor as it is.

Perhaps check with the authors first to try to figure out what happened.

Bob