RE: A long HBH Options question

[Ron Bonica <[e-mail]>]

Hi Tom,

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?
- What does the "chg" bit mean when it appears in an option where Opt Data Len is equal to 0.
- 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).

                                                                              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_mail
> > man_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=kq67Q11JdAIfRhVwF5c
> > N-DpFwRB9d3ip8DQlPOmzaII&s=UJLxrCn-N92TYQRkRq9QD_0-
> Du3MfKXlx3a1n1bVe7U
> > &e=
> > --------------------------------------------------------------------