Re: A long HBH Options question

On Tue, Aug 21, 2018 at 5:39 PM, C. M. Heard <heard@pobox.com> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------