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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 07 March 2017 19:18 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 9A91C129426 for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 11:18:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 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] 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 CYbsfT6ZYV0S for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 11:18:28 -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 C0C54129483 for <ipv6@ietf.org>; Tue, 7 Mar 2017 11:18:27 -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 v27JIPk5018516; Tue, 7 Mar 2017 20:18:25 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 30F3D20961B; Tue, 7 Mar 2017 20:18:25 +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 236E6202938; Tue, 7 Mar 2017 20:18:25 +0100 (CET)
Received: from [132.166.84.102] ([132.166.84.102]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v27JIOKJ010180; Tue, 7 Mar 2017 20:18:24 +0100
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
References: <CAN-Dau17q_BrUuzfvB1mLDt6p5UxYikphWaHpa8VQ2L-3kx-DA@mail.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> <6f532a72-a142-5d84-f351-c38cba5230dd@gmail.com> <CAJE_bqcHvq1DbS4RCKiE1N7p=hpyU-QbhMdgHjUXcngurSzTKg@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <3a23f15e-afaf-d292-c68f-d6485c18d929@gmail.com>
Date: Tue, 7 Mar 2017 20:18:25 +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_bqcHvq1DbS4RCKiE1N7p=hpyU-QbhMdgHjUXcngurSzTKg@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/Qv7IMwt61qj8SsT198Bic9j5Ksc>
Cc: IPv6 IPv6 List <ipv6@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: Tue, 07 Mar 2017 19:18:29 -0000


Le 07/03/2017 à 19:36, 神明達哉 a écrit :
> At Tue, 7 Mar 2017 11:44:04 +0100, Alexandre Petrescu
> <alexandre.petrescu@gmail.com>; wrote:
>
>>> 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.
>
> At least the above text from Section 5.5.3 of RFC4862 is irrelevant
> to link-local addresses.  The entire Section 5.5 is about "Creation
> of Global Addresses" as the title shows.  In the case of creating
> global addresses, I can't think of an interpretation of 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.

The Host won't drop it because there's that other RFC needing it, right?
As such this RFC should say "the received PIO value MUST not be used as
such to generate an address; but it could be used if padded with 0s, or
trimmed of other bits".

> as it allows the creation in the case of advertised plen=63 and IID
> len=64.  RFC4862 requires not to do so with the MUST.  BSDs
> implement it that way, and so does Linux (according to what I heard
> here).  I'm also pretty sure that there's a conformance test tool
> like that for "IPv6 ready logo" or USGv6 that confirms the intent of
> the RFC.  And so I'm also pretty sure that other major OSes interpret
> the RFC as it intends.  So, overall, I don't think it's just what a
> document editor intends in his mind, but a widely accepted
> interpretation.
>
> That said, there's always someone who understands any seemingly
> clear text differently from the actual intent, not to mention the
> recent row about EH insertion.

And there are people looking deep into RFC details to understand what
could be implemented correctly, in order to solve this
"single-/64-per-Host" delivered by 3GPP.

> So I'm not surprised that there are such people. If you think this
> point is so unclear for so many people, I'd suggest you write a
> clarification draft or submit an errata.  If you think we should
> actually allow the creation in such a case, that's a protocol change,
> and I'd suggest you write a draft to update RFC4862.  With luck, that
> will become the new standard.
>
> I don't think continuing this topic in this thread brings us
> anywhere, so I'll stop here.

This is the topic of allowing or not allowing 64 limit.

I think continuing to defend that 64 limit makes no sense after all
these problems.

The problem is in all these RFCs, and there is no need of a new one.  We 
wrote already too many on this topic of 64.

Alex

>
> -- JINMEI, Tatuya
>