Subject: Review of draft-ietf-6man-hbh-header-handling-01

From: Fernando Gont <[email-masked]>
Date: Fri, 4 Mar 2016 05:26:58 -0300

Hi Fred & Ron,

Some quick comments:

** Technical **

* Section 2, page 4:
>    o  REQ1: Implementations MUST NOT discard otherwise forwardable
>       packets because the contain the HBH Options Extension header.
>       While an implementation MAY be configured to discard packets
>       containing the HBH Options Extension Header, this MUST NOT be the
>       default behavior.

It would seem that you should remove the first sentence of this para?

* Section 2, page 5:
>    o  REQ 3: If an implementation receives a packet that contains
>       multiple unrecognized HBH Options, and at least one of those
>       unrecognized options contains a Type indicator whose first two bit
>       are 01, the implementation MUST discard the packet, without
>       sending an ICMP message.  The implementation MUST NOT send an ICMP
>       message, even if one of the other unrecognized options contains a
>       Type indicator that begins with 10 or 11.

This would mean that a router that already knows that must discard the
packet ('cause of an unrecognized option), should possibly need to
continue scanning  the options such that, if one of them would mean
"silently" drop, no icmp messages should generated.
Question: is this what you meant? Does it make sense to require more
work when the router already knows it has to discard the packet?

(I'm not necessarily arguing against this, but rather that you should
probably provide the rationale for this behavior)

* Section 2, page 5:
>    o  REQ 4: Implementations MUST protect themselves against denial of
>       service attack against the control plane are propagated through
>       HBH Options.  These protections MUST be enabled by default,
>       without special configuration.
> 
>    o  REQ 5: Implementations MUST protect themselves against denial of
>       service attack against the control plane are propagated through
>       HBH Options.  These protections MAY require special configuration.

These two contradict each other. (edit error?)

* Section 2, page 5:
>    o  REQ 8: The HBH Options Extension Header can contain as many as
>       2056 bytes.  Some implementation are not capable of processing
>       extension headers of that length.  When an implementation receives
>       a packet that it cannot process due to its HBH Options Extension
>       Header length, the implementation MUST discard the packet and send
>       an ICMP Parameter Problem message the packet source.  ICMP
>       Parameter Problem Code MUST be "Long Extension Header" (value TBD)
>       and the ICMP Parameter Problem Pointer MUST contain the offset of
>       HBH Options Extension Header.

Actually, this may become a problem for headers much smaller than 2056
bytes (e.g. larger than 128 bytes). You may want to reference
draft-gont-v6ops-ipv6-ehs-packet-drops here.

* Section 3, page 6:
>    Having received a packet containing the HBH Options Extension header,
>    the forwarding plane determines whether the HBH Options Extension
>    Header is too long for it to process.  If so, the forwarding plane
>    discards the packet and sends an ICMP Parameter Problem message to
>    the packet source.  ICMP Parameter Problem Code is set to "Long
>    Extension Header" and the ICMP Parameter Problem Pointer is set to
>    the offset of HBH Options Extension Header.

I'm with you here. However, this is something that is not unique for HBH
(see draft-gont-v6ops-ipv6-ehs-packet-drops).

* Appendix A, page 9:
>       The content of this document is likely to be subsumed into 2460bis
>       [I-D.ietf-6man-rfc2460bis], but is held separate for the present
>       discussion.

This would be odd.

** Editorial **

* Section 1, page 3:
> In order to protect scarce control plane
>    resources, these routers enforce policies the restrict access from
>    the from the forwarding plane to the control plane.

Remove duplicated instance of "from the"

* SEction 1, page 3:
> Effective
>    policies address packets containing the HBH Options Extension header,
>    because HBH control options require access from the forwarding lane
>    to the control plane.

s/lane/plane/

* Section 1 page 3:
s/DOS/DoS/

* Section 2, page 5:
>    o  REQ 4: Implementations MUST protect themselves against denial of
>       service attack against the control plane are propagated through
>       HBH Options.  These protections MUST be enabled by default,
>       without special configuration.

s/are/that are/?

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Mar 2016 11:08:22 +1300

On 04/03/2016 21:26, Fernando Gont wrote:
...
>>       containing the HBH Options Extension Header, this MUST NOT be the

I don't think that's the right fix, but these two sentences are somewhat
contradictory. Is this what the authors intended?

o REQ1: Implementations MUST NOT be configured by default
  to discard otherwise forwardable packets because they contain
  the HBH Options Extension header. However, an implementation
  MAY have a configuration option to discard packets containing
  the HBH Options Extension Header.

This, BTW, means that the statement in RFC 7045 quoted in the draft
will remain true. So I am not sure why this draft formally updates 7045.

Also, I would suggest sequencing this draft to come out *after* 2460bis.
It might have the distinction of being the first RFC to update 2460bis.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 5 Mar 2016 02:55:37 -0300

> It might have the distinction of being the first RFC to update 2460bis.

Not that I like to point this out, but...
One one hand, if we're working on rfc2460bis, then one would argue that
if we're to intentionally stall draft-ietf-6man-hbh-header-handling so
that it gets published after rfc2460bis, then why not incorporate it in
rfc2460bis?

I'd expect that this doc is published soon & as is: It updates
RFC2460... and then rfc2460bis picks RFC2460 plus updates.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 6 Mar 2016 22:33:49 +0000

Something to discuss wth the chairs, I suppose. The first question is whether 2460bis is ready about when it is, or one is later.

I'd like to believe this is close to done, and I suspect Bob would like to believe 2460bis is close to done.... If so, the chairs may prefer to somehow incorporate it into 2460bis and ship it.

> On Mar 5, 2016, at 6:55 AM, Fernando Gont <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 7 Mar 2016 17:06:36 +1300

> I'd like to believe this is close to done, and I suspect Bob would like to believe 2460bis is close to done.... If so, the chairs may prefer to somehow incorporate it into 2460bis and ship it.

I don't see that happening, because 2460bis is supposed to be aimed at
Internet Standard status and that requires solid operational experience
for all features. hbh-header-handling is some years from that situation,
unfortunately. So I can only see it as a Proposed Standard update
to the future Internet Standard.

(You may recall draft-loughney-newtrk-one-size-fits-all. I always
thought that would have saved us a lot of bureaucracy.)

   Brian

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 7 Mar 2016 15:19:18 +0000

Hi Fernando,

Thanks for the careful review. All good catches. Details inline.

              Ron

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Friday, March 04, 2016 3:27 AM
> Cc: [email-masked]; [email-masked]
> Subject: Review of draft-ietf-6man-hbh-header-handling-01
> 
> Hi Fred & Ron,
> 
> Some quick comments:
> 
> ** Technical **
> 
> * Section 2, page 4:

Good point. In an effort to be clear, I repeated myself.

> packet ('cause of an unrecognized option), should possibly need to continue
> scanning  the options such that, if one of them would mean "silently" drop,
> no icmp messages should generated.
> Question: is this what you meant? Does it make sense to require more work
> when the router already knows it has to discard the packet?
> 
> (I'm not necessarily arguing against this, but rather that you should probably
> provide the rationale for this behavior)

Yes, this is exactly what I mean. Let's say an implementation receives a packet two HBH Options. One begins with 01 and the other begins with 10. The implementation MUST drop the packet without sending an ICMP message. It MUST do this, regardless of which HBH option came first.

Yes, this does mean more work, but guarantees the semantics of the 01.

> These two contradict each other. (edit error?)

Yikes. Late night cloning error. REQ 4 should say, "Implementations MUST protect themselves against denial of  service attack against the *forwarding* plane that are propagated through HBH Options."

> bytes (e.g. larger than 128 bytes). You may want to reference draft-gont-
> v6ops-ipv6-ehs-packet-drops here.
> 
> 

Way shorter than 2056! I will included a reference to packet drops.

> I'm with you here. However, this is something that is not unique for HBH (see
> draft-gont-v6ops-ipv6-ehs-packet-drops).
> 

Agree. This is not unique to HBH. But the scope of this document is limited to HBH.

> >       [I-D.ietf-6man-rfc2460bis], but is held separate for the present

I have no preference, one way or the other.
> ** Editorial **

All good catches. Thanks.

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

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 7 Mar 2016 22:43:46 +0000

Brian,

That's OK by me.

                         Ron

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Sunday, March 06, 2016 11:07 PM
> To: Fred Baker (fred) <[email-masked]>; Fernando Gont
> <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: Review of draft-ietf-6man-hbh-header-handling-01
> 
> > Something to discuss wth the chairs, I suppose. The first question is
> whether 2460bis is ready about when it is, or one is later.
> >
> > I'd like to believe this is close to done, and I suspect Bob would like to
> believe 2460bis is close to done.... If so, the chairs may prefer to somehow
> incorporate it into 2460bis and ship it.
> 
> Internet Standard status and that requires solid operational experience for all
> features. hbh-header-handling is some years from that situation,
> unfortunately. So I can only see it as a Proposed Standard update to the
> future Internet Standard.
> 
> (You may recall draft-loughney-newtrk-one-size-fits-all. I always thought that
> would have saved us a lot of bureaucracy.)
> 
>    Brian
> 
> >> One one hand, if we're working on rfc2460bis, then one would argue
> >> that if we're to intentionally stall
> >> draft-ietf-6man-hbh-header-handling so that it gets published after
> >> rfc2460bis, then why not incorporate it in rfc2460bis?
> >>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Mar 2016 04:42:19 -0300

On 03/07/2016 12:19 PM, Ronald Bonica wrote:
>>> unrecognized options contains a Type indicator whose first two
>>> bit are 01, the implementation MUST discard the packet, without 
>>> message, even if one of the other unrecognized options contains
>>> a Type indicator that begins with 10 or 11.
>> 
>> This would mean that a router that already knows that must discard
>> the packet ('cause of an unrecognized option), should possibly need
>> to continue scanning  the options such that, if one of them would
>> mean "silently" drop, no icmp messages should generated. Question:
>> is this what you meant? Does it make sense to require more work 
>> (I'm not necessarily arguing against this, but rather that you
>> should probably provide the rationale for this behavior)
> 
> Yes, this is exactly what I mean. Let's say an implementation
> receives a packet two HBH Options. One begins with 01 and the other
> begins with 10. The implementation MUST drop the packet without
> sending an ICMP message. It MUST do this, regardless of which HBH
> option came first.
> 

BUt aren't you violating the semantics of 10 if you continue processing
(I assume 10= drop without ICMP, since I'm not looking at RFC2460 right
now).

>> * Section 3, page 6:
>>> Having received a packet containing the HBH Options Extension
>>> header, the forwarding plane determines whether the HBH Options
>>> Extension Header is too long for it to process.  If so, the
>>> forwarding plane discards the packet and sends an ICMP Parameter
>>> Problem message to the packet source.  ICMP Parameter Problem
>>> Code is set to "Long Extension Header" and the ICMP Parameter
>>> Problem Pointer is set to the offset of HBH Options Extension
>>> Header.
>> 
>> I'm with you here. However, this is something that is not unique
>> for HBH (see draft-gont-v6ops-ipv6-ehs-packet-drops).
>> 
> 

What I mean is this is, again, an indication that some version of this
is needed. I don't oppose to saying this here. I just wonder if this
isn't an indication that we should revive any of the efforts to cap the
EH chain length.

Thanks!

Best regards,

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 10 Mar 2016 12:33:12 +0000

Hi Fernando,

This is a very substantive question. I will rephrase it, hoping to get others to speak up. We should also raise the issue in Buenos Aires.

Assume that a node receives a packet containing an HBH Extension Header. The Header contains two unrecognized HBH Options. One begins with 01 and the other begins with 10. As 2460 is written, if the option that begins with 01 comes first, the node MUST NOT send and ICMP message. However, if the option that begins with 10 comes first, the node MUST send an ICMP message. 

The current draft says that the 10 takes precedence over the 01.  So, the node MUST NOT send an ICMP message, regardless of the ordering of options inside of the HBH header.

Which behavior does the WG really want?

                                        Ron

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Tuesday, March 08, 2016 2:42 AM
> To: Ronald Bonica <[email-masked]>
> >>> are 01, the implementation MUST discard the packet, without sending
> >>> an ICMP message.  The implementation MUST NOT send an
> >> ICMP
> >> is this what you meant? Does it make sense to require more work when
> >> the router already knows it has to discard the packet?
> >>
> > Yes, this is exactly what I mean. Let's say an implementation receives
> > a packet two HBH Options. One begins with 01 and the other begins with
> > 10. The implementation MUST drop the packet without sending an ICMP
> > message. It MUST do this, regardless of which HBH option came first.
> >
> BUt aren't you violating the semantics of 10 if you continue processing (I
> assume 10= drop without ICMP, since I'm not looking at RFC2460 right now).
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 10 Mar 2016 10:31:22 -0800

At Thu, 10 Mar 2016 12:33:12 +0000,
Ronald Bonica <[email-masked]> wrote:

> This is a very substantive question. I will rephrase it, hoping to
> get others to speak up. We should also raise the issue in Buenos
> Aires.

> Assume that a node receives a packet containing an HBH Extension
> Header. The Header contains two unrecognized HBH Options. One begins
> with 01 and the other begins with 10. As 2460 is written, if the
> option that begins with 01 comes first, the node MUST NOT send and
> ICMP message. However, if the option that begins with 10 comes
> first, the node MUST send an ICMP message.

> The current draft says that the 10 takes precedence over the 01.

You should mean the 01 (=no ICMP) takes precedence over the 10 (=send
ICMP), or for that matter, over the 11.

> So, the node MUST NOT send an ICMP message, regardless of the
> ordering of options inside of the HBH header.

> Which behavior does the WG really want?

I don't have a strong opinion (yet), but I'd first like to understand
why you introduced this change.

> > > Yes, this does mean more work, but guarantees the semantics of the 01.

If this is the reason, the main question is whether which makes more
sense between guaranteeing the semantics of the 01 and guaranteeing
the semantics of the 10, right?  In that sense I guess the latter (the
RFC2460 way) is safer and therefore makes more sense - if the option
expects an ICMP error when it's not recognized, I'd assume that it
*explicitly* means receiving the ICMP at the sender has some critical
role in handling that option beyond a mere diagnostic purpose.

On the other hand, guaranteeing the semantics of the 01 doesn't seem
to be less critical for the protocol to work - it would simply result
in some additional ICMP messages (which are rate limited).  Except for
the overhead of the router, of course - is that perhaps the main
reason why you wanted to make this change?

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Mar 2016 05:18:22 -0300

Hi, Ron,

On 03/10/2016 09:33 AM, Ronald Bonica wrote:
> ICMP message. However, if the option that begins with 10 comes first,
> the node MUST send an ICMP message.
> 
> The current draft says that the 10 takes precedence over the 01.  So,
> the node MUST NOT send an ICMP message, regardless of the ordering of
> options inside of the HBH header.
> 

My take: Act according to the first unrecognized option that mandates
that the packet should be dropped. If such option says that you should
silently drop the packet, then do so regardless of whether a subsequent
unrecognized option says "drop with ICMPv6 message".

Thanks!

Cheers,

---

From: [email-masked]
Date: Fri, 11 Mar 2016 13:32:45 +0100

Ron,

> Assume that a node receives a packet containing an HBH Extension Header. The Header contains two unrecognized HBH Options. One begins with 01 and the other begins with 10. As 2460 is written, if th…

the 2460 text does not say "MUST NOT".

the purpose of this mechanism (10&11) is for a sender to detect if a particular HBH option is supported by all the nodes towards the destination. by setting the flags the sender of a particular option requests nodes to report back. aka capability detection.
the flags are per option and independent of each other.

as far as I'm concerned there is no conflict here.

if 10/11 is set on any option then ICMP is sent back (assuming unicast), regardless of the flags on any other option.

Best regards,
Ole

---

From: [email-masked]
Date: Fri, 11 Mar 2016 13:48:15 +0100

[Moving to the correct mailing list [email-masked]]

<implementors hat on>

> Which behavior does the WG really want?

I wonder if we should take a step back and look at the benefit of mandatory options and the "reporting back" functionality of HBH.
Is that functionality used? Is it deployable?

The current option definition requires every node on the path to parse the extension header. Also nodes that do not support any HBH options. I suggest we change that, essentially making all options have flags 00.

For the particular implementation I'm looking at (VPP / fd.io), looking even one cache-line further into the packet has a significant cost.

Best regards,
Ole

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 12 Mar 2016 21:57:10 +0000

Ole,

I that case, REQ 8 in draft-ietf-6man-hbh-header-handling has it exactly backwards. If the WG agrees, I would be glad to change REQ 8.

Whatever we decide, I think we need to spell it out explicitly.

                                                           Ron

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, March 11, 2016 7:33 AM
> Cc: Fernando Gont <[email-masked]>; [email-masked]; draft-ietf-
> [email-masked]
> > This is a very substantive question. I will rephrase it, hoping to get others to
> speak up. We should also raise the issue in Buenos Aires.
> >
> > Assume that a node receives a packet containing an HBH Extension Header.
> The Header contains two unrecognized HBH Options. One begins with 01 and
> the other begins with 10. As 2460 is written, if the option that begins with 01
> comes first, the node MUST NOT send and ICMP message. However, if the
> option that begins with 10 comes first, the node MUST send an ICMP
> message.
> 
> the purpose of this mechanism (10&11) is for a sender to detect if a particular
> HBH option is supported by all the nodes towards the destination. by setting
> the flags the sender of a particular option requests nodes to report back. aka
> capability detection.
> if 10/11 is set on any option then ICMP is sent back (assuming unicast),
> regardless of the flags on any other option.
> 
> Best regards,
> Ole
>

---

From: [email-masked]
Date: Mon, 21 Mar 2016 23:33:26 +0100

Ron,

> Whatever we decide, I think we need to spell it out explicitly.

agree. with an implementor hat on, I'd very much like to only have to look inside HBH _iff_ the implementation has explicitly been configured to do so. doing that should make HBH much less objectionable. (and probably mimics what's deployed)

it would require some changes to 2460bis. anyone ever heard of an HBH option that require the "this option is mandatory by all routers on the path"?

Best regards,
Ole

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 21 Mar 2016 22:44:47 +0000

Hi Ole,

Please take a look at version 3 of the draft. I think I finally got it right ;-)

