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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018-12-06 01:16, Joe Touch wrote:
> 
> 
> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
> 
>>> Nobody deprecated the flags that require HBH options to be processed or dropped if not supported. 
>>
>> Intentionally. If a forwarding node is transparent to HbH options,
>> it is not looking at those flags. If it is looking at HbH options,
>> it will obey those flags. Why is that a problem?
> 
> What exactly does ‘transparent to HbH options mean’ if not ‘not supported’?

It means a forwarding node that uses the exception added by RFC7045 and simply
doesn't even look for an HbH header. The flag bits are invisible and irrelevant
to such a node. The flag bits apply as defined for a forwarding node that *does*
process HbH options, so they certainly should not be deprecated.

   Brian

> 
> In that case, the flags have exactly no meaning anywhere. But they’re not deprecated.
> 
> That makes no sense at all.
> 
> Joe
> .
> 





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux