Re: A long HBH Options question

[Tom Herbert <[e-mail]>]

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