Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 03 March 2017 09:59 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC55D12941E for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 01:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level:
X-Spam-Status: No, score=-5.333 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_HI=-5, 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 40AujRdmDYEu for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 01:58:57 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3711297AC for <ipv6@ietf.org>; Fri, 3 Mar 2017 01:58:56 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v239wruF019016; Fri, 3 Mar 2017 10:58:53 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3C52203FE8; Fri, 3 Mar 2017 10:58:53 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D49EC20122C; Fri, 3 Mar 2017 10:58:53 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v239wrEg008129; Fri, 3 Mar 2017 10:58:53 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: 神明達哉 <jinmei@wide.ad.jp>
References: <20170223134026.GI5069@gir.theapt.org> <58AF726A.3040302@foobar.org> <F7C230DE-4759-4B78-ABF2-6799F85B3C62@google.com> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <CAN-Dau0s04c=RV0Y8AGaxBPFui41TWPTB+5o0K2Lj-iah0An1w@mail.gmail.com> <CAL9jLaYirty22iGiEjEaYq3_KA1FZhxBTOBWuFOXQ9C-WPd5xQ@mail.gmail.com> <CAN-Dau0n6oFm538XdJOcuO1yg92BCDD3mBu5YfBVm_+g-gtcKA@mail.gmail.com> <CAL9jLaYO=uYgVfSZ0SoSe0SujJ1xgwEKE8WLzo_keJHywgXTtg@mail.gmail.com> <CAN-Dau1vJV5O_Ythp6THkAu4-YZXV82Upny1V+ybbjCVZQQX=A@mail.gmail.com> <27cce319-18ac-5c0e-3497-af92344f0062@gmail.com> <de4988be-6031-08d9-84ce-21c3fa4f9bc9@gmail.com> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <CAO42Z2z7v4gDk91b6Of-1sczV88m3B9kzn0MeJU_VBJ416k6Ww@mail.gmail.com> <ae35b45a-0398-840f-fc0d-1f64dd2fcc58@gmail.com> <CAJE_bqdZezDRti5LqCKnmU9QkwwhdejP22gXwk3wLKiS0mhx+Q@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <0bab257c-878e-3a29-70e5-65f3367553c7@gmail.com>
Date: Fri, 03 Mar 2017 10:58:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAJE_bqdZezDRti5LqCKnmU9QkwwhdejP22gXwk3wLKiS0mhx+Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bNTm3LIPxReZ6YGJLaS9DQzDKwY>
Cc: 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 09:59:00 -0000

Le 03/03/2017 à 03:24, 神明達哉 a écrit :
> On Tue, Feb 28, 2017 at 4:04 AM, Alexandre Petrescu
> <alexandre.petrescu@gmail.com> wrote:
>
>> Finally, there is no advice of what bits to put between fe80:: and
>>  a 64bit the Interface ID - zeros or ones?  linux says it's a
>> fe80::/64 and IIRC BSD says it's a fe80::/10.  The routing entries
>>  based on that can make for interop problems.
>
> I don't know exactly what you mean by "BSD says it's a fe80::/10",

Tatuya, sorry, that may have been a mistake on my part.  That was
based on a vague recollection.

> but BSD variants use a 64-bit IID to configure (e.g) an ethernet
> interface with a link-local address, as specified in RFC4862 and
> RFC2464.
>
> They also only recognize addresses that match fe80::/64 as on-link:

When you say 'recognize' you mean by using the below macro?  If so, it 
may be quite approximate and vague to recognize on 10bit something that 
is generated on 64bit.  A precise recognition would be on 64bit.

> Destination                       Gateway Flags Netif fe80::%em0/64
> link#1 U           em0
>
> On the other hand, BSDs' implementation of the
> IN6_IS_ADDR_LINKLOCAL() macro only checks the first 10 bits:
>
> #define IN6_IS_ADDR_LINKLOCAL(a)        \ (((a)->s6_addr[0] == 0xfe)
>  && (((a)->s6_addr[1] & 0xc0) == 0x80))
>
> If you mean this by "fe80::/10", yes, BSDs hardcorde /10 for
> link-local.

Yes that 10 comes out of 8 plus the 2 of the 0xc0 mask.

If so, it means BSD uses a 10bit mask to recognise a LL, but uses a
64bit mask to generate an LL.  Maybe it is prudent enough.

BUt it may not be correct.  The right way would be to use precisely same
generation and recognition masks.

Otherwise there can be risks of incompatibility, address space waste, 
and probably others.

I guess the programmer assumes the bits between 10 and 64 are simply 0
(others may say it's 1).

But we should not say the generation is using a 10bit mask and
recognition is using a 64bit mask, nor vice-versa.  It reads incorrectly.

> But it has nothing to do with the length of IIDs.

Well, if the length of the IID is 64, and the fe80::/10 recognition is 
hardcoded at 10, then what does BSD put between position 10 and 64 when 
trying to recognise an LL address it has just generated?

Alex

>
> -- JINMEI, Tatuya
>