Also, it was REQ 3, not REQ 8.

                                          Ron

P.S. I think that RSVP-TE breaks if some routers along the path ignore the router alert option. This is strange, because the first two bits of the router alert option are 00.

> Sent: Monday, March 21, 2016 6:33 PM
> > I that case, REQ 8 in draft-ietf-6man-hbh-header-handling has it exactly
> backwards. If the WG agrees, I would be glad to change REQ 8.
> >
> agree. with an implementor hat on, I'd very much like to only have to look
> inside HBH _iff_ the implementation has explicitly been configured to do so.
> doing that should make HBH much less objectionable. (and probably mimics
> what's deployed)
> 
> it would require some changes to 2460bis. anyone ever heard of an HBH
> option that require the "this option is mandatory by all routers on the path"?
> 
> Best regards,
> Ole
> 
> >
> >>> get others to
> >> The Header contains two unrecognized HBH Options. One begins with 01
> >> and the other begins with 10. As 2460 is written, if the option that
> >> begins with 01 comes first, the node MUST NOT send and ICMP message.
> >> However, if the option that begins with 10 comes first, the node MUST
> >> send an ICMP message.
> >>
> >> the purpose of this mechanism (10&11) is for a sender to detect if a
> >> particular HBH option is supported by all the nodes towards the
> >> destination. by setting the flags the sender of a particular option
> >> requests nodes to report back. aka capability detection.
> >> if 10/11 is set on any option then ICMP is sent back (assuming
> >> unicast), regardless of the flags on any other option.
> >>
> >> Best regards,
> >> Ole
> >>

---

From: [email-masked]
Date: Tue, 22 Mar 2016 00:13:41 +0100

Ron,

> Please take a look at version 3 of the draft. I think I finally got it right ;-)

