Subject: Hop-by-hop options in 2460bis

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jun 2016 09:13:26 -0700

>From the draft:

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

This effectively makes deployment of Hop-by-Hop options a nonstarter.
For instance, if my packets go through ten routers to a destination,
and nine routers implement the my HBH option but the tenth drops it,
then HBH is unusable for that destination. Also, with this text we
cannot claim that the tenth router is out of compliance, and if the
tenth router throws HBH into a slow path instead that doesn't really
help us much either to deploy at scale.

If processing HBH is a performance issue then a node should ignore it.
I suggest this alternate text for the above paragraph.

"A intermediate node in the path of a packet MUST either process the
Hop-by-Hop Option header or ignore it. A node MUST NOT drop a packet
solely on the basis that the Hop-by-Hop Option header is present."

Also, I think there is also a potential ambiguity is this text:

"The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:"

Since intermediate nodes can process HBH options are they expected to
take this actions? I think the answer should be no, it seems like only
the receiver should be allowed to drop packets with unknown options.
Note that if intermediate nodes are allowed to ignore the HBH option
this might be in conflict with the rules about handling unrecognized
options-- all options in that case are implicitly skipped.

Tom

---

From: Erik Kline <[email-masked]>
Date: Fri, 10 Jun 2016 09:23:02 -0700

I agree with your concern, but I'm skeptical that "ignore" will be a
practical option, since everybody loves to get their hands on port
numbers--even if only for incrementing logging counters.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jun 2016 09:31:59 -0700

> numbers--even if only for incrementing logging counters.

"ignore" in the sense that a node does not have to process the options
within the header. A node can alway skip over an EH to parse the next
header as long as it can identify the EH.

Tom

---

From: [email-masked]
Date: Fri, 10 Jun 2016 19:22:56 +0200

Tom,

Did you see the text I suggested here:

https://mailarchive.ietf.org/arch/msg/ipv6/dNtdwOgvvVL6Hz1uOykNKYOhEeU

[...]

I agree, that a clarification of what the "may process" means. Ron proposed the following text on a different thread:

  When an implementation skips  over an HBH Options header, it continues to process the packet, as if
  the HBH Options header had not been present in the header chain.

[...]

> options-- all options in that case are implicitly skipped.

with the changes proposed in the other thread we may get around that.
2460 has the following text:

   The Option Type identifiers are internally encoded such that their
   highest-order two bits specify the action that must be taken if the
   processing IPv6 node does not recognize the Option Type:

the "must -> should -> may process" change, we're relaxing which nodes need to process the option.
only the nodes processing the option needs to consider the high order bits.

cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jun 2016 10:47:54 -0700

>   the HBH Options header had not been present in the header chain.
Thanks for pointing that out. I think that's fine, but I would like to
see some explicit requirement that nodes cannot drop packets just
because HBH option or any other type of EH are present. If they are
permitted to do that it undermines the whole facility and makes it
unlikely we will ever deploy any EH in the Internet.

> only the nodes processing the option needs to consider the high order bits.
Allowing intermediate nodes to drop unrecognized options creates
non-deterministic behavior. For example, if a flow is going through
one path then all packets with HBH are delivered to the destination,
but if routing changes and and some intermediate node starting
dropping packets due to unrecognized EH then we lose connectivity for
the flow. If we're lucky we might get an ICMP param problem, but if we
don't we've lost the flow without endpoints having any idea why. This
is why I think only receiver should drop for unrecognized options.

Tom

---

From: [email-masked]
Date: Fri, 10 Jun 2016 20:46:22 +0200

Tom,

> unlikely we will ever deploy any EH in the Internet.

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.
   Nodes that do not process or examine the Hop-by-Hop Options header must ignore it,
   and it must be passed on unchanged if forwarded.

[...]

> is why I think only receiver should drop for unrecognized options.

Yes, I accept that argument. Mandatory options (those with any of the two high order bits set) are mandatory for a reason. Take the jumbo or the RPL option, you cannot expect that those can be forwarded through a network unless every node along the path supports the option. I would argue that trying to send a mandatory option over a network which isn't configured to handle it is a configuration error. The packet would likely be dropped regardless of processing of the high order bits. In practice that means that it is highly unlikely that mandatory options will be supported in the Internet.

Which is why I think that we do not have to change the specification for the high order bits.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Jun 2016 08:36:59 +1200

>    and it must be passed on unchanged if forwarded.

I agree that this is a more realistic desired behaviour. The text in RFC7045
was an attempt to describe the real world. The fact is that processing
HbH at line speed on a multi Gbit link isn't going to happen any time soon.

   Brian

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

---

From: Bob Hinden <[email-masked]>
Date: Fri, 10 Jun 2016 13:49:36 -0700

Ole,

> On Jun 10, 2016, at 11:46 AM, [email-masked] wrote:
> 
> Tom,
> 

I think this is fine, except for the last sentence that I think it too prescriptive for rfc2460bis.  It is requiring new behavior.  Saying something like:

  It is expected that nodes that do not process or examine the Hop-by-Hop Options header will
  ignore it, and it will be passed on unchanged if forwarded

would be fine.

Thanks,
Bob

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jun 2016 13:56:44 -0700

>   ignore it, and it will be passed on unchanged if forwarded
This sounds somewhat weak and passive to me. Can we say:

Nodes that do not process or examine the Hop-by-Hop Options header
must ignore it, and must pass it on unchanged if forwarded.

Thanks,
Tom

---

From: Bob Hinden <[email-masked]>
Date: Fri, 10 Jun 2016 14:06:17 -0700

Tom,

> must ignore it, and must pass it on unchanged if forwarded.

Purposely so.  The reason is that we can't advance this to Internet Standard if we introduce new behavior.  We can relax the requirements, as the text proposed by Ole does.  Hope that helps.

Bob

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 11 Jun 2016 12:57:17 +0000

I preferred Ole's proposal but understand the point. Will support this clarification text.

Thanks Bob!

Pascal

> Le 10 juin 2016 à 23:06, Bob Hinden <[email-masked]> a écrit :
> 
> Tom,
> 
>>>