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

Lorenzo Colitti <lorenzo@google.com> Tue, 28 February 2017 16:30 UTC

Return-Path: <lorenzo@google.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 79F50129614 for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 08:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 HHIP2Cw4dVAp for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 08:30:13 -0800 (PST)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 0F825129613 for <ipv6@ietf.org>; Tue, 28 Feb 2017 08:30:13 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id v200so12280576ywc.3 for <ipv6@ietf.org>; Tue, 28 Feb 2017 08:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K1ZDv33wTpLYpgzipd6/o9ux2d4GjOWnME4EK+sV1aw=; b=aqpB9r9AQidkvlLNTm+RfJcuBgm5+jl4PFz9+wOE9IjRa/TrXTYwr3+JODuSKOM6or W0sODC4zmVb3LdqvGNNe91W/NdL6kO0lRNNxFKqC8BXUJ+x5NMu/TZNLpbhF2SzJGiH+ LCRRyNfHR0BH2IM/LMI41gaiX0F6egv5bR5r7+RGzlkBfRnczftp6Wc+qbWytZX3MmQB g2IGrEz5todiNL2XQX3smdILxEeBrU692VM1B6ul3XuNQ3jbqz7E/baMtgxPLR/UJ4A+ WoZFFIimXC7axRcXrPlN6vgSznR4zNoE8UQ8KEkqyFxcQuLTb2Nf8bOuXlU8DjIaIln1 OPdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K1ZDv33wTpLYpgzipd6/o9ux2d4GjOWnME4EK+sV1aw=; b=p8triw/dy14OQzekhvLDFSB2j6+R6NLAs1w4maMc/yzpH2qWzQr7M4vLGH38zaPt7l ndfG6zqHw4I2bJVLRs3qJEmRORQKx417YGnnKNi/FtETmDevdMQZK15b0sWy+GGEUQsw tDK2ngaYIuzWg5NgvGbn2+1rdSxXJOJyJhea6SMtiMu4Ybcxf8ysIkFZz/d8L5zsqdav D2Z901jehttP8DPG19AY9aQU0jQ5nyLivze8cIpX4Qs9g9fFbfY3cvaK7kbB0xcXamXt cIGgqQfQOgt8R6Bai/RU0U6pqwJBwftYe5VInYLpKLBt5J2LHHp6Ls6D7tqWo8PQ22M/ 2PpA==
X-Gm-Message-State: AMke39nMkIjurUNOCeBRcGsxbAdajwlaWO/1NkhTfHUq/IGEkNajiIuoAtWI/NnuAadd+n7BmhF6HHoVvRVSLn6N
X-Received: by 10.129.98.70 with SMTP id w67mr1131495ywb.184.1488299412153; Tue, 28 Feb 2017 08:30:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.51.139 with HTTP; Tue, 28 Feb 2017 08:29:51 -0800 (PST)
In-Reply-To: <CAN-Dau0ohz3Wp55bs+eoFvSyoUjuKfjzKGSAsJS3wUt3z7TGtA@mail.gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org> <F7C230DE-4759-4B78-ABF2-6799F85B3C62@google.com> <58B014F6.2040400@foobar.org> <6DA95097-8730-4353-A0C9-3EB4719EA891@google.com> <CAKD1Yr0qk_njAGnex_FZsYisCVw=eM8hXTr1v+wqvcfX_09wiQ@mail.gmail.com> <CAN-Dau0ohz3Wp55bs+eoFvSyoUjuKfjzKGSAsJS3wUt3z7TGtA@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 01 Mar 2017 01:29:51 +0900
Message-ID: <CAKD1Yr0wK8EiAbz39EZz-xZLtsSV2JROSzNECKtGo36Zc=RZ0Q@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: David Farmer <farmer@umn.edu>
Content-Type: multipart/alternative; boundary="001a11471baec83c0c054999b58d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4s__xF2ffIOq_73dPTFIHqlsgtY>
Cc: james woodyatt <jhw@google.com>, 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: Tue, 28 Feb 2017 16:30:14 -0000

On Wed, Mar 1, 2017 at 12:46 AM, David Farmer <farmer@umn.edu> wrote:

> However many OSes also allow configurations other than just /64, is this
> OK? Is that how RFC4291 should be interpreted? Honestly, I don't read it
> that way,
>

IMO the important question is not "should an OS refuse to configure a /65
when manually configuring an address". I think the much more important
questions are, "can the OS assume that it can use the full 64 bits to form
an IID", and "will this link ever run out of IPv6 addresses". The answers
to those should be yes and no.


> I think we should be saying OS MAY allow configurations other than /64, at
> least with manual configuration, and maybe DHCPv6 too.
>

I really don't want to use a network that provides a /120 and requires
DHCPv6 to connect. Not only does it offer subpar functionality, it does so
for no good reason. At least in IPv4 there was a reason: there weren't
enough addresses. Would you want to use such a network?

Another thing I think we should avoid is to remove the fixed 64 barrier and
open the door to having this debate again and again, once for every new
IPv6-over-foo document and once for every new address configuration
protocol (today we have SLAAC and DHCPv6, who knows what we'll have in the
future).

We have defined this as a parameter not as a constant.
>

I really don't understand this statement. How can you say that it's a
parameter, given that every RFC that has been published on this topic
starting from 1998 states that (most) IIDs are 64 bits long?

Most of the code in most implementations treated this a parameter, but
there is code that just takes the 64-bit length at face value, and is well
within its rights to do so, because it's specified by the standard.