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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 07 December 2020 14:55 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F0B3A145F for <ipv6@ietfa.amsl.com>; Mon, 7 Dec 2020 06:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBTKA4iYC0mQ for <ipv6@ietfa.amsl.com>; Mon, 7 Dec 2020 06:55:31 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AEB3A15B9 for <ipv6@ietf.org>; Mon, 7 Dec 2020 06:55:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0B7EtMd4018971; Mon, 7 Dec 2020 09:55:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607352926; bh=LxQTeEI0CH0/smVuGW5FDA2MG+Qxs/Cvh5L3kBOUozY=; h=From:To:CC:Subject:Date:From; b=ocWmAePONmZynps3icjp5ZwQSjK/5Oqanpj+Suq5Q99JO7G2qsxEnSqYUEaGakl4s 3e4CTHtjoORBBDJK2MbQN+W6toWc7udewm/3Jbvbmlj4uTDPq+GY5PgwLppGsZLW7W Mb1tSu0FnY7cCchYTmWanS7EY2IKlZU03RISxZPEn5cX8jbM2fsxcm/a9xjcFYYsdO c+yRQJCMb4Xjgxhr8148CDQxg/Fc1pqJAuu9rGZHNAhQGIBBC8+GgcDAO7BiN3LQxQ IfqVFHDlxK5scz7bzSuKYczjF3fBpw+ve3C3nmDxLQS5w3Ko7rGih7JGfj0/ySxb6r MmjrUImOFhSIg==
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0B7EtK0H018925 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 7 Dec 2020 09:55:20 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 7 Dec 2020 06:55:19 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 7 Dec 2020 06:55:19 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "otroan@employees.org" <otroan@employees.org>
CC: Fernando Gont <fernando@gont.com.ar>, Bob Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: RE: Proposal for changing how IPv6 Hop-by-Hop Options are processed
Thread-Topic: Proposal for changing how IPv6 Hop-by-Hop Options are processed
Thread-Index: AdbMpyyTYSPwkNUGQnavvFgtx8G8EQ==
Date: Mon, 07 Dec 2020 14:55:18 +0000
Message-ID: <37cde639d1d0427191843454e040979d@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 96172AD86DE0403794A8566AD2EC0FEDE38566AC8C9F75323B59A818090BD8992000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eESwwSmsjxm1CVEAG849uVB3bpI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2020 14:55:40 -0000

Ole,

> -----Original Message-----
> From: otroan@employees.org [mailto:otroan@employees.org]
> Sent: Monday, December 07, 2020 6:40 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Fernando Gont <fernando@gont.com.ar>; Bob Hinden <bob.hinden@gmail.com>; 6man WG <ipv6@ietf.org>; Gorry Fairhurst
> <gorry@erg.abdn.ac.uk>
> 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