Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Joe Touch <touch@isi.edu> Tue, 07 February 2017 19:47 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2945129E67; Tue, 7 Feb 2017 11:47:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Hh7_TOMa-aqj; Tue, 7 Feb 2017 11:47:18 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE7E129E5E; Tue, 7 Feb 2017 11:47:18 -0800 (PST)
Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v17JkEQt009519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 11:46:15 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: otroan@employees.org
References: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.com> <30725d25-9829-bf50-23c6-9e1b757e5cba@si6networks.com> <7ee506c2-4213-9396-186a-2b742c32f93b@gmail.com> <EA7E5B60-F136-47C6-949C-D123FB8DA70E@cisco.com> <00af01d27e11$fe539500$4001a8c0@gateway.2wire.net> <60F01869-8B32-46D3-80B1-A140DF1DDA8A@employees.org> <b07dcffe-107a-a777-2d03-57931088d842@isi.edu> <757E0263-7801-49D3-8A3D-8B5E2BD9C96D@employees.org>
From: Joe Touch <touch@isi.edu>
Message-ID: <5411446e-abd1-c445-e3b8-70c0c0c80660@isi.edu>
Date: Tue, 07 Feb 2017 11:46:15 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <757E0263-7801-49D3-8A3D-8B5E2BD9C96D@employees.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/09eTO3fli-O_GNvrVUmdZORkKuM>
Cc: draft-ietf-6man-rfc2460bis@tools.ietf.org, ietf@ietf.org, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, 6man-chairs@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2017 19:47:19 -0000

Thanks.

FWIW, AFAICT inserting headers on the fly also breaks PLPMTUD too
(though PLPMTUD will eventually recover).

Joe


On 2/7/2017 11:38 AM, otroan@employees.org wrote:
> Joe,
>
>> Can anyone give those of us not tracking 672 messages a brief summary?
>> IMO, without diving into that thread deeply, I agree with the new proposed text below from Brian:
> Posted to list on Satuday.
> https://mailarchive.ietf.org/arch/msg/ietf/MJexpTisUTSN2XrkkYVVLPJrjFM/?qid=8e4597241d656835af9f01439581f375
>
>>>    With one exception, extension headers are not processed, inserted,
>>>    deleted or modified by any node along a packet's delivery path, until
>>>    the packet reaches the node (or each of the set of nodes, in the case
>>>    of multicast) identified in the Destination Address field of the IPv6
>>>    header.
>>>
>> In fact, I'd go further to say that that non-HBH EHs should not even be *viewed* or used as context by intermediate nodes.
>>
>> And any limits on what can be done with HBH EHs should be stated explicitly. I'd be glad if at least the EH lengths didn't change.
> The original intent of the IPv6 design was certainly that. Routers should have no need to look beyond the first 40 byte header (with one exception) and everything else was end to end encrypted so there wouldn't be any purpose looking there anyway.
>
> We might get into trouble with the implementation report.
> If anyone knows of any implementation, software or hardware that is compliant with that, I'd certainly like to know. :-)
>
> Best regards,
> Ole