Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

Erik Kline <ek@google.com> Fri, 24 February 2017 09:04 UTC

Return-Path: <ek@google.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAFA12962F for <ietf@ietfa.amsl.com>; Fri, 24 Feb 2017 01:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, 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 s0Z2vQB2RFQw for <ietf@ietfa.amsl.com>; Fri, 24 Feb 2017 01:04:52 -0800 (PST)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 DC1D91293F8 for <ietf@ietf.org>; Fri, 24 Feb 2017 01:04:51 -0800 (PST)
Received: by mail-yb0-x229.google.com with SMTP id n76so3898783ybg.3 for <ietf@ietf.org>; Fri, 24 Feb 2017 01:04:51 -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=quwmVS0HgN0VlF0M5EAcmLxVQ4XGDvzkpXE+pUK+Yew=; b=wA3XZXEzM8czzMbGjqsFIPgH5RoiJPtTCUhweRZwAqyknGbXunQDDokenK7tyhEbhl 811bxorudcw/AeMmRXi/FJcp06qCPwbBp/tKmfRJv0o3Qw4SHZGmqjFZN93pb6r37SHH iAhfFMYD0mF+43Pnv+OQdUJcPljLnSxRYNRVwaIj78Dpj7Xn+YH9anRdVwu7pru5Etmd AJdwKTP4yHaAsiqBZ2i+t6sscaDXxjEglCvh8rMQR+io0DBIiWNixnRBKf72Eecl6/Ee U/50E3xu/RMdaxEj0ai71kFK5WW6+jtkGaqxdd2y7PVag1zJm9VOxMyOW+tpgylJNgIZ GXgA==
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=quwmVS0HgN0VlF0M5EAcmLxVQ4XGDvzkpXE+pUK+Yew=; b=Xds5TDLRGYS12A5L9co3pY7LDRzAnrLOg2e74fzmnH3+k9z47vCGok40rhhsXhJgM4 AWq7EW052KuvqSk4cQr0cs2s0WMpnMDUs/Hn4OgVFW6VJGa5btUz6UX8Yg1OrwUiJumd bBQzFBRHKFp/e5esLn8tFPM4Pu19N6LC15j4dNDOzqoNdY5yE2HFvn5vNOvorxvhRAir GvBQQbA0Ldwd168At5ZacZZj8ZqSb6pBNAnegc4Y/8jWs5DVmK7YFkol8GBsu6hzGr5R KmH7Z3owNhUWh9M45yGbNRyVz3LopbiO1PvMf3jXnhF45I9gDCJia4xnZpaxdFO+tVsx 6ZdQ==
X-Gm-Message-State: AMke39mZv8x6WxMZ1hVuOqDoEtGga6sP0CW5ZXSMhoC8ZTJh7MwpXTIsNrLnKTi72GILeZP/VofEiucM3HuuQl/V
X-Received: by 10.37.7.5 with SMTP id 5mr898956ybh.8.1487927090807; Fri, 24 Feb 2017 01:04:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.207.4 with HTTP; Fri, 24 Feb 2017 01:04:30 -0800 (PST)
In-Reply-To: <CAL9jLaaOWm+iQMOOGg00CXrhHtKZ0PxBswaJTUn6wf-EDq4KgQ@mail.gmail.com>
References: <58AF313D.3020905@foobar.org> <20170223190730.GL2367@Space.Net> <m2poi8s2cf.wl-randy@psg.com> <CAL9jLaYuDJm4qROZ3bgDxamG9Xo8Ot88Ej5yHhO7Mj7q+77DCg@mail.gmail.com> <CAKD1Yr0hc3DYK7tg0Vi0J5kEdd-CkD4D+cJ7LbaZw5WfNS=ZEg@mail.gmail.com> <CAL9jLaaOWm+iQMOOGg00CXrhHtKZ0PxBswaJTUn6wf-EDq4KgQ@mail.gmail.com>
From: Erik Kline <ek@google.com>
Date: Fri, 24 Feb 2017 18:04:30 +0900
Message-ID: <CAAedzxqPzPweW6RQUfHfUB0ZktofuY8HxKz-LbiBNWg+2ZoBaw@mail.gmail.com>
Subject: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="94eb2c069d44bbd28005494305f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/j2WN0kdS-Zfx-5R_CE5QbBv7AZE>
Cc: IPv6 Operations <v6ops@ietf.org>, ietf <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2017 09:04:55 -0000

On 24 February 2017 at 12:41, Christopher Morrow <morrowc.lists@gmail.com>
wrote:

> gosh people are being literal today :)
>
>
> On Thu, Feb 23, 2017 at 10:34 PM, Lorenzo Colitti <lorenzo@google.com>
> wrote:
>
>> On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow <
>> morrowc.lists@gmail.com> wrote:
>>
>>> > The IESG plans to make a decision in the next few weeks, and solicits
>>> > final comments on this action. Please send substantive comments to the
>>> > ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments
>>> may be
>>> > sent to iesg@ietf.org instead. In either case, please retain the
>>> > beginning of the Subject line to allow automated sorting."
>>>
>>> Nothing in the past really matters here, what matters is: "Is the bis
>>> draft all set, did we fix all the things which must be fixed before this
>>> draft becomes a real 'standard'?"
>>>
>>
>> I don't think you can say nothing in the past matters here. We know that
>> there have been host implementations that relied on this guarantee, and we
>> have to consider that if we change the standard, those implementations will
>> become non-compliant.
>>
>
> I don't think the proposed (now 160+ messages back) text really says:
> "FREE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64
> because the application you are being placed into requires it (slac, blah
> and blah and ilnp and blah - see rfc7k) then do that, else any other prefix
> length works"
>
> how's that not 'ok' for host folks? "Hi, my host is going to be in a slaac
> world.. so /64 it is!"
>

For manual assignment among consenting adults: as you like it.  (For all
prefixes longer than /64, the trailing 64bits would still end up being
unique; there is no real issue here.)

And I gather everyone agrees that at a minimum the /127 RFC and other
working-group-graduated documents should be suitably incorporated and
referenced.

Otherwise, this feels like another round of "why isn't IPv6 just 128bit
IPv4?"  IMHO having /64 as the logical unit of allocation to network leaves
is a very good thing.