Subject: RFC2460bis WGLC comments

From: [email-masked]
Date: Wed, 8 Jun 2016 13:43:10 +0200

I have read through the change set and have the following comments:

1. Update reference to working group document:
    [I-D.hinden-6man-rfc4291bis].

2. HBH header handling.

2460bis relaxes the must to a should. And incorporates a paragraph from 7045 giving performance considerations.
The use of a _should_ process combined with a _may_ drop is not elegant.
The second paragraph can also be read as a licence to drop.

After having thought about the text in draft-ietf-6man-hbh-header-handling, I propose the following instead:

OLD:
   The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that should be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv6
   header.

   It should be noted that due to performance restrictions nodes may
   ignore the Hop-by-Hop Option header, drop packets containing a hop-
   by-hop option header, or assign packets containing a hop-by-hop
   option header to a slow processing path.  Designers planning to use a
   hop-by-hop option need to be aware of this likely behaviour.

NEW:
   The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that may be examined
   and processed by nodes along a packet's delivery path, including the
   source and destination nodes.  The Hop-by-Hop Options header, when
   present, must immediately follow the IPv6 header.  Its presence is
   indicated by the value zero in the Next Header field of the IPv6
   header.

   NOTE: While RFC2460 required that all nodes must process the Hop-by-
   Hop Options header, it is now expected that nodes only process the
   Hop-by-Hop Options header if explicitly configured to do so.

In short replace the should we a may, making HBH options header purely optional. Note that section 4.8 in 2460bis already uses a may.
I also suggest we remove the 7045 paragraph on performance considerations, that's highly subjective.

3. Section 4.3 HBH
OLD:
  The Hop-by-Hop Options header is used to carry optional information
   that should be examined by every node along a packet's delivery path.
   The Hop-by-Hop Options header is identified by a Next Header value of
   0 in the IPv6 header, and has the following format:

NEW:
   The Hop-by-Hop Options header is used to carry optional information
   that may be examined by every node along a packet's delivery path.
   The Hop-by-Hop Options header is identified by a Next Header value of
   0 in the IPv6 header, and has the following format:

Same change as above.

4. Fragmentation.

We need more people to review the rewritten fragmentation section.

Are people comfortable with these new names on the parts?

+------------------+-------------------------+---//----------------+
 |  Per-Fragment    | Extension & Upper-Layer |   Fragmentable      |
 |    Headers       |       Headers           |      Part           |
 ------------------+-------------------------+---//----------------+

I kind of think the old terms where clearer, but it might just be what I'm used to.

Ole

---

From: [email-masked]
Date: Wed, 8 Jun 2016 14:01:19 +0200

1.  s/proper MTU/path MTU
In the following paragraph:

           An extension to Path MTU Discovery defined in this document can be
 	   found in [RFC4821].  It defines a method for Packetization Layer Path
 	   MTU Discovery (PLPMTUD) designed for use over paths where delivery of
 	   ICMP messages to a host is not assured.  In this algorithm, the
 	   proper MTU is determined by starting with small packets and probing
 	   with successively larger packets.  The bulk of the algorithm is
 	   implemented above IP, in the transport layer (e.g., TCP) or other
 	   "Packetization Protocol" that is responsible for determining packet
 	   boundaries.

2. ... forwarded by some node (regardless of whether it decrements the Hop Limit) along the path

How can "regardless of whether it decrements the Hop Limit" be misunderstood?
Should a bridge do PMTUD? ;-)

If this is for RFC4389, it is already described there. I do wonder if we should drop this "clarification" from 1981bis as it seems a little 'disclarifying' to me. Albeit correct in the ND proxy case. How did that experiment go btw? ;-)

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2016 11:01:44 +1200

Hi,

On 30/05/2016 20:15, [email-masked] wrote:
> This message starts a two week 6MAN Working Group Last Call on advancing:

Slightly late, here are my comments after re-reading these drafts.
I have systematically reviewed the changes in each version since
this exercise started. Most of my issues have been dealt with in
previous versions, so I don't have much new to say.

One general comment: the authors have chosen to avoid upper case
normative keywords. I understand this choice, but I expect it will be
brought up at IETF Last Call or IESG review by somebody. It will be
worth justifying this choice in the writeup, I think.

...
> Htmlized:    https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-04

