Subject: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01)

From: "C. M. Heard" <[email-masked]>
Date: Thu, 24 Mar 2016 21:56:05 -0700

On 3/24/16,  Ronald Bonica wrote:
> If we continue down the path of RFC 7045, we break the semantics of
> the first two bits of the Option Type. If we are to do that, we should
> probably repurpose draft-ietf-6man-hbh-header-handling-01 to:
> 	- document the decision
> 	- deprecate the semantics of the first two bits of the option type
> 	  (because we broke them)
> 	- explain how this deprecation limits the applicability of HBH.
> 	  (i.e., HBH cannot support applications that absolutely require the
>	   01/10/11 semantic)
> 	- figure out if we have broken any existing HBH options that start
> 	  with 01/10/11

I advocate doing this, rather than deprecating the entire HBH mechanism.

Of the eight non-trivial defined HBH options, only four demand actions
other than ignore if unrecognized:

opt		act	chg	bin		Descr			Reference	Status
0x63		01	1	00011	RPL Option	 	[RFC6553]	PS
0x6D	01	1	01101	MPL Option	 	[RFC7731]	PS
0xC2	11	0	00010	Jumbo Payload	[RFC2675]	PS
0xEE	11	1	01110	IP_DFF	 	 	[RFC6971]	Experimental

Indeed, the question arises whether allowing a router to ignore these
options beaks them, or not.  Clearly so for Jumbo Payload, but it's
unclear to me why RPL, MPL, and DFF need to be specified as
other than ignore if unrecognized.  If they work only in a controlled
forwarding domain, would not one expect all routers in such a
domain to recognize them and act upon them?  Would they not
still work if routers in the general internet ignored them?

The remaining four non-trivial HBH options are

opt		act	chg	bin		Descr		Reference	Status
0x05		00	0	00101	Router Alert	[RFC2711]	PS
0x07		00	0	00111	CALIPSO		[RFC5570]	Informational
0x08		00	0	01000	SMF_DPD	[RFC6621]	Experimental
0x26		00	1	00110	Quick-Start	[RFC4782]	Experimental

These are compatible with the RFC 7045 treatment.  CALIPSO, at least,
seems to be of practical importance.

Mike Heard

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Mar 2016 10:11:50 +0000

Thanks for this, Mike:

Talking for the RPL and probably MPL as well:

I think that the history of drop if unrecognized in the case of RPL is to avoid a leak out of the RPL domain into the larger internet.

>From recent discussions on the ML and WG meeting, we'd be glad to reverse this, and/or move the content to the flow label, whichever suits best this community. Reversing the bits would allow a non RPL aware host to accept the packet with the option in it. Right now, all end nodes have to be RPL aware.

Cheers,

Pascal

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of C. M. Heard
> Sent: vendredi 25 mars 2016 05:56
> To: ipv6 <[email-masked]>
> Subject: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-
> handling-01)
> 
> options beaks them, or not.  Clearly so for Jumbo Payload, but it's unclear to
> me why RPL, MPL, and DFF need to be specified as other than ignore if
> unrecognized.  If they work only in a controlled forwarding domain, would
> not one expect all routers in such a domain to recognize them and act upon
> them?  Would they not still work if routers in the general internet ignored
> them?
> 
> These are compatible with the RFC 7045 treatment.  CALIPSO, at least, seems
> to be of practical importance.
> 
> Mike Heard
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Mar 2016 14:35:49 -0400

C. M. Heard <[email-masked]> wrote:
    > unclear to me why RPL, MPL, and DFF need to be specified as other than
    > ignore if unrecognized.

I agree that it's unclear if there is real benefit.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 25 Mar 2016 19:49:09 +0000

Hi Mike,

Thanks for this analysis.

Although Router Alert begins with 00, it really should be on the first list. Think about what would happen if:

- You implemented RSVP-TE over IPv6
- One router the path does not recognize the Router Alert Option

For this reason and others, when people implement RSVP-TE over IPv6, they should not rely on the Router Alert HBH Option.

                                                                                           Ron

> Sent: Friday, March 25, 2016 12:56 AM
> To: ipv6 <[email-masked]>
> Of the eight non-trivial defined HBH options, only four demand actions other
> than ignore if unrecognized:
> 
> opt		act	chg	bin		Descr
> 	Reference	Status

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 16:05:31 +1300

On 26/03/2016 07:35, Michael Richardson wrote:
>     > options beaks them, or not.  Clearly so for Jumbo Payload, 

I dispute that, as far as the real world goes. Nobody ever expected the
jumbo payload to be used outside a "consenting adults" scenario; the requirement
to send back ICMP on discard is really icing on the jumbo cake. As some words in
RFC3765 tells you, the path has to be pretty much hand-crafted:

"  On links with configurable MTUs, the MTU must not be configured to a
   value greater than 65,575 octets if there are nodes attached to that
   link that do not support the Jumbo Payload option and it can not be
   guaranteed that the Jumbo Payload option will not be sent to those
   nodes."

So in practice, it really doesn't matter what the non-supporting
router does. Did anybody ever see one of these things at a peering
link or an IXP? I very much doubt it.

    Brian

>     > but it's

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Mar 2016 16:07:13 +1300

>>From recent discussions on the ML and WG meeting, we'd be glad to reverse this, and/or move the content to the flow label, whichever suits best this community. Reversing the bits would allow a non…

That sounds better than another round of why this would be a dubious use of the
flow label.

    Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 26 Mar 2016 12:59:41 +0000

+1

I think you're spot on Brian, with the consenting adults image. Some things have to be limited to some me domain where an agreement beyond the plain packet handling enables higher services. 

IOT needs that with RPL.

DetNet is another example that will need per hop handling?

Do we need to  deprecate things or simply better constrain their use?

Regards,

Pascal

> Le 26 mars 2016 à 04:05, Brian E Carpenter <[email-masked]> a écrit :
>

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 27 Mar 2016 20:58:30 -0700

On Fri, Mar 25, 2016 at 12:49 PM, Ronald Bonica <[email-masked]> wrote:
> Although Router Alert begins with 00, it really should be on the first list [options
> with the first two bits <> 00]. Think about what would happen if:
>
> For this reason and others, when people implement RSVP-TE over IPv6, they
> should not rely on the Router Alert HBH Option.

I can't disagree with that last statement, but I don't agree that
Router Alert should
have had first two bits not equal to 00, requiring that nodes not
understanding it
to drop it. That would not make RSVP-TE work better, and it would make "classic"
RSVP work worse (although in practice, that may not matter much anymore).

//cmh

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2016 11:30:47 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> From recent discussions on the ML and WG meeting, we'd be glad to
    >> reverse this, and/or move the content to the flow label, whichever
    >> suits
    >> best this community. Reversing the bits would allow a non RPL aware host
    >> to accept the packet with the option in it. Right now, all end nodes
    >> have to be RPL aware.

    > That sounds better than another round of why this would be a dubious
    > use of the flow label.

RPL is at a critical juncture where we are going to introduce non-backwards
compatible code into LLNs.  {Probably it's a flag day, and that's probably
okay for many networks; I think we can probably arrange a signal to enable
incremental deployment, but this thread is not about that}

As we arrange to compress RFC6554/6553, we could change the HbH code point
From 63 to 43, which would permit non-RPL nodes (such as 6lowpan only leafs,
and cloud data collection devices) to skip the RPI header.

This would permit more scenarios to work without the hop-by-hop IPIP
headers.  While the 6lorh work will likely compress much of the IPIP overhead
out, RPL is being used in networks which are non-6lowpan, and often not as
challenged as some LLNs.

The *ONLY* argument against this has been that the 63 HbH code point kept the
RPI from escaping.  This was done for 6man more than ROLL.

SO... if the above argument is bogus, then I want to re-open changing the RPI
code point.

(NOT wearing a hat, since I'm not HATLESS!!! WOOHOO!!!)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Mar 2016 07:57:35 +1300

> and cloud data collection devices) to skip the RPI header.

That makes a lot of sense. It might have made even more sense for
RFC 7045 to have said:

   The IPv6 Hop-by-Hop Options header MAY be processed by
   intermediate forwarding nodes as described in [RFC2460].
   Other forwarding nodes MUST ignore it.

      Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Mar 2016 09:20:07 +0000

Hello Brian:

> >
> > As we arrange to compress RFC6554/6553, we could change the HbH code
> > point From 63 to 43, which would permit non-RPL nodes (such as 6lowpan
> > only leafs, and cloud data collection devices) to skip the RPI header.
> 
> That makes a lot of sense. It might have made even more sense for RFC 7045
> to have said:
> 
> I-----------------------------

 I read that RFC7045 would override RFC2460 to make the *router* behaviour optional. Our intent was that the *hosts* would not drop a packet with a HbH header with options that they do not understand, which is an additional step. The reasoning being that the HbH is mostly for intermediate nodes and that the role of the header is probably consumed at the time the host gets it. 

For RPL,  we need that hosts that do not participate to RPL to ignore a HbH header with a RPL option in it.
But the RPI in the RPL option may be useful to another type of host that we call leaves; leaves are RPL-aware non-forwarding nodes.
Leaves will set the information in the RPI, and may process incoming packet differently (e.g. priority and or security) depending on the RPI.
This is why the flow label was of such interest for us, only nodes which care would have been impacted by the setting.

Cheers,

Pascal