looking... you are making a much stronger statement about HBH processing than 2460bis.
I'm more in favour of relaxing the HBH requirements. i.e. the opposite position of what the document takes.

e.g. I would say something like:

REQ 1: An implementation MAY NOT need to examine or process the Hop-by-Hop Options header unless explicitly configured to do so.

with regards to REQ-3, I still think the options should be treated independently, not sequentially.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2016 13:14:49 +1300

On 22/03/2016 11:33, [email-masked] wrote:
> it would require some changes to 2460bis. 

No, please, no. 2460bis picked up some text from 7045 and describes the currently
deployed version of IPv6 accurately. Thus, it is the appropriate text for
an Internet Standard.

If you want to change it, that will be a PS that comes logically *after*
the future IS 2460bis.

> anyone ever heard of an HBH option that require the "this option is mandatory by all routers on the path"?

Not hardly ;-). 2460 doesn't say that or imply it; what it does say is that all
routers must look at the HbH header, and that is what 7045 and 2460bis relax.

    Brian

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 22 Mar 2016 00:59:27 +0000

Ole,

Let's break this down by asking a series of yes/no questions:

1) Having received a packet that contains the HBH Options Extension Header, does an implementation that recognizes at least one HBH Option need to examine the options contained by the header? (y/n)
2) Having received a packet that contains the HBH Options Extension Header, does an implementation that does not recognize any HBH Options need to examine the options contained by the header? (y/n)

