Re: [ipwave] [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> Tue, 09 April 2019 20:13 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41012033B; Tue, 9 Apr 2019 13:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 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] 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 g1j7EYV9pZNh; Tue, 9 Apr 2019 13:13:38 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 9E667120335; Tue, 9 Apr 2019 13:13:37 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x39KDV7b083396; Tue, 9 Apr 2019 22:13:31 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9F761207EE5; Tue, 9 Apr 2019 22:13:31 +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 86E7F2075A1; Tue, 9 Apr 2019 22:13:31 +0200 (CEST)
Received: from [10.8.68.16] ([10.8.68.16]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x39KDU8S013269; Tue, 9 Apr 2019 22:13:30 +0200
To: 神明達哉 <jinmei@wide.ad.jp>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Pascal Thubert <pthubert@cisco.com>, "<int-dir@ietf.org>" <int-dir@ietf.org>, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org, its@ietf.org, IETF Discussion <ietf@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> <CAJE_bqf2y=Thg7RM5-ZMXsTrxf9QGJH_E=X3aFEcj-WPZj0eBQ@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <977d1de2-cb6a-4236-4077-2db687191a1f@gmail.com>
Date: Tue, 09 Apr 2019 22:13:30 +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_bqf2y=Thg7RM5-ZMXsTrxf9QGJH_E=X3aFEcj-WPZj0eBQ@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/its/pYPmKfAsp8nGCv9U_3GGe_WEHtk>
Subject: Re: [ipwave] [Int-dir] Intdir early review of draft-ietf-ipwave-ipv6-over-80211ocb-34 - 'conforming IPv6' - fe80::/10 vs fe80::/64
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 20:13:40 -0000

Tatuya,

Thank you for the message.

Le 09/04/2019 à 19:14, 神明達哉 a écrit :
> At Tue, 9 Apr 2019 16:11:33 +0200, Alexandre Petrescu
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> wrote:
> 
>>>>> "
>>>>> 
>>>>> This subnet MUST use at least the link-local prefix fe80::/10
>>>>> and the interfaces MUST be assigned IPv6 addresses of type 
>>>>> link-local. " If this is conforming IPv6 then the MUST is
>>>>> not needed.
> [...]
>>>> Do you disagree with it?
>>>> 
>>>> (the reasons why I put there /10 and not /64 are the following:
>>>> LLs work in linux with any length between 10 and 64, the ND
>>>> spec does not restrict to 64,
>>> 
>>> No, but IPv6-over-foo documents usually do apply that
>>> restriction, rather than define 118-bit IIDs.
>> 
>> It is good to know about practice in IPv6-over-foo documents.
>> 
>> What should I do in the IP-over-OCB document: continue that
>> restriction? or define 118bit IID with filling in 0s between 64 and
>> position of last bit of prefix?
> 
> I don't have a strong opinion about specifically what this doc
> should say, but "MUST use at least the link-local prefix fe80::/10" 
> shouldn't be interpreted as if we could use fe80:1::1 as a valid
> IPv6 link-local address without violating the current addressing 
> architecture (RFC4291, Section 2.5.6).  If this text can be 
> interpreted that way, we should definitely revise it.

Thank you for the suggestion.

I would like to ask you whether I can ask you to propose a formulation
of using fe80::/10 without violating RFC4291 2.5.6?

Maybe: "The OCB interface MAY use IPv6 link-local addresses with prefix
length 10 without violating RFC4291 2.5.6, provided such address is
allowed by IANA".

Would this text be ok?

Or do you rather think we should not allow LLs on OCB with any other
prefix than fe80::/64?

>> (in implementation I already did fe80:1::1/32 as a link-local
>> address on OCB at 5.9GHz; the prefix is fe80:1::/32 and the IID is
>> ::1 of length 96 with 32 leading 0 bits; it works between cars)
> 
> It's a violation of the current addressing architecture.

But it does not violate IANA allocation, right?

> Anyone can do whatever they want in their pet implementations, but
> unless/until this document updates RFC4291 so that it explicitly
> allows a non-0 value in the intermediate 54 bits, it has nothing to
> do with this current discussion.  Non-compliant implementations can
> work as their author intends, especially if they don't care about 
> interoperability.  But that doesn't make it magically standard 
> compliant.

Thank you for the suggestion.

Can I dare to read you suggestion as implying that we should add an 
"Updates: 4291" text on the first page of the draft?

Or should I interpret it as a suggestion to not even try to update RFC4291?

About the doubting of authors interoperability worries: the authors do 
care extensively about interoperability.  The interoperability of LLs, 
at this time, is being checked against linux versions, and some BSD flavor.

Alex

> 
> -- JINMEI, Tatuya