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

["Pascal Thubert (pthubert)" <[e-mail]>]

+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

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> Sent: vendredi 24 juin 2016 04:52
> To: Bob Hinden <[e-mail]>; [e-mail]
> Subject: Re: [6man] #11 (rfc2460bis): HBH header handling
> 
> OK for me
>    Brian
> On 22/06/2016 11:17, Bob Hinden wrote:
> > 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
> <[e-mail]> wrote:
> >>
> >> #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:  [e-mail]  |      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/>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------