- If you answered Yes to Question #2, skip the following questions:

3) How should a router that does not recognize any HBH Options and does not examine options contained by the HBH Header behave when in receives a packet containing the HBH Options Extension Header?
	a) discard the packet
	b) forward the packet

If a) don't we break the semantics of type 0? If b) don't we break the semantics of types 01, 10 and 11?

                                                              Ron

> Sent: Monday, March 21, 2016 7:14 PM
> REQ 1: An implementation MAY NOT need to examine or process the Hop-
> by-Hop Options header unless explicitly configured to do so.
>

---

From: [email-masked]
Date: Tue, 22 Mar 2016 02:24:22 +0100

Ron,

[continuing on the path to see if it is possible to change the meaning of those two bits in the options]

> Let's break this down by asking a series of yes/no questions:

Can't answer that without another question.

0) Can an implementation that has no feature configured that requires any HBH options forward the packet without
    examining the header? y/n
Y

> 1) Having received a packet that contains the HBH Options Extension Header, does an implementation that recognizes at least one HBH Option need to examine the options contained by the header? (y/n)

What does recognise mean? If the node is configured to examine the header it should process all options.
Y

> 2) Having received a packet that contains the HBH Options Extension Header, does an implementation that does not recognize any HBH Options need to examine the options contained by the header? (y/n)

