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

On Wed, Mar 23, 2016 at 9:01 PM Ronald Bonica <rbonica@juniper.net> wrote:

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

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

>                                                                       Ron
>
>
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman
> > Sent: Tuesday, March 22, 2016 1:50 PM
> > To: ipv6@ietf.org
> > 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
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>