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

["C. M. Heard" <[e-mail]>]

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