Same as 1.

> If a) don't we break the semantics of type 0? If b) don't we break the semantics of types 01, 10 and 11?

I'd like to make the implementations that "by default" ignore the HBH compliant.
It would be b). Depending on your reading, it wouldn't change the semantics of the option type.
The node processing the option would still comply with those flags, we're just changing the requirement that every router must examine them, regardless of the router being able to do anything about the options or not.)

My suggestion is that we change behaviour from "every hop" to "every configured hop". I believe that matches operational reality as well.

Here is the 2460bis text:

   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.

We could replace it with:

   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 any 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.

Making processing it optional.

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2016 15:03:10 +1300

On 22/03/2016 14:24, [email-masked] wrote:

...
> Making processing it optional.

The practical difference between "should" and "may" isn't very significant.
Either way, the designer of a HbH option must deal with the fact that
not all routers will process it, which is exactly today's reality.

The current draft wants to change this to make processing the HbH header
mandatory. But it's a bit self-contradictory because it starts out
by saying:

   "REQ1: Implementations MUST NOT discard otherwise forwardable
    packets because they contain the HBH Options Extension header."

That implies that all routers must transmit such packets, which is
goodness.

Then, with the second part of REQ1 things get a bit strange:

   "...an implementation MAY be configured to discard packets
    containing the HBH Options Extension Header, so long as this is
    not the default behavior."

