Re: Next steps on advancing core IPv6 specifications to full Internet standard

神明達哉 <jinmei@wide.ad.jp> Wed, 16 November 2016 19:18 UTC

Return-Path: <jinmei.tatuya@gmail.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 9C32F1294B0; Wed, 16 Nov 2016 11:18:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 end0bqocXtrm; Wed, 16 Nov 2016 11:18:29 -0800 (PST)
Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 0B4A1129512; Wed, 16 Nov 2016 11:18:29 -0800 (PST)
Received: by mail-qk0-x243.google.com with SMTP id n204so22720118qke.2; Wed, 16 Nov 2016 11:18:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Sg2y7vRunr2CdOWYqGFdyo8LqCzPR7wigurcYfb79f8=; b=CaQvws6M4z6xfnMZklG5Wn3zae7ena5DlbCrl68/lahgNeGNiT182dl5lh2CEOGDVp 0i934ZIYoc8DVwjJtjhq9CT0dCmS5FaS1SxoXREID+erofcQVI7huCpC5zRftF8KUY76 LAqTKjipoMIOozwy2nDIvkGE6Agx2QVYyHpZXpAwjAExWTUxZqYa/5YtOCSpf5O0L7ex OKC7EOYG05expEjNtofdDxDBmCnbn3J/N1HcHXbdG9HIPTI88MuY7kg+p+lhMRjL7aKh KYYO0GWjUj6YTVLGo6gyMi5aWvWxK8VFYSehcu1xQ67IpznnWoGOz0wK1I2PpTpPBTux px9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Sg2y7vRunr2CdOWYqGFdyo8LqCzPR7wigurcYfb79f8=; b=VxSywIb74b0Z6G9Apxoagn2jB3pgjWxGxQan8S7tKv8N7N/7aZ1U5AlLP2c1N8KMGm SAUC5VDWE8wYBKKgBW6Tbu++QD+2NAAPSrKXJ2fEoVknAdh0rhV8nkUvy0BBnCyBXbrh IFdjZ37FrwrjdqMFKkFWS4t9Fw5NY8YgRZ9cv970bSK8aYso69dBm4WDSxJvKiIJhG7T Inj9EPU0Ag0SD+nbvHwc4tOj2PtifBrxUFhUIUM9I1T81J+N5CIUkDUwnToRLOdLsYN+ 7kv/noeo/kdDC8cP4yv18hSa/6EhCplG34t1BgXKAR6zhifsp3caXPmTaLvyWtmAjbGT snIQ==
X-Gm-Message-State: AKaTC00TNkVAClF89WtYb4SmdwE1K1a1cLV4vqq67RM0o69GvIw3nr7/yOBPixYlycMCpj6DGIO7XhGH0iDpUg==
X-Received: by 10.55.51.201 with SMTP id z192mr5017683qkz.311.1479323908052; Wed, 16 Nov 2016 11:18:28 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.53.155 with HTTP; Wed, 16 Nov 2016 11:18:27 -0800 (PST)
In-Reply-To: <451D4151-B805-4A2E-8BAC-B6627C0B669C@employees.org>
References: <451D4151-B805-4A2E-8BAC-B6627C0B669C@employees.org>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Wed, 16 Nov 2016 11:18:27 -0800
X-Google-Sender-Auth: jLyacuP3wuKW0uK5YEbvkJsDzPA
Message-ID: <CAJE_bqczRSZYWC3tDLXvxRMzqnV9nDjYjUddyRHtwfpGEXvm5w@mail.gmail.com>
Subject: Re: Next steps on advancing core IPv6 specifications to full Internet standard
To: Ole Troan <otroan@employees.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Kp76SONpyqWneNgvtc8sh-fGAu0>
Cc: 6man WG <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 16 Nov 2016 19:18:30 -0000

At Tue, 15 Nov 2016 15:19:45 +0900,
otroan@employees.org wrote:

> We have now finished the edits on the RFC2460bis, RFC1981bis and
> RFC4291bis documents. With the agreement in today's working group
> session on the header insertion issue for 2460, the working group last
> call is now complete.
>
> The chairs have decided to declare consensus on the following text:
> (that includes a small amendment proposed in the meeting).
>
>    The insertion of Extension Headers by any node other than the
>    source of the packet causes serious problems.  Two examples include
>    breaking the integrity checks provided by the Authentication Header
>    Integrity [RFC4302], and breaking Path MTU Discovery which can
>    result in ICMP error messages being sent to the source of the
>    packet that did not insert the header, rather than the node that
>    inserted the header.
>
>    One approach to avoid these problems is to encapsulate the packet
>    using another IPv6 header and including the additional extension
>    header after the first IPv6 header, for example, as defined in
>    [RFC2473]

Am I correct that an agreement in a f2f session must first be
confirmed in the mailing list and this case is not an exception?

Assuming so, I'd like to say I still have a serious concern with this
text in that it's as "ambiguous" to the extent the original RFC2460
was ambiguous regarding whether the protocol intends (intended) to
allow such extension header insertion.  I'm concerned about this
because such ambiguity can lead to casual violation of the intent (we
know the intent was to not allow it) and casually dismissing the
stated problems and other issues that are not explicitly noted in the
text.  The existence of segment routing implementation for the Linux
kernel (a general purpose operating system) suggests it's not just an
imaginary concern: http://www.segment-routing.org/index.php/SR/SR-IPv6

It's true that no matter how clearly we clarify the intent there is
always someone who violates it, either intentionally or carelessly.
But that doesn't mean we should drop the effort of making it clearer
completely.  IMO it has non-marginal effect to warrant a caution if we
explicitly clarify the original intent (and, ideally, if we also state
an attempt of loosening the intent requires a great care).

If the current "compromise" text comes from the concern that any
clarified intent can be interpreted as an "outright ban" of such
insertion, prohibiting any future update to the restriction, we can
also clarify that's not the intent of the clarification.  I don't
think these cannot coexist.

I didn't attend the wg session (or for that matter I was not in Seoul
in the first place), so I don't know what kind of discussion the
participants had to reach this agreement.  Maybe the points I'm now
making were already covered and rejected, but I should still have the
right to make these points on my own behalf even if I'm a hapless
minority.  Hopefully there are some more who were not in the session
but share this view and we can still revisit the text.

--
JINMEI, Tatuya