I'm happy with this version. I think it expresses the parts of RFC2460 that
have been confirmed to be interoperable by years of running code. There are
still some subtle changes being discussed around extension header insertion and
HbH option processing, however. I think we are very close to consensus now,
but one more release of the I-D is needed for those points.

...
> Htmlized:    https://tools.ietf.org/html/draft-ietf-6man-rfc1981bis-02

I'm happy with this version. I think that the reference to PLPMTUD is
correctly formulated for use in an Internet Standard.

...
> Htmlized:   https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-02

I'm happy with this version. I think it correctly treads a narrow line about
IIDs in a way that is suitable for an Internet Standard.

(I have raised a definitional issue about 'global' scope, but I don't
think the text in 4291bis needs changing because of this.)

However, I believe that we need to get draft-ietf-6man-default-iids
to the IESG at the same time. Having it referenced as a draft in 4291bis
is inappropriate, even though it's informational. If that isn't possible,
I think the reference should be removed.

> as Internet Standards. Substantive comments and statements of support
> for publishing these document should be directed to the mailing
> list. 

So, consider this a statement of support once the minor points mentioned
above have been resolved.

Regards
    Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2016 11:06:29 +1200

Very brief comments in line...

>    Hop-by-Hop Options header if explicitly configured to do so.

wfm

>    0 in the IPv6 header, and has the following format:

wfm

> Are people comfortable with these new names on the parts?

I'm OK with it. Or with the old terms.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2016 11:18:33 +1200

>  	   "Packetization Protocol" that is responsible for determining packet

This use of 'proper' (for 'correct' or 'appropriate') seems natural to
a native English speaker but if it isn't clear, sure, change it.

> Should a bridge do PMTUD? ;-)

Well, if it's bridging a packet from a jumbo frame Ethernet to a 1500 byte Ethernet,
maybe it should? If it's an encapsulator sending to a low-MTU tunnel, without a
suitable adaptation layer, then surely it should. In both cases, it probably won't
decrement the Hop Limit. (Cue Fred Templin.)

> If this is for RFC4389, it is already described there. 

I think that's a corner case.

> I do wonder if we should drop this "clarification" from 1981bis as it seems a little 'disclarifying' to me.

Not to me.

    Brian

> Albeit correct in the ND proxy case. How did that experiment go btw? ;-)
> 
> Ole
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: [email-masked]
Date: Thu, 16 Jun 2016 13:28:16 +0200

Brian,

> a native English speaker but if it isn't clear, sure, change it.

OK, thanks.

> decrement the Hop Limit. (Cue Fred Templin.)

aren't we quite far into layer violations and unspecified behaviour here?
an Ethernet bridge doesn't necessarily even have an IP stack.

in the normal encapsulator case it decrements the hop limit.

I'm still confused exactly what case we're talking about and why this should go into an IS document.

> I think that's a corner case.

well, it is for this corner case we're making the change, no?

>> I do wonder if we should drop this "clarification" from 1981bis as it seems a little 'disclarifying' to me.

cheers,
Ole

---

From: [email-masked]
Date: Thu, 16 Jun 2016 13:30:04 +0200

> I'm OK with it. Or with the old terms.

splendid!
compiling that text with the updating RFCs was apparently quite tedious.
let's stick with the current terms.

Best regards,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 16 Jun 2016 19:44:52 +0000

Hi,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, June 15, 2016 4:19 PM
> To: [email-masked]; 6man WG <[email-masked]>
> Cc: [email-masked]
> Subject: Re: RFC1981bis WCLC comments
> 

I am OK with the final paragraph of RFC1981bis, Section 3 in this regard. I also don't
mind adding "regardless of whether it decrements the Hop Limit".

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jun 2016 13:31:50 +1200

> an Ethernet bridge doesn't necessarily even have an IP stack.

Indeed. Having the parenthesis invites that discussion. Maybe you're right
and these are unnecessary words. I would be 'no objection' either way.

   Brian

---

From: [email-masked]
Date: Mon, 20 Jun 2016 20:34:30 +0200

Thanks a lot Brian.

I have added the reference to default-iid issue to the tracker.
The current list is here:
https://trac.tools.ietf.org/wg/6man/trac/report/1

Let me know if you think there are other outstanding issues that I missed.

Best regards,
Ole

> On 16 Jun 2016, at 01:01, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
>