Re: [Tsv-art] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

[Ole Troan <[e-mail]>]

Joe,

> Read this text. Tell me what part of it you do not understand regarding nodes THAT DO NOT SUPPORT an option (if “skipping over” isn’t not supported, then what is it?):
> 
> The Option Type identifiers are internally encoded such that their highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 
>  00 - skip over this option and continue processing the header. 
> ** 01 - discard the packet. 
> ** 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 
> ** 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type.
> 
>>> I’m talking about a conflict in the text of 8200 - which has those fields as required to support - and 7045, which says they can be silently ignored.
>> 
>> 8200 says:
>> If the router is explicitly configured to process the HBH header it MUST adhere to the option flag 2 high order bits.
>> Otherwise it MUST forward the packet.
>> 
>> There is no conflict.
> 
> The conflict is in the issue of “not supported”. Skipping over headers means they’re not supported, but it’s not possible to “NOT SUPPORT” them two different ways - one silent, one that *requires* action.

I don’t know where you found the use of “support”.

The text from RFC8200 is:

   The Option Type identifiers are internally encoded such that their
   highest-order 2 bits specify the action that must be taken if the
   processing IPv6 node does not recognize the Option Type:

This only apply if you are actually processing the option in the first place.
Which is a change from RFC2460.

Cheers,
Ole