IETF Logo Mail Archive

RE: [EXTERNAL] Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 04 December 2020 19:36 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 070903A0EFF for <ipv6@ietfa.amsl.com>; Fri, 4 Dec 2020 11:36:46 -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 o1FgLquhfYYc for <ipv6@ietfa.amsl.com>; Fri, 4 Dec 2020 11:36:43 -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 95CDB3A0F01 for <ipv6@ietf.org>; Fri, 4 Dec 2020 11:36:42 -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 0B4JadaA031066; Fri, 4 Dec 2020 14:36:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607110600; bh=66C83mkfZkfcM1LVwPDwohI8KTnvPllHiXUuaoGjD+g=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Ve2pC5u349FnfTJ3HuxrEZbKjGZZAelGKIJJuMbBjTxVH7pMf2YnJL0Cl/sn4FJq8 qRpmI4JiM8CUNlHDA14pvdYrb0G4OZVKiICOTrrt1GlwhPn+h+cYizZoHZxQlRNR8N QNrD4P5qPeADKMLj/gx5iYwQ9NRUB5oUgjp3sgpARZftU2uZOaG/Dh6pIPWS0IK0ol qtUWPFSeq6/w5hgx57p6j1tNxYuk71aG1SoyHtsvyyzQroA3uucujOF/02AjDErgJU 5Mxmgy0/Q/J4IsRU0X4iMsJuCHw2JASszmHQFi01u7+KKXYdNqwjNANAPUseoZEw2e ddfZLwyU3i5tg==
Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0B4JaVQ2031023 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 4 Dec 2020 14:36:31 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Fri, 4 Dec 2020 11:36:30 -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; Fri, 4 Dec 2020 11:36:30 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Tom Herbert <tom@herbertland.com>
CC: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: RE: [EXTERNAL] Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
Thread-Topic: [EXTERNAL] Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
Thread-Index: AdbJzWfWXWiwZZKMQKek3OrnblfYVQAnj8cAABImZwAAEDQWMA==
Date: Fri, 04 Dec 2020 19:36:30 +0000
Message-ID: <b3895d2420964d2cbb6b92c84c191b1c@boeing.com>
References: <b2e38223c5734399832888087c87b120@boeing.com> <4b7928258d904bca964ebab741a418e9@boeing.com> <CALx6S36vrpw-X80Ca_qmntDzSDyw-bzBsH6pjC2yFcRnc+Bj4g@mail.gmail.com>
In-Reply-To: <CALx6S36vrpw-X80Ca_qmntDzSDyw-bzBsH6pjC2yFcRnc+Bj4g@mail.gmail.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: F7E4ECA6722ACBA8C82EC5498FA9D50E4CFB35F7735E65F6E47CFC90D1DDB1A72000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9f9z8Q0poqaBOh0IXSEM_CDGKeo>
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: Fri, 04 Dec 2020 19:36:46 -0000

Hi Tom,

> -----Original Message-----
> From: Tom Herbert [mailto:tom@herbertland.com]
> Sent: Friday, December 04, 2020 11:11 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>; Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> Subject: Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> 
> Fred,
> 
> Can you provide some detail on your use case and why you think this
> change is needed?

Probably not without setting off a burst of passionate list activity. But,
I think the proposed changes are more consistent with Postel's law.

Thanks - Fred
 
> Tom
> 
> On Fri, Dec 4, 2020 at 11:34 AM Templin (US), Fred L
> <Fred.L.Templin@boeing.com> wrote:
> >
> > Bob and Gorry,
> >
> > Regarding my previous message, here are my proposed updates to RFC8200.
> > Can these be added to your document?
> >
> > Thanks - Fred
> >
> > ---
> >
> > RFC8200, Section 4:
> > OLD:
> >          "The Hop-by-Hop Options header, when present, must immediately follow
> >          the IPv6 header."
> > NEW:
> >          "The Hop-by-Hop Options header, when present, is processed only if it
> >          immediately follows the IPv6 header (otherwise ignored)."
> >
> >
> > RFC8200, Section 4.1:
> > OLD:
> >          "IPv6 nodes must accept and attempt to process extension headers in
> >           any order and occurring any number of times in the same packet,
> >           except for the Hop-by-Hop Options header, which is restricted to
> >           appear immediately after an IPv6 header only."
> > NEW:
> >          "IPv6 nodes must accept and attempt to process extension headers in
> >           any order and occurring any number of times in the same packet,
> >           except for the Hop-by-Hop Options header, which is processed only
> >           if it appears immediately after an IPv6 header (otherwise ignored)."
> >
> > > -----Original Message-----
> > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> > > Sent: Thursday, December 03, 2020 3:39 PM
> > > To: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
> > > Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> > > Subject: RE: Proposal for changing how IPv6 Hop-by-Hop Options are processed
> > >
> > > Bob and Gorry,
> > >
> > > I would like it if some document that updates RFC8200 (such as yours) could
> > > relax the restriction that the Hop-by-Hop option has to immediately follow
> > > the IPv6 header. This comes up in two different places in RFC8200:
> > >
> > > Section 4:
> > >    "The Hop-by-Hop Options header, when present, must immediately follow
> > >    the IPv6 header."
> > >
> > > Section 4.1:
> > >    "IPv6 nodes must accept and attempt to process extension headers in
> > >    any order and occurring any number of times in the same packet,
> > >    except for the Hop-by-Hop Options header, which is restricted to
> > >    appear immediately after an IPv6 header only."
> > >
> > > I would like to see this restriction softened somewhat (perhaps to a "should")
> > > since I have a use case in mind where another extension header type might
> > > appear before the Hop-by-Hop option, if only briefly. Any chance your doc
> > > could accommodate?
> > >
> > > Fred
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
> > > > Sent: Thursday, December 03, 2020 3:16 PM
> > > > To: IPv6 List <ipv6@ietf.org>
> > > > Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; Bob Hinden <bob.hinden@gmail.com>
> > > > Subject: [EXTERNAL] Proposal for changing how IPv6 Hop-by-Hop Options are processed
> > > >
> > > > Hi,
> > > >
> > > > Gorry and I put together a draft that proposes to change how IPv6 Hop-by-Hop Options are processed.  Links to the draft below.
> > > >
> > > > Abstract:
> > > >
> > > >   This document specifies procedures for how IPv6 Hop-by-Hop options
> > > >   are processed.  It modifies the procedures specified in the IPv6
> > > >   Protocol Specification (RFC8200) to make processing in routers more
> > > >   practical with the goal of making IPv6 Hop-by-Hop options useful to
> > > >   deploy in the Internet.  When published, this document updates
> > > >   RFC8200.
> > > >
> > > > A very short summary is that there can only be one Hop-by-Hop option in a Hop-by-Hop Option header, and that Hop-by-Hop
> > > Options
> > > > must be process in the fast path.
> > > >
> > > > Please read and comment on the draft (that is, not on just this email).   We think this might make Hop-by-Hop options practical to
> > > use
> > > > in the Internet.
> > > >
> > > > Bob & Gorry
> > > >
> > > >
> > > > > Begin forwarded message:
> > > > >
> > > > > From: internet-drafts@ietf.org
> > > > > Subject: New Version Notification for draft-hinden-6man-hbh-processing-00.txt
> > > > > Date: December 3, 2020 at 3:04:46 PM PST
> > > > > To: "Robert M. Hinden" <bob.hinden@gmail.com>, "Godred Fairhurst" <gorry@erg.abdn.ac.uk>, "Robert Hinden"
> > > > <bob.hinden@gmail.com>, "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
> > > > >
> > > > >
> > > > > A new version of I-D, draft-hinden-6man-hbh-processing-00.txt
> > > > > has been successfully submitted by Robert M. Hinden and posted to the
> > > > > IETF repository.
> > > > >
> > > > > Name:             draft-hinden-6man-hbh-processing
> > > > > Revision: 00
> > > > > Title:            IPv6 Hop-by-Hop Options Processing Procedures
> > > > > Document date:    2020-12-03
> > > > > Group:            Individual Submission
> > > > > Pages:            11
> > > > > URL:            https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-00.txt
> > > > > Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/
> > > > > Html:           https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-00.html
> > > > > Htmlized:       https://tools.ietf.org/html/draft-hinden-6man-hbh-processing-00
> > > > >
> > > > >
> > > > > Abstract:
> > > > >   This document specifies procedures for how IPv6 Hop-by-Hop options
> > > > >   are processed.  It modifies the procedures specified in the IPv6
> > > > >   Protocol Specification (RFC8200) to make processing in routers more
> > > > >   practical with the goal of making IPv6 Hop-by-Hop options useful to
> > > > >   deploy in the Internet.  When published, this document updates
> > > > >   RFC8200.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Please note that it may take a couple of minutes from the time of submission
> > > > > until the htmlized version and diff are available at tools.ietf.org.
> > > > >
> > > > > The IETF Secretariat
> > > > >
> > > > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email