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

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

MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
In-Reply-To: <451D4151-B805-4A2E-8BAC-B6627C0B669C@employees.org>
References: <451D4151-B805-4A2E-8BAC-B6627C0B669C@employees.org>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Wed, 16 Nov 2016 11:18:27 -0800
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
Precedence: list

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

Next steps on advancing core IPv6 specifications … otroan
Re: Next steps on advancing core IPv6 specificati… 神明達哉
Re: Next steps on advancing core IPv6 specificati… Brian E Carpenter
Re: Next steps on advancing core IPv6 specificati… Tim Chown
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… Bob Hinden
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… Mark Smith
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… Brian E Carpenter
Re: Next steps on advancing core IPv6 specificati… David Farmer
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… Tom Herbert
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… 神明達哉
Re: Next steps on advancing core IPv6 specificati… Brian E Carpenter
Re: Next steps on advancing core IPv6 specificati… Brian E Carpenter
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… Bob Hinden
Re: Next steps on advancing core IPv6 specificati… Tom Herbert
Re: Next steps on advancing core IPv6 specificati… Mark Smith
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… Tim Chown
Re: Next steps on advancing core IPv6 specificati… Mark Smith
Re: Next steps on advancing core IPv6 specificati… Hemant Singh
Re: Next steps on advancing core IPv6 specificati… Hemant Singh