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

神明達哉 <jinmei@wide.ad.jp> Fri, 03 March 2017 19:14 UTC

Return-Path: <jinmei.tatuya@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 DDDD91295C5 for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 11:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 onYTdDYHqgPI for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 11:14:02 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 DBAC31204D9 for <ipv6@ietf.org>; Fri, 3 Mar 2017 11:14:01 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id v125so12262804qkh.2 for <ipv6@ietf.org>; Fri, 03 Mar 2017 11:14:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lC8IRVDxHVwvb8TSuV/PTVRBaj15EQZOt2wVKexNFtg=; b=dHOyQf8fqtTgVnR9LGZW+MFxmww+sIzBaTd3Fap1HaAmU7l72p/j6F5yNzUXnrH1uY J3CSV6qvIpwJNYxhHP/BfEoaSNjh6uaXH1iznFXobj9Ofj7CxaoHmikY5kDDEOx6bNGO KPqsFMfDleRn63EEEgY9IGIFDqoslc0k1Io+7Pk715QLVaTC7mUq4ll+kMzLXlvyf/MW o2Ou/sUxWSK/M4rTYFd/mhkp/vhOcag5cSU6hc+vC/fGeqm47kMmJ+qcRZsAKkS8gMJ5 LXvlfw5LvUs5WKuiMMMQ6OChdfYF4gDAllqgrN8PGCAKxbxHM3dtzT7cWktoN0auhtrH SkvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lC8IRVDxHVwvb8TSuV/PTVRBaj15EQZOt2wVKexNFtg=; b=j8pWeM1MkfwSbWhvG+oFwAkfnu3fhlOnk6SgbYd72G63Gb/9wIk9GmOj2pbGfzBGcY KZScqp3DUMcpRAWuhjpj0haHXZCQzvmhy4nzdigGHuJVURQyoR05mDjbM9H/Jwc4R0Yl npPvnrt95ZmkD9k8vYYEZhkYrqMVzhDJz9wBwbX4S0TxvW9Q9snRV/L7TNnQDb/iXFH2 G3LlUOplHUMzlUtemogm1+Z2p681fm43U8ildtxj2coXB6uZTJ8Xm234d3H0uOxqngAq BimEf7WID2iV59du76gfIYdZj1fxiqL+QkfTMCahV0Wxh8aJtKGB7buSjrOG7ngbVMl5 7Cfw==
X-Gm-Message-State: AMke39kkkVu7Nd8JMLM+aMPr0E+SKK3iFRmEwpNgk9vaI0rBFmtpm13GxqQhYlA6UG0mB3tbYWTmVUwRrasbeg==
X-Received: by 10.200.56.48 with SMTP id q45mr4501860qtb.220.1488568440934; Fri, 03 Mar 2017 11:14:00 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Fri, 3 Mar 2017 11:14:00 -0800 (PST)
In-Reply-To: <0bab257c-878e-3a29-70e5-65f3367553c7@gmail.com>
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> <0bab257c-878e-3a29-70e5-65f3367553c7@gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Fri, 3 Mar 2017 11:14:00 -0800
X-Google-Sender-Auth: O7bla3tS1BHEq7PTS5rxPG8VyWg
Message-ID: <CAJE_bqfSm2TerO2c=737QsOeV51-kSs1vx-TfjqzDMY+T6dUvA@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GtweLhJ9U2fvGKPRmfUyHPi92NA>
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 19:14:03 -0000

At Fri, 3 Mar 2017 10:58:59 +0100,
Alexandre Petrescu <alexandre.petrescu@gmail.com>; wrote:

> > 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?

No.  I meant it wouldn't consider a destination address that matches
fe80::/10 but not fe80::/64 to be on-link for any of its local links.

> 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.

The BSD implementation doesn't (auto)generate a link-local address
that does not match fe80::/64.  It also doesn't send a packet to a
destination that matches fe80::/10 but not fe80::/64 to outside of the
node.  So I don't see any possibility of incompatibility, at least in
practice.

You may not *like* that implementation, but to me, it's merely a
matter of taste, not about correctness.

> > 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?

zero, as specified in RFC4291 and RFC4862 (btw I don't understand what
you mean by "when trying to recognise an LL address it has just
generated" in this context).

--
JINMEI, Tatuya