Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 07 March 2017 10:44 UTC

Return-Path: <alexandre.petrescu@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 B2539129595 for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 02:44:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.352
X-Spam-Level:
X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, 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 2bLFCbso5D_7 for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 02:44:05 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EB112946E for <ipv6@ietf.org>; Tue, 7 Mar 2017 02:44:05 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v27Ai35f010555 for <ipv6@ietf.org>; Tue, 7 Mar 2017 11:44:03 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E85A6206327 for <ipv6@ietf.org>; Tue, 7 Mar 2017 11:44:02 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DF33920539F for <ipv6@ietf.org>; Tue, 7 Mar 2017 11:44:02 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27Ai2U0013061 for <ipv6@ietf.org>; Tue, 7 Mar 2017 11:44:02 +0100
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"
To: ipv6@ietf.org
References: <CAN-Dau17q_BrUuzfvB1mLDt6p5UxYikphWaHpa8VQ2L-3kx-DA@mail.gmail.com> <ee764408573b4db4b22e58c4ea5f289c@XCH15-06-11.nw.nos.boeing.com> <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <CAN-Dau0bSPiubeDOFeJAg6H0wP0ZNDS514eedmJtkOqHTXWOOw@mail.gmail.com> <D6D5B476-7F21-4F49-A81D-C2A11C30ADEC@google.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <ABE47051-FBFC-460F-89B0-FFD451410F7B@google.com> <m1cjviu-0000EYC@stereo.hq.phicoh.net> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <m1ck5mu-0000GaC@stereo.hq.phicoh.net> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <m1ckxfo-0000IMC@stereo.hq.phicoh.net> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <CAOSSMjUR203+hYFBrFBrj9Xkjux3o7fYNd4y9kNyxwpLxF11ew@mail.gmail.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <CAOSSMjUP6m-L1iNhE=BxHW+7hvt4YsZgxxtVn+qmgEVS9HeStA@mail.gmail.com> <CAJE_bqfpE-NWwG12S4CXM+ZnHdHHH31-y+_+pYhuCuq2FtqZ4w@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.com>
Date: Tue, 07 Mar 2017 11:44:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAJE_bqfpE-NWwG12S4CXM+ZnHdHHH31-y+_+pYhuCuq2FtqZ4w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3u1GXGF1V4Xk18Zp1nH06ZNXBrQ>
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: Tue, 07 Mar 2017 10:44:07 -0000

Le 07/03/2017 à 02:11, 神明達哉 a écrit :
[...]
> But this thread and another similar discussion seem to suggest that
> it's still not clear enough for some people.  At least two different
>  readers interpret this text:
>
>> If the sum of the prefix length and interface identifier length
>> does not equal 128 bits, the Prefix Information option MUST be
>> ignored.

Let me say that there are some interpretations of that sum from people
struggling to make it work.  These interpretations may be surprising to
the specifier.

The specifier is tempted to think that that "sum" equation is a good way
to tell everything in just one phrase.

But some people face the problem of making that sum be 128 even though
the plen is less than 64 and the IID is 64.

It is the case with the fe80:://10 needing to become a fe80::/64, and it
is also the case when PIO in RA has a P1::/63.

For this latter case, one wonders: am I allowed to form an address when
all I have is a P1::/63, and an IIDlen 64?  Can I make a P2::/64 by 
padding with 0s?

The specs dont answer these questions.  The specs think that the "sum"
equation is enough.

Further, because of that, some people think P1::/63 is forbidden from
being advertised on Ethernet.  Others think fe80:://10 is the same as
fe80::/64.

> as the PIO MUST be ignored for all purposes including on-link
> determination.  In a sense, it's not necessarily surprising - no
> matter how we try to clarify a point there's always a reader that
> still interprets it differently.

I agree with you.  And the more IPv6 gets deployed, the more readers
there are.

> But if there is really a protocol conformance test that doesn't
> interpret the text differently it's really surprising to me.
>
> The bottom line is, if there is an implementation that ignores a PIO
>  - with both L and A flag on, and - with prefix length being
> something other than 64 - received on a link whose IID is specified
> to be 64 (like Ethernet) even for on-link determination, then that
> implementation violates RFC4861.  I can also assure that the
> document editor of RFC4862 didn't intend such "strictness" - on the
> contrary, he actually tried to clarify that's not the intent, but it
> looks like it's still not super clear.

Well...

Alex

>
> -- JINMEI, Tatuya
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>