Subject: [6man] #11 (rfc2460bis): HBH header handling

From: "6man issue tracker" <[email-masked]>
Date: Sun, 12 Jun 2016 18:34:01 -0000

#11: 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.

-- 
----------------------------------+-----------------
 Reporter:  [email-masked]  |      Owner:
     Type:  defect                |     Status:  new
 Priority:  major                 |  Milestone:
Component:  rfc2460bis            |    Version:
 Severity:  In WG Last Call       |   Keywords:
----------------------------------+-----------------

Ticket URL: <https://tools.ietf.org/wg/6man/trac/ticket/11>
6man <https://tools.ietf.org/wg/6man/>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 21 Jun 2016 16:17:25 -0700

Hi,

This proposed change is to make the processing of HBH options optional.  To me this matches what we have in operational practice.  Making that change, reduces the need for the note about some nodes may not processing HBH options.

I support this change.

Comments?

Bob

> On Jun 12, 2016, at 11:34 AM, 6man issue tracker <[email-masked]> wrote:
> 
> #11: HBH header handling
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 21 Jun 2016 23:37:00 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
 
> This proposed change is to make the processing of HBH options optional.  To
> me this matches what we have in operational practice.  Making that change,
> reduces the need for the note about some nodes may not processing HBH
> options.
> 
> I support this change.
> 
> Comments?

I think we should not use "process," but instead "examine and process." Makes it clear that nodes can completely ignore the HBH header, like all the other extension headers.

> >   Hop Options header, which carries information that may be *examined*
NOTE: While RFC2460 required that all nodes must examine the Hop-by-
Hop Options header, it is now expected that nodes only examine the
Hop-by-Hop Options header, and process the packet accordingly,  if
explicitly configured to do so.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 Jun 2016 07:56:04 -0700

Manfredi,

> On Jun 21, 2016, at 4:37 PM, Manfredi, Albert E <[email-masked]> wrote:
> 

I agree, this makes sense, and more consistent with the rest of the text.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jun 2016 14:51:51 +1200

OK for me
   Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 24 Jun 2016 06:36:33 +0000

+1

I think that the whole point is that it is the practice in the real world.

In a RPL domain, RPL nodes are configured to process the HbH header, so the change in the text does not alter the existing practice.

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: vendredi 24 juin 2016 04:52
> To: Bob Hinden <[email-masked]>; [email-masked]
> Subject: Re: [6man] #11 (rfc2460bis): HBH header handling
> 
> OK for me
>    Brian
> >> 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:

---

From: "6man issue tracker" <[email-masked]>
Date: Tue, 28 Jun 2016 22:33:27 -0000

#11: HBH header handling

Comment (by [email-masked]):

 Changes published in draft-ietf-6man-rfc2460bis-05.txt.

-- 
----------------------------------+------------------
 Reporter:  [email-masked]  |       Owner:
     Type:  defect                |      Status:  new
 Priority:  major                 |   Milestone:
Component:  rfc2460bis            |     Version:
 Severity:  In WG Last Call       |  Resolution:
 Keywords:                        |
----------------------------------+------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6man/trac/ticket/11#comment:1>
6man <https://tools.ietf.org/wg/6man/>