In other words, it's actually OK to do what the first sentence forbids.

An alternative would be to say: if, and only if, you process the HbH header,
here are the rules. Otherwise, forward the packet. Or more formally:

   REQ1: Forwarding devices MUST NOT by default discard otherwise forwardable
   packets solely because they contain the HBH Options Extension header.

   REQ1a: Forwarding devices that process packets containing the HBH
   header MUST do so in accordance with the following rules.

     Brian

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 22 Mar 2016 03:31:49 +0000

Brian,

I think that we are talking past one another because we have different mental models of HBH Options. The two competing mental models are:

- HBH Options are suggestions. If you want to take them, fine. If you want to forward the packet without looking at them, that's OK too.
- HBH Options that begin with 00 are suggestions, as described above. Not so for HBH Options that begin with 01, 10, or 11. If you don't support this option, don't even think about forwarding the packet.

If the former is we want to canonize, the current draft doesn't add any value at all. If the latter is what we want to canonize, we should continue discussion of this draft.

                                                Ron

P.S. I won't be heartbroken if we want to canonize the former. So long as somebody writes it down someplace.

> Sent: Monday, March 21, 2016 10:03 PM
> To: [email-masked]; Ronald Bonica <[email-masked]>
> Either way, the designer of a HbH option must deal with the fact that not all
> routers will process it, which is exactly today's reality.
> 
> mandatory. But it's a bit self-contradictory because it starts out by saying:
> 
> That implies that all routers must transmit such packets, which is goodness.
>

