Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

[Fernando Gont <[e-mail]>]

Hi, Tom,

On 7/12/20 13:21, Tom Herbert wrote:
[...]
>>
>> The real strength of Postel's law is the second clause moreso than the first. Application
>> of the second clause per my proposed text will naturally guide application of the first
>> clause in cases where the sender actually does want the HbH option processed. In
>> other cases, the second clause ensures correct operation for the receiver.
>>
> Fred,
> 
> The receive clause of the Robustness principle is only applicable
> within the bounds of the protocol requirements. RFC8200 is specific
> that HBH must be first and there can only be one HBH in a packet. A
> receive path may be implemented assuming these requirements such that
> they never have to consider the possibility of HBH appearing elsewhere
> in a packet. In fact, that is how Linux implemented HBH handling by
> making a special case different from all the other possible next
> headers. Looking at the code, I suspect that if a Linux host receives
> a packet with HBH EH not immediately following the IPv6 header, the
> packet will be dropped as having an unrecognized next header. I don't
> believe this behavior is non-conformant or is inconsistent with
> Postel's law.

FWIW, the benefits of Postel's Law to produce interoperable 
implementations is well known. That said, the same law has been 
challenged in recent times for resulting in increased complexity, 
inconsistent behavior and, ultimately, reduced security.

At the very least, as others have noted, I'd like to know what's the 
problem that relaxing RFC8200 would buy us. Relaxing the spec for no 
concrete reason doesn't seem like a good idea to me.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1