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

On Thu, Mar 24, 2016 at 10:25 AM, Warren Kumari <warren@kumari.net> wrote:

>
>
> 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.
>
>
+1, i  have not and will never let my routers forward along a path across
my internal network suggested by a 3rd party.

CB

>
>
>>
>>
>>  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
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>