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

神明達哉 <jinmei@wide.ad.jp> Thu, 11 April 2019 15:21 UTC

Return-Path: <jinmei.tatuya@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 0075B120136; Thu, 11 Apr 2019 08:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Level:
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 gtcSOsX7vfmn; Thu, 11 Apr 2019 08:21:50 -0700 (PDT)
Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62B91120392; Thu, 11 Apr 2019 08:21:50 -0700 (PDT)
Received: by mail-wr1-f67.google.com with SMTP id s15so7853710wra.12; Thu, 11 Apr 2019 08:21:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Yg86yakorKIjMJVR/AkvnhQudyOu+JZrHM3IlkXHgI=; b=k4DurF48D48ZMnNRF7QJ/AT6Jvc/VMOfrNxIqXtr3kwT0kKK7+NnU4eFR5YiD+RHbg hwC/VrRN2cLJd+BQeFMQwbSAGzuafmNqWMhGpGSvQMchdFGNRB0cju5/RW3vp1VwUfth FQNEcJlHZn2J7NiIva3fOBK1cPTQaziu76QCVxJjNkj8IQ8RsPExVWsDf5pTmUCgHQc9 yqow+WCoQXeCFLyXzojkXillfLodtvUkUfqLV/oXZ8AfEUZ+IATvQtT4QJh5MraN/EMi nlDnmmGUFQgaThkgH/V6906s9d56BIxtQv/Ege12+hlATjTItFT3fRd7Lmo6wv/USVJ0 g5UQ==
X-Gm-Message-State: APjAAAVRFdQ3kUxfbTweCfQ+RoJTUY1IJw1FU22cbfzHYeIuyfp+6NvU M7Bvki80skF0B1IWyUsN7JZB1gecWcT0VdxmU2E=
X-Google-Smtp-Source: APXvYqxcxWqitZ1Ce2dRVlKV3YvWSsGX1P9fRjUicbfvpQbgCaUaO79rWt34rokYulEnob4QnXBquSjhOZhW7uPEj7w=
X-Received: by 2002:adf:e949:: with SMTP id m9mr30536944wrn.237.1554996108527; Thu, 11 Apr 2019 08:21:48 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <c878f52b-2ce9-7a83-5867-38d7565cd0f2@gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Thu, 11 Apr 2019 08:21:36 -0700
Message-ID: <CAJE_bqezECHRjQfN4m5t1-3UxQUCUmt12xmxqXQhL+b4T_tkXQ@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
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>
Content-Type: multipart/alternative; boundary="000000000000ad0de0058642bef2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/f2Hqhyi4AwdyTRe-GGGPuSYKgrU>
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: Thu, 11 Apr 2019 15:21:53 -0000

At Thu, 11 Apr 2019 13:26:59 +0200,
Alexandre Petrescu <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.

--
JINMEI, Tatuya