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

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 7 Dec 2020 14:55:18 +0000

Ole,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 07, 2020 6:40 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Fernando Gont <[email-masked]>; Bob Hinden <[email-masked]>; 6man WG <[email-masked]>; Gorry Fairhurst
> <[email-masked]>
> Subject: Re: [EXTERNAL] Proposal for changing how IPv6 Hop-by-Hop Options are processed
> 
> >> Mind explaining what you are trying to achieve with that change?
> >
> > Other than text that is more consistent with the robustness principle?
> > Shouldn't that be good enough in itself?
> 
> Not really.
> You will have more success gathering support for your ideas if you explain what problems they are meant to solve.
> Restricting the HBH header to appear only directly after the IPv6 header seems like quite a robust design.

Restricting the HbH header to appear only directly after the IPv6 header is consistent
with "be conservative in what you send". Processing the HbH header  only if it follows
immediately after the IPv6 header (otherwise ignore) is consistent with "be liberal in
what you accept from others".

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.

Thanks - Fred

> Cheers,
> Ole

---

From: Tom Herbert <[email-masked]>
Date: Mon, 7 Dec 2020 09:21:44 -0700

> 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.

Tom

> Thanks - Fred
>
> > Cheers,
> > Ole
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Dec 2020 21:18:03 -0300

Hi, Tom,

On 7/12/20 13:21, Tom Herbert wrote:
[...]
> believe this behavior is non-conformant or is inconsistent with

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1