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
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec

Reply via email to