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

Ole Troan <otroan@employees.org> Wed, 10 April 2019 08:22 UTC

Return-Path: <otroan@employees.org>
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 C78D11202CB; Wed, 10 Apr 2019 01:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 rVA26GH4TgqO; Wed, 10 Apr 2019 01:22:41 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640DD1200FE; Wed, 10 Apr 2019 01:22:41 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [173.38.220.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 49D1DFECC047; Wed, 10 Apr 2019 08:22:40 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id AE14112D134C; Wed, 10 Apr 2019 10:22:37 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <cc9564f5-b049-fa99-31a4-98a9c9c1261a@gmail.com>
Date: Wed, 10 Apr 2019 10:22:37 +0200
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Pascal Thubert <pthubert@cisco.com>, int-dir@ietf.org, draft-ietf-ipwave-ipv6-over-80211ocb.all@ietf.org, its@ietf.org, ietf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <856F277E-8F26-48BC-9C57-70DC61AA4E06@employees.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>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/lzZBIAA7VvF_vGLtRYb-26_hjZ4>
Subject: Re: [ipwave] 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: Wed, 10 Apr 2019 08:22:43 -0000

>> "At least" does not mean "the value should be at least 10" in that phrase.
>> 
>> Do you think we should say otherwise?
> 
> To me there is nothing in the actual text to tell me that "at least"
> qualifies the "/10". I think you could rephrase as
> "This subnet's prefix MUST lie within the link-local prefix fe80::/10 ..."
> 
> However, see Jinmei's messages about conformance with RFC 4291.
> 
> I think there might be unexpected side effects from using an
> address like fe80:1::1. What if some code uses matching with
> fe80::/64 to test if an address is link-local? I agree that
> would be faulty code, but you would be the first to discover it.

Indeed.
If you absoultely must cut and paste text from 2464:

5.  Link-Local Addresses


   The IPv6 link-local address [AARCH] for an Ethernet interface is
   formed by appending the Interface Identifier, as defined above, to
   the prefix FE80::/64.

       10 bits            54 bits                  64 bits
     +----------+-----------------------+----------------------------+
     |1111111010|         (zeros)       |    Interface Identifier    |
     +----------+-----------------------+----------------------------+


I presume there is support for brining 802.11p and other 802.3 links?
And that the MAC address length of this link type is also 48 bits?

If the two assumptions above hold, then I see zero justification for pushing the 64 bit boundary in this draft.

Ole