---

From: [email-masked]
Date: Tue, 22 Mar 2016 09:12:24 +0100

Ron,

> - HBH Options are suggestions. If you want to take them, fine. If you want to forward the packet without looking at them, that's OK too.

My whole point in stating that you don't have to look at them, is to allow us to say "thou MUST forward them".
Thereby making forwarding of HBH for routers not involved in the HBH signalling have the same cost as other packets (or packets with EH).

> - HBH Options that begin with 00 are suggestions, as described above. Not so for HBH Options that begin with 01, 10, or 11. If you don't support this option, don't even think about forwarding the p…

Right, that's kinda what 2460 says.

> P.S. I won't be heartbroken if we want to canonize the former. So long as somebody writes it down someplace.

I'd certainly wouldn't like to see you heartbroken. ;-)
Isn't this draft the place to write it down?

Best regards,
Ole

---

From: [email-masked]
Date: Tue, 22 Mar 2016 10:06:04 +0100 (CET)

> - HBH Options that begin with 00 are suggestions, as described above. Not so for HBH Options that begin with 01, 10, or 11. If you don't support this option, don't even think about forwarding the p…

I might also want to treat differently:

- HBH options arriving on my IP transit/peering links - acting on
these could potentially result in remotely triggered control plane
problems.

- HBH options arriving from my MPLS core - I might want to act on
these.

Steinar Haug, AS2116

---

From: Brian Haberman <[email-masked]>
Date: Tue, 22 Mar 2016 13:49:59 -0400

All,

     My question is not directed at Steinar even though I am replying to
his note...

On 3/22/16 5:06 AM, [email-masked] wrote:
>> I think that we are talking past one another because we have
>> different mental models of HBH Options. The two competing mental
>> models are:
>> 
>> - HBH Options are suggestions. If you want to take them, fine. If
>> you want to forward the packet without looking at them, that's OK
>> too. - HBH Options that begin with 00 are suggestions, as described
>> above. Not so for HBH Options that begin with 01, 10, or 11. If you
>> don't support this option, don't even think about forwarding the
>> packet.
> 

Provocative question...

Have we reached a point where HBH options are completely obsolete? If a
router needs to process a signaling message (e.g., RSVP or IGMP/MLD),
most implementations that I am aware of don't trigger that processing
based on the presence of a HBH option. For example, IGMP/MLD messages
are identified by the protocol (or ICMPv6 codepoint).

Which signaling protocol(s) would break if HBH went away?

Brian

---

From: [email-masked]
Date: Sat, 26 Mar 2016 23:38:57 +0100

> Which signaling protocol(s) would break if HBH went away?

MLD, RSVP. IOS depends on the HBH (as I would expect many others).

I think the original purpose of HBH still stands. Probably even more now than when it was designed.
It is useful to have the function to signal to routers along the path, that they should take the closer look at a packet.

e.g. it should have been used for draft-ietf-conex-destopt, I know cisco has an OAM feature that uses it.

Where we went wrong was to make the assumption that _every_ router on the path should process the header. (It isn't like anyone would ever expect that you could create a SRH list of your choosing and have routers act upon that wish).
That seems like a simple fix to me...

I do not see any benefit in making the header obsolete. That'll just make it harder for those valid use cases where routers on the path should process deeper into the packet. Let's fix it instead.

Best regards,
Ole