RE: A long HBH Options question

[Ron Bonica <[e-mail]>]

Tom,

Fair enough. The first item is out of scope for your draft. The second will be included. The third and fourth are already in your draft.

                                                           Ron


> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Wednesday, August 22, 2018 1:17 PM
> To: Ron Bonica <[e-mail]>
> Cc: C. M. Heard <[e-mail]>; 6man <[e-mail]>
> Subject: Re: A long HBH Options question
> 
> On Wed, Aug 22, 2018 at 9:43 AM, Ron Bonica <[e-mail]> wrote:
> > Hi Tom,
> >
> 
> Hi Ron,
> 
> > Judging by the feedback, those experiencing cognitive dissonance
> > constitute a small minority. Maybe our concerns are better addressed
> > with medication than clarifications ;-)
> >
> > However, if you want to reduce the number of pills that I take every day,
> you might add the following clarifications to your document:
> >
> > - What do the "act" bits mean when they appear in an HBH option?
> 
> That would be a good clarification of HBH processing in RFC8200.
> 
> > - What does the "chg" bit mean when it appears in an option where Opt
> Data Len is equal to 0.
> 
> Okay.
> 
> > - What does the "chg" bit mean when it appears in a Destination Options
> header precedes the Routing Options header.
> > - What does the "chg" bit mean when it appears in a Destination Options
> header follows the Routing Options header (or the packet does not contain a
> routing header).
> 
> I think that's already covered in the draft (section 3). Please let me know if it's
> not clear.
> 
> Tom
> 
> >
> >
> > Ron
> >
> >
> >> -----Original Message-----
> >> From: Tom Herbert <[e-mail]>
> >> Sent: Wednesday, August 22, 2018 10:28 AM
> >> To: C. M. Heard <[e-mail]>
> >> Cc: Ron Bonica <[e-mail]>; 6man <[e-mail]>
> >> Subject: Re: A long HBH Options question
> >>
> >> On Tue, Aug 21, 2018 at 5:39 PM, C. M. Heard <[e-mail]>
> wrote:
> >> > On Tue, 21 Aug 2018 19:16:55 +0000, Ron Bonica wrote:
> >> >> [ … ] let's assume that:
> >> >>
> >> >> - A packet contains an HBH option and the high-order bits of the HBH
> >> >>   Option type are "10" [could also be "01" or "11']
> >> >>
> >> >> - The packet traverses Router A and Router B on route to its
> >> >>   destination
> >> >>
> >> >> - Router A is not configured to process HBH options
> >> >>
> >> >> - Router B is configured to process HBH options
> >> >>
> >> >> - Neither Router A nor Router B recognize the HBH option contained by
> >> >>   the above-mentioned packet.
> >> >>
> >> >> I think that RFC 8200 requires the following behavior:
> >> >>
> >> >> - Router A forwards the packet to Router B, without examining the HBH
> >> >>   Options header
> >> >>
> >> >> - Router B discards the packet, because it doesn't recognize the
> >> >>   option.
> >> >>
> >> >> Is this the required behavior?
> >> >
> >> > Yes.
> >> >
> >> >> If so, does this behavior cause cognitive dissonance for anybody else?
> >> >
> >> > It sure does.
> >> >
> >> >> I am thinking that the "act" bits are meaningless in the HBH
> >> >> extension header. This discussion may also be applicable to
> >> >> draft-herbert-ipv6-update-dest-ops.
> >> >
> >> > The "act" bits are not exactly meaningless, but only the encoding "00"
> >> > will elicit consistent behavior from nodes that  comply with RFC
> >> > 8200 and don't recognize the option. To me, it would seem quite odd
> >> > if the designer of any new HbH option were to choose an encoding with
> "act"
> >> > bits other than "00". For already allocated options, any encoding
> >> > other than "00" will not have the results expected by those who
> >> > designed the options assuming that the rules in RFC 2460 would be
> >> > followed. Thus, that the maintainers of existing HbH options with
> >> > the "act" bits other than "00" should probably re-examine the
> >> > option encoding in light of the change wrought by RFC 8200. Here is the
> list:
> >> >
> >> > 0x63  RPL (RFC 6553, PS)
> >> > 0x6D  MPL (RFC 7731, PS)
> >> > 0xC2  Jumbo Payload (RFC 2675, PS)
> >> > 0xEE  IP_DFF (RFC 6971, Experimental)
> >> >
> >> > The ROLL WG has in fact taken this step with the RPL option, though
> >> > for reasons independent of the change made in RFC 8200. The
> >> > thinking behind the original design in RFC 6553 was that it was
> >> > undesirable for the RPL option to escape from the RPL domain in
> >> > which it was originated, so "act" was set to "01" to force nodes
> >> > external to the domain to silently discard escaped packets. That
> >> > thinking has been revised, and there is a document in last call
> >> > that will deprecate the existing code point and get a new one
> >> > (probably 0x23) with "act" set to
> >> "00".
> >> >
> >> > A re-examination of already allocated destination options would be
> >> > called for if the change proposed in
> >> > draft-herbert-ipv6-update-dest-ops
> >> > were to be implemented. Here is that list:
> >> >
> >> > 0xC9  Home Address (RFC 6275, PS)
> >> > 0x8A  Endpoint Identification (DEPRECATED) 0x8B  ILNP Nonce (RFC
> >> > 6744,
> >> > Experimental) 0x8C  Line-Identification (RFC 6788, PS)
> >> >
> >> Mike,
> >>
> >> Thanks for looking into this.
> >>
> >> Neither RFC6744 nor RFC6788 explicitly prohibit putting the option in
> >> front of a routing header, but I don't think doing that would make
> >> much sense in either case. In case of ILNP nonce, the option is used
> >> to communicate to a peer node information about the reverse path so
> >> it's really intended for the transport destination endpoint.
> >> Line-Identification is only used in conjunction with a ND packet
> >> being tunneled in the payload so only the ultimate destination should
> >> do anything with the option. It would be a good idea if
> >> specifications for new Destination Options explicitly said whether or not
> they can appear before a Routing header.
> >>
> >> Tom
> >>
> >> > The Home Address option would actually not be affected by the
> >> > proposed change in draft-herbert-ipv6-update-dest-ops since it
> >> > isn't allowed to appear appear before a Routing Header. I have not
> >> > examined the others, however.
> >> >
> >> > Mike Heard
> >> >
> >> > -------------------------------------------------------------------
> >> > - IETF IPv6 working group mailing list [e-mail] Administrative
> >> > Requests:
> >> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_m
> >> > ail
> >> > man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >> ndb3voDTXcWzo
> >> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-
> >> AWF2EfpHcAwrDThKP8&m=kq67Q11JdAIfRhVwF5c
> >> > N-DpFwRB9d3ip8DQlPOmzaII&s=UJLxrCn-N92TYQRkRq9QD_0-
> >> Du3MfKXlx3a1n1bVe7U
> >> > &e=
> >> > -------------------------------------------------------------------
> >> > -