Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 11 April 2019 16:28 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D961203A2; Thu, 11 Apr 2019 09:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 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_MED=-2.3, 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 VhY-YkQ1rDv3; Thu, 11 Apr 2019 09:28:43 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E96C1202E8; Thu, 11 Apr 2019 09:28:42 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3BGSZsG044981; Thu, 11 Apr 2019 18:28:35 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3D83204E8D; Thu, 11 Apr 2019 18:28:35 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C8544204D73; Thu, 11 Apr 2019 18:28:35 +0200 (CEST)
Received: from [10.8.68.84] ([10.8.68.84]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3BGSZnD012024; Thu, 11 Apr 2019 18:28:35 +0200
To: 神明達哉 <jinmei@wide.ad.jp>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Ole Troan <otroan@employees.org>, "draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org" <draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>, "its@ietf.org" <its@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <94941ef0-d0df-e8fe-091b-2e616f595eba@gmail.com> <c052e7a9-9acd-ecdd-9273-3142644dc5cd@gmail.com> <386b9f4c-f9b5-900c-817a-95df68226ed9@gmail.com> <cc9564f5-b049-fa99-31a4-98a9c9c1261a@gmail.com> <856F277E-8F26-48BC-9C57-70DC61AA4E06@employees.org> <c91328aa-72e4-c0be-ec86-5bfd57f79009@gmail.com> <1BF2A47E-3672-462B-A4EC-77C59D9F0CEA@employees.org> <2ba71d54-8f2f-1681-3b2a-1eda04a0abf9@gmail.com> <B618E1B8-1E01-4966-97B2-AAF5FC6FE38A@employees.org> <bf83d3c2-a161-310f-98f4-158a097314a6@gmail.com> <D1A09E57-11E2-4FBC-8263-D8349FBFB454@employees.org> <MN2PR11MB3565A36F02B010B12E709ABED82E0@MN2PR11MB3565.namprd11.prod.outlook.com> <39c49adc-65b2-bfa8-4f97-b1216d7a71a4@gmail.com> <CAJE_bqf0+JjX81TeoqmirgKw4KnHoJdkCmgBx0nfu+-OeWPP3A@mail.gmail.com> <c878f52b-2ce9-7a83-5867-38d7565cd0f2@gmail.com> <CAJE_bqezECHRjQfN4m5t1-3UxQUCUmt12xmxqXQhL+b4T_tkXQ@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b8f5bcdc-bdce-8b85-30e4-d3cd811a5d13@gmail.com>
Date: Thu, 11 Apr 2019 18:28:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAJE_bqezECHRjQfN4m5t1-3UxQUCUmt12xmxqXQhL+b4T_tkXQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/3FFe_-Hd58khfMTnKzdxSSiDR9M>
Subject: Re: [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 16:28:46 -0000


Le 11/04/2019 à 17:21, 神明達哉 a écrit :
> At Thu, 11 Apr 2019 13:26:59 +0200,
> Alexandre Petrescu <alexandre.petrescu@gmail.com 
> <mailto:alexandre.petrescu@gmail.com>> wrote:
> 
>  > Others reported openbsd to work ok with Interface ID of length different
>  > than 64.  Because of that report, I believe openbsd will also work ok
>  > with fe80:1::1/32.
> 
> I guess you mean this thread:
> https://mailarchive.ietf.org/arch/msg/ipv6/2dnG1_yJON6zpGKz7YRWgI55iMc
> 
> It's a big logical leap to conclude that fe80:1::1(/32) can be used as
> a link-local address from that discussion.  First, it's quite clear
> that it's largely about generating global addresses.  In fact, the
> implementor actually clarified that "/64" is used for link-local
> addresses:
> https://mailarchive.ietf.org/arch/msg/ipv6/WetxgYx-kJ1p4xUZbFxf6BikEks
> 
> Secondly, even if this could be interpreted as if this implementation
> allows 96-bit IIDs for link-local addresses, that doesn't mean it can
> use a non-0 bit in the (now 22-bit) intermediate field.  At best it
> can only mean "fe80:1::1/10" (using a 118-bit interface ID) would be
> allowed.
> 
> I'd strongly suggest when you say something like this:
> 
>  > - using fe80::/10 on Cisco, linux and openbsd works ok.
> 
> you confirm it literally "works" by running it by yourself, rather
> than just deducing a conclusion from someone else's word in a
> different topic in your favor.  Otherwise your other assertions will
> look similarly implausible.
> 
> Anyway, as ipv6-over-80211ocb now seems to be removing the possibly
> misleading text of "fe80::/10" intending to allow a non-0 value in the
> intermediate 54 bits of link-local addresses, I have no more comment
> on this in this thread.  I'll stop here.

I agree with the comments on your email.  NExt time I talk about 
implementations I do, not deduced from others' tests.

The text now indeed removes fe80::/10.

Alex
> 
> --
> JINMEI, Tatuya