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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 10 April 2019 09:22 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 E349A120193; Wed, 10 Apr 2019 02:22:52 -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 neDQa_RrgCZC; Wed, 10 Apr 2019 02:22:50 -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 7DCA1120021; Wed, 10 Apr 2019 02:22:50 -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 x3A9MgJV021663; Wed, 10 Apr 2019 11:22:42 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C00DB2044BD; Wed, 10 Apr 2019 11:22:42 +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 B239D2044BC; Wed, 10 Apr 2019 11:22:42 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x3A9MgBJ003930; Wed, 10 Apr 2019 11:22:42 +0200
To: Ole Troan <otroan@employees.org>
Cc: Brian E Carpenter <brian.e.carpenter@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
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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <2ba71d54-8f2f-1681-3b2a-1eda04a0abf9@gmail.com>
Date: Wed, 10 Apr 2019 11:22:42 +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: <1BF2A47E-3672-462B-A4EC-77C59D9F0CEA@employees.org>
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/XCvh3I-z3ZvQioxT2WEHLJX9zWM>
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 09:22:53 -0000


Le 10/04/2019 à 11:04, Ole Troan a écrit :
>>>>> "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:
>>
>> YEs, that is how we started.  We cut and paste 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 bridging 802.11p and other 802.3 links?

In the IP-OBUs that I know there is IP forwarding between 802.11-OCB 
(earlier 802.11p) and 802.3, not bridging.

In some IP-OBU (Internet Protocol On-Board Unit) some non-OCB interfaces 
are indeed bridged.  E.g. the Ethernet interface is bridged to the WiFi 
interface; that helps with DHCP, tcpdump and others to see one a single 
- bridged - interface.

Bridging may be, but it is not a MUST.  There is no necessarily any 
bridging between the 802.11-OCB interface and other interface, neither 
bridging between the multiple 802.11-OCB interfaces that might be 
present in the same computer.

Do you assume bridging of 802.11-OCB interface to Ethernet interface is 
always there?

Note: I also heard many comments suggesting that EAL is akin to 
'bridging'.  I do not know whether you refer to that perspective.  If 
yes, we can discuss it separately.

Alex

[...]

>>> And that the MAC address length of this link type is also 48 bits?
>>
>> YEs, the length of MAC address on 802.11 mode OCB is also 48.
>>
>>> If the two assumptions above hold, then I see zero justification for pushing the 64 bit boundary in this draft.
>>
>> Let me try  to understand the first assumption.
> 
> 
> Ole
>