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

From: Ronald Bonica <[email-masked]>
Date: Thu, 24 Mar 2016 01:01:40 +0000

Brian,

Your question is not only appropriate, it is telling!

Consider the following:

- Today only ten HBH Options are defined
- Of these, Pad and PadN don't do very much
- Many of the others aren't widely deployed

Many routing protocol designers avoid the Router Alert Option in favor of other mechanisms. For example, many RSVP-TE implementations avoid the IPv4 router alert option. Alternatively, they address the RSVP packet to the next node in the path.  I suspect that they will do likewise when then implement RSVP-TE over IPv6. The designers of other protocols may follow suite.

The WG is at an inflection point. Options are:

a) continue down the path of RFC 7045 wrt HBH
b) continue down the path of the initial versions of draft-ietf-6man-hbh-header-handling
c) deprecate the HBH Options Extension Header

None of these are very appealing. 

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

If we continue down the path of the initial versions of draft-ietf-6man-hbh-header-handling, we preserve the semantics of the first two bits of the option type. From a standardization point of view, this is as painful as continuing down the path of RFC 7045. It also makes HBH handling more computationally expensive. Lots of work, little payoff.

Deprecation may be painful for applications that rely on existing HBH Options. But given that there are only ten HBH Options and many of them are not widely deployed, we are probably better off experiencing the pain now than later.

                                                                     Waiting for incoming, 
                                                                      Ron

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Tuesday, March 22, 2016 1:50 PM
> To: [email-masked]
> Subject: Re: Review of draft-ietf-6man-hbh-header-handling-01
> 
>  [SNIP]
> 
> 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: joel jaeggli <[email-masked]>
Date: Wed, 23 Mar 2016 18:28:40 -0700

On 3/23/16 6:01 PM, Ronald Bonica wrote:
> - Today only ten HBH Options are defined - Of these, Pad and PadN
> don't do very much - Many of the others aren't widely deployed
> 
> Many routing protocol designers avoid the Router Alert Option in
> favor of other mechanisms. For example, many RSVP-TE implementations
> avoid the IPv4 router alert option. Alternatively, they address the
> RSVP packet to the next node in the path.  I suspect that they will
> do likewise when then implement RSVP-TE over IPv6. The designers of
> other protocols may follow suite.

I would suspect the sorts of things one might use them for operators
either use dscp bits overload the flow label or employ wrappers such a
labels.

I've seen l3dsr for example implmented using dscp.

https://github.com/yahoo/l3dsr

I don't the we did this because it's a great approach but rather because
it has minimal imposition on the required functionality of the
forwarding path, e.g because prexisting bits are already there.

> a) continue down the path of RFC 7045 wrt HBH b) continue down the
> path of the initial versions of draft-ietf-6man-hbh-header-handling 
> 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
> 
> If we continue down the path of the initial versions of
> draft-ietf-6man-hbh-header-handling, we preserve the semantics of the
> first two bits of the option type. From a standardization point of
> view, this is as painful as continuing down the path of RFC 7045. It
> also makes HBH handling more computationally expensive. Lots of work,
> little payoff.
> 
> Deprecation may be painful for applications that rely on existing HBH
> Options. But given that there are only ten HBH Options and many of
> them are not widely deployed, we are probably better off experiencing
> the pain now than later.
> 
> Waiting for incoming, Ron
> 
> 
>> -----Original Message----- From: ipv6
>> [mailto:[email-masked]] On Behalf Of Brian Haberman Sent:
>> Tuesday, March 22, 2016 1:50 PM To: [email-masked] Subject: Re:
>> Review of draft-ietf-6man-hbh-header-handling-01
>> 
>> [SNIP]
>> 
>> 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).
>> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 24 Mar 2016 17:25:33 +0000

On Wed, Mar 23, 2016 at 9:01 PM Ronald Bonica <[email-masked]> wrote:

> Many routing protocol designers avoid the Router Alert Option in favor of
> other mechanisms. For example, many RSVP-TE implementations avoid the IPv4
> router alert option. Alternatively, they address the RSVP packet to the
> next node in the path.  I suspect that they will do likewise when then
> implement RSVP-TE over IPv6. The designers of other protocols may follow
> suite.
>
> 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
>         - explain how this deprecation limits the applicability of HBH.
> (i.e., HBH cannot support applications that absolutely require the 01/10/11
> semantic)
> draft-ietf-6man-hbh-header-handling, we preserve the semantics of the first
> two bits of the option type. From a standardization point of view, this is
> as painful as continuing down the path of RFC 7045. It also makes HBH
> handling more computationally expensive. Lots of work, little payoff.
>
> Options. But given that there are only ten HBH Options and many of them are
> not widely deployed, we are probably better off experiencing the pain now
> than later.
>

This is probably not going to be popular, but I think that deprecating them
is the right thing to do - having something which is part of the spec, but
which we know doesn't work / isn't really implemented (and is dangerous to
enable / use ('tis a perfect dos)) seems like a bad thing.

Lets just rip the bandaid off and get it over with.

>  Waiting for incoming,

Likewise,
W

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

---

From: t.petch <[email-masked]>
Date: Thu, 24 Mar 2016 18:01:13 +0000

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "Ronald Bonica" <[email-masked]>; "Brian Haberman"
<[email-masked]>; <[email-masked]>
Sent: Thursday, March 24, 2016 5:25 PM
> > Many routing protocol designers avoid the Router Alert Option in
favor of
> > If we continue down the path of RFC 7045, we break the semantics of
the
> >         - deprecate the semantics of the first two bits of the
option type
> > (because we broke them)
> >         - figure out if we have broken any existing HBH options that
start
> > with 01/10/11
them are
> Lets just rip the bandaid off and get it over with.

I would support that.

The comment was made earlier this year that one factor in the uptake of
IPv6 not being as quick as would be desirable was the complexity of the
protocol so I am in general of pruning anything that can be, especially
when it is problematic.

Tom Petch

Ron
> > > 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

------------------------------------------------------------------------
--------

---

From: 神明達哉 <[email-masked]>
Date: Thu, 24 Mar 2016 11:09:46 -0700

At Thu, 24 Mar 2016 01:01:40 +0000,

> - Many of the others aren't widely deployed

"The others" include the jumbo payload option.  It's certainly not
widely deployed, but I guess the reason is because links (or paths if
we consider the PMTU implication) whose MTU is over 64KB are not
widely deployed (if not just nonexistent).  Are we okay to shut down
that possibility for good, or is there any viable alternative if and
when we want to use such links (or paths) more widely?

(not to say a particular opinion on obsoleting HBH, just raising a
possible point to discuss).

--
JINMEI, Tatuya

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 24 Mar 2016 18:29:35 +0000

Jinmei,

I am not too worried about Jumbograms because:

- Since RFC 2675 was written in 1999, routers have become much more capable. They can forward many more packets per second today than they could then. So, the motivation to send large packets has decreased.
- In reality, many applications limit themselves to sending 1280-byte packets. This is due to MTU discovery and fragmentation issues. I hope that these issues will be overcome someday. But even when they are overcome, 64K seems like a reasonable limit.

                                                              Ron

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ????
> Sent: Thursday, March 24, 2016 2:10 PM
> To: Ronald Bonica <[email-masked]>
> Cc: Brian Haberman <[email-masked]>; [email-masked]
> Subject: Re: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-
> handling-01)
> 
> "The others" include the jumbo payload option.  It's certainly not widely
> deployed, but I guess the reason is because links (or paths if we consider the
> PMTU implication) whose MTU is over 64KB are not widely deployed (if not
> just nonexistent).  Are we okay to shut down that possibility for good, or is
> there any viable alternative if and when we want to use such links (or paths)
> more widely?
> 
> (not to say a particular opinion on obsoleting HBH, just raising a possible point
> to discuss).
> 
> --
> JINMEI, Tatuya

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Mar 2016 18:34:04 +0000

Hello Ron

RPL uses HbH within a limited realm.
I do not see the IETF deprecating that, unless an alt is found. 

The proposal to use the flow label instead was acceptable from the IOT perspective but is somewhere in limbo at the moment.

Regards,

Pascal

> Le 24 mars 2016 à 19:30, Ronald Bonica <[email-masked]> a écrit :
> 
> Jinmei,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 24 Mar 2016 19:58:22 +0000

Hi,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Ronald Bonica
> Sent: Thursday, March 24, 2016 11:30 AM
> To: 神明達哉 <[email-masked]>
> Subject: RE: HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01)
> 
> Jinmei,
> 
> - Since RFC 2675 was written in 1999, routers have become much more capable. They can forward many more packets per second
> today than they could then. So, the motivation to send large packets has decreased.
> - In reality, many applications limit themselves to sending 1280-byte packets. This is due to MTU discovery and fragmentation issues. I
> hope that these issues will be overcome someday. But even when they are overcome, 64K seems like a reasonable limit.

I say leave jumbos in place - we have no idea what sorts of networks we will run
IPv6 over in the future.

Thanks - Fred
[email-masked]

---

From: Ca By <[email-masked]>
Date: Thu, 24 Mar 2016 13:32:26 -0700

On Thu, Mar 24, 2016 at 10:25 AM, Warren Kumari <[email-masked]> wrote:

>> start with 01/10/11
> This is probably not going to be popular, but I think that deprecating
> them is the right thing to do - having something which is part of the spec,
> but which we know doesn't work / isn't really implemented (and is dangerous
> to enable / use ('tis a perfect dos)) seems like a bad thing.
>
+1, i  have not and will never let my routers forward along a path across
my internal network suggested by a 3rd party.

CB

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2016 10:18:32 +1300

A specific point about jumbograms is that when they were conceived, the use case
was for single hops within a data centre using very high data rate technologies
such as HIPPI (high rate for those days, of course). I was wearing a CERN hat
at the time and was very keen on jumbograms for particle physics data centres,
where HIPPI was a strong contender.

All that is OBE now, but in any case I never though that routed jumbograms
was a serious use case.

That doesn't mean we should scrap the option, but expecting routers to
process it is another matter entirely.

    Brian

On 25/03/2016 07:29, Ronald Bonica wrote:
> .

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2016 10:28:11 +1300

>> On Wed, Mar 23, 2016 at 9:01 PM Ronald Bonica <[email-masked]> wrote:
...
>>> a) continue down the path of RFC 7045 wrt HBH

Actually the statement in RFC 7045 is factual. We are on that
path today whether we like it or not.

>>> draft-ietf-6man-hbh-header-handling

I'll be blunt. I think that's doomed. I don't think we're going to
see that amount of re-engineering of the boxes concerned.

>>> None of these are very appealing.

A slightly less painful way to remove the Band-Aid is

d) specify that no further HbH options will be defined and that
the RFC 7045 warning is with us for ever. And weasel word the
issue of the first two bits' semantics.

But what do we do if domain-specific use cases like RPL come
up in the future?

...
> my internal network suggested by a 3rd party.

err, isn't that the routing header, not the HbH?

    Brian

---

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

> d) specify that no further HbH options will be defined and that the RFC
    > 7045 warning is with us for ever. And weasel word the issue of the
    > first two bits' semantics.

    > But what do we do if domain-specific use cases like RPL come up in the
    > future?

The RPL case would have been much simpler if we had specified that the header
was non-critical [00] (i.e. could be skipped if not understood), then some
things would be much simpler.

The argument against doing this was that if the RFC6553 marked packets got
out of the LLN, then the 01 marking would cause them to the dropped.
The worse case scenario would otherwise be that a packet escapes from one
LLN, travels to another LLN, and there, is mis-interpreted.

If routers no longer process HbH options, then no router will bother to drop
the errant packets, and the argument for 01 rather than 00 goes away.

At this point, it appears that draft-ietf-roll-useofrpi (compressed by
draft-ietf-roll-routing-dispatch-00) will result in many uses in RPL as being
encapsulated/decapsulated at each hop.  That is, the mutability of the
RPI/6553 header is unimportant, because at each hop the outer packet will be
addressed to the (LL) address of the next hop.   This is because we can not
guarantee that the final recipient understands the RPI header.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG outgoing co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

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

Brian,

You raise an excellent point. We should probably be specific about what it means to deprecate the HBH Options Extension Header.

>From a standardization perspective:

	1) An implementation can claim IPv6 conformance if it recognizes the HBH Options Extension Header and processes selected HBH Options (as per RFC 2460).
	2) An implementation can claim IPv6 conformance if it does not recognize the HBH Options Extension Header. Hosts in this category will discard packets containing the HBH Options Extension header. Routers in this category will forward packets that contain the HBH Options Extension Header without examining HBH contents or the contents of any subsequent IPv6 extension header (as per RFC 7045). 
	3) The IETF will not define any new HBH Options
	4) The IETF will not define any new protocols that rely on existing HBH Options
	5) The IETF should review existing protocols that rely on HBH. If there is still interest in that protocol, it should consider breaking its dependence on HBH. If there is no continued interest in that protocol, it should be deprecated.

>From an operational perspective:

	1) Operators MAY filter packets containing HBH at their ingress
	2) Operators MAY filter packets containing HBH at all nodes

>From an implementation perspective:

	1) Over time, fewer and fewer vendors will recognize the HBH Options Extension Header.  However, market forces will determine how long they will continue to support HBH.

                                                                                                                   Ron

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, March 24, 2016 5:28 PM
> To: Ca By <[email-masked]>; Warren Kumari <[email-masked]>
>  [SNIP}
> d) specify that no further HbH options will be defined and that the RFC 7045
> warning is with us for ever. And weasel word the issue of the first two bits'
> semantics.
>

---

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

Ronald Bonica <[email-masked]> wrote:
    > 2) An implementation can claim IPv6 conformance if it does not
    > recognize the HBH Options Extension Header. Hosts in this category will
    > discard packets containing the HBH Options Extension header. Routers in
    > this category will forward packets that contain the HBH Options
    > Extension Header without examining HBH contents or the contents of any
    > subsequent IPv6 extension header (as per RFC 7045).

I think that hosts in this category would claim IPv6 conformance if they
skipped HBH headers that were marked skippable.  (I would prefer that hosts
were told to skip all HBH headers, regardless of the skiptable two bits, but
that might really contradict "obsolete")

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

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 28 Mar 2016 12:58:47 +0000

Hi Michael,

I thought about that possibility. But doesn't that mean that hosts would have to recognize HBH forever, if for no reason other than to know enough to move on to the next header?

                                                                                  Ron

> From: Michael Richardson [mailto:[email-masked]]
> Sent: Friday, March 25, 2016 5:35 PM
> Cc: Brian E Carpenter <[email-masked]>; Ca By
> <[email-masked]>; Warren Kumari <[email-masked]>; Brian
> Haberman <[email-masked]>; [email-masked]

---

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

Ronald Bonica <[email-masked]> wrote:
    > I thought about that possibility. But doesn't that mean that hosts
    > would have to recognize HBH forever, if for no reason other than to
    > know enough to move on to the next header?

That's a good point.
Yes, they'd have to know how to skip it if they want to look at the next
header.

So, this would not affect routers that do not care to look at the next
header, but would affect end-hosts ... mostly. And security devices.

Anyone with deployed code *NOW* has this already.
So this only matters to people writing new code (or new chips).

If you think that there is ENOUGH savings... I'm listening.

What would happen to packets with RFC6553 HbH when they hit a core routers
after the change?  Ignore end hosts: I assume that if they need to understand
6553 packets addressed to them that they can afford the code.

Then we need to consider what it means for an LLN gateway that receives
a packet with a 6553 HbH option in it: since they act a bit like MPLS or
VLAN tags, we might have to drop them anyway, since they aren't trusted.

So, at the least, we would like to put IPsec AH on them, but since they are
mutable, that doesn't help that much (at least it authenticates the source,
maybe...), so we actually have to put IPsec tunnel mode on it... at which
point we are essentially back to IPIP headers on a hop-by-hop basis.
(This is precisely the ANIMA ACP model, btw. IPv6(LL)-IPsec-RPI-IPv6..)

So maybe core routers and security devices would never see RFC6553 HbH
headers..!  I'd still like to change them from 63 to 43 for the case where
the end-host doesn't speak RPI, such as in the ANIMA
NOC-does-not-speak-ACP-yet use case.