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

David Farmer <farmer@umn.edu> Tue, 28 February 2017 15:46 UTC

Return-Path: <farmer@umn.edu>
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 B69D61295C3 for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 07:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.801
X-Spam-Level:
X-Spam-Status: No, score=-3.801 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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=umn.edu
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 W7KYSysIiTv6 for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 07:46:09 -0800 (PST)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 F32EB1295EE for <ipv6@ietf.org>; Tue, 28 Feb 2017 07:46:08 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 4C75F579 for <ipv6@ietf.org>; Tue, 28 Feb 2017 15:46:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJVbRxLnTvBA for <ipv6@ietf.org>; Tue, 28 Feb 2017 09:46:08 -0600 (CST)
Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 00B32B26 for <ipv6@ietf.org>; Tue, 28 Feb 2017 09:46:07 -0600 (CST)
Received: by mail-ua0-f197.google.com with SMTP id f54so13008549uaa.5 for <ipv6@ietf.org>; Tue, 28 Feb 2017 07:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n4QvM8ClwzBVnx7Vs+v2VXzIHpPe61Gm4Vy1KdlrcJ0=; b=cua6KACJd9DkSTmdsB83fukeqYhmxmsEJ/silXtoMNq5H9PnGW6SkBoqSrNUBguUe3 8X6PXbZNr0X7haRyr53gmdXQleF6kayD5vmpktIHHIeDiTnoZovo1Yq8jH1YHp4GpGMc ylmh1n+EetILM02qGy3cErTztIaN/d801YEPA+Avs5XZBSBSusMHFBa9wZ5ID1G3f2oq LldqmXSLmoJgdvGNUiwqlT2MxNRwCa4YUdgphACAJugkFJg17T2aqtDzeVIOiUhnFoMp gFhpRIlz2yxYjZS2DGrD+ujE9QFcdYfxrCp1c6YIs6l4jYDChyfI0I0CjpASZR8q8Dph ld3g==
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=n4QvM8ClwzBVnx7Vs+v2VXzIHpPe61Gm4Vy1KdlrcJ0=; b=j4KAs3PdDtY9XWf/O6NO5EUdG2BVfyXodwTpX2nPl0M0q/jgqbdsbiWKHR3AfKiuta 8yoS8cj4KKOxyOf0zCtFK3XBIZnB5SnIQNCiWTXEW49B8zygHEoMyr8fNcoPsqVxhfJu N4X4ddc00dMJ0qyJvoel4xBN+gL/m9zvpkdXWBGywwDHwDFJ0QCJlv10JWNBSO843dh+ sZf8zjLLuH8lNb5G1uxnt7GOZDR2wnSwQOi9oh5/P2i0hcbLlMpOiahtY0nclQCxwIrJ 57tOjXqdtHJrSWhPcEqKi7decXzwbsNslRIlOnDCSKBvYw8Kz1kn8QsGRGVcC+PTaC3f yZ4Q==
X-Gm-Message-State: AMke39nhapFGHrApoX96c/YtBnaMkJGZCN8Be9+ExNZO8Ejqx0Gtu+fXm/Ay2KCXNDk4m2C3AHEJQcnxbXZQq+OFKmybgxiorzB+ZevshLFHkUTajcsw5EfEfV/PBu6eWvpn7p5A1gzFDU4RWJg=
X-Received: by 10.31.49.81 with SMTP id x78mr1343527vkx.82.1488296767366; Tue, 28 Feb 2017 07:46:07 -0800 (PST)
X-Received: by 10.31.49.81 with SMTP id x78mr1343515vkx.82.1488296767098; Tue, 28 Feb 2017 07:46:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.89.71 with HTTP; Tue, 28 Feb 2017 07:46:06 -0800 (PST)
In-Reply-To: <CAKD1Yr0qk_njAGnex_FZsYisCVw=eM8hXTr1v+wqvcfX_09wiQ@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>
From: David Farmer <farmer@umn.edu>
Date: Tue, 28 Feb 2017 09:46:06 -0600
Message-ID: <CAN-Dau0ohz3Wp55bs+eoFvSyoUjuKfjzKGSAsJS3wUt3z7TGtA@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: multipart/alternative; boundary=001a114388b01fad77054999181a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1xA92vb14t-XZF07YeK47f09oXc>
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 15:46:11 -0000

On Tue, Feb 28, 2017 at 7:39 AM, Lorenzo Colitti <lorenzo@google.com>; wrote:

> On Sat, Feb 25, 2017 at 3:11 AM, james woodyatt <jhw@google.com>; wrote:
>
>> Let me be more specific then: are you proposing that vendors write code
>> to allow or disallow interface subnets which aren't /64 (or /127)? This
>> is a binary choice; a vendor needs to choose one way or another.
>>
>>
>> I don’t know how I can be more clear about this: I insist that general
>> purpose host operating system developers should be expressly permitted to
>> write code that declines to accept subnet prefixes of any length other than
>> /64 on the grounds that these are not used in general IPv6 networking and
>> the successor to RFC 4291 continues to say so.
>>
>> I know there are operating systems with billions of units in the field
>> today that do exactly this because RFC 4291 and its predecessors have for
>> years given them clear license to do so, and I don’t want to see the
>> publication of I-D.ietf-6man-rfc4291bis as RFC come to remove this license
>> as a side effect of promoting IPv6 to full Standard category.
>>
>> You want to remove that license? I suppose we can continue discussing
>> that, but I think you should try to do it in a separate draft once IPv6 is
>> officially promoted.
>>
>
> What James said. The 64-bit boundary is crucial to ensuring leaf nodes and
> hosts never run out of addresses, which is critical to preserving
> end-to-end connectivity.
>
> The thing about a 64-bit prefix length is that it *never runs out of
> addresses*. Even if you create a million new addresses every second, it
> will take you almost 600 THOUSAND YEARS to run out. We can use that
> property for all sorts of valuable things, many of which we likely haven't
> though of. I fundamentally disagree that "now we have experience running
> IPv6" we know what we can do with it. We really don't, not yet. We're not
> even running 20% of the public Internet on IPv6, and pretty much the
> entirety of people who work on the Internet today learned about IPv4. We
> are bound to IPv4 practices more than we even realize.
>
> I think the 64-bit balance is actually the best thing about IPv6. The way
> to think of it is: IPv6 provides 4 billion times more /64s than IPv4 has
> addresses... and each of those /64s provides unlimited space for
> innovation, all while preserving end-to-end connectivity.
>
> We should not throw that away just because of some arbitrary notion that
> "classful addresses are bad". They were certainly bad in IPv4, because IPv4
> *didn't have enough space*. We don't have that problem in IPv6 today. And
> to those who say we will have that problem tomorrow: why can't we talk
> about that again when we run out of 2000::/3 and we only have 88% of the
> address space left?
>
> So I really don't understand why we count individual IPv6 addresses and
> insist that we need to be able to assign a subnet a /124? What's the point?
> It can't be /64s cost money - you can buy 42,950 of them for 1 cent
> <https://www.arin.net/fees/fee_schedule.html>;. Is it address
> conservation? But the numbers that have been run again and again in
> multiple RFCs and RIR policies say that it's not a problem. So why, then? I
> don't think the ND cache exhaustion attacks are a sufficient reason.
> They're pretty easy to defend against.
>

I'm fine with OS requiring /64, that is, and should be, the lowest common
denominator, this is an operational fact we all have to deal with.
Everything MUST support /64. However, saying that host can refuse other
than /64, admits this is a parameter could be something other than /64.

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, I think it says /64 only now and forever.  And, I don't think
that is correct.

I think we should be saying OS MAY allow configurations other than /64, at
least with manual configuration, and maybe DHCPv6 too.  Further, operators
should be allowed do configure other than /64, when they know all devices
on a network can support such a configuration.  If they don't know this for
sure they SHOULD configure /64.

Saying that /64 is required is a false imperative, at best it is an
aspirational statement not an actual requirement, at it's worst it creates
confusion and incompatibilities. The fact that RAs allow other lengths
means this has always been a parameter.  We have defined this as a
parameter not as a constant. Trying to redefine it as a constant, only
confuses people.  Saying that this is a parameter that is recommended to be
64 makes sense.  I'd even include the consequences of not using 64.   But,
saying it's a parameter that is required to be 64, sound like it's a
constant or at least masquerading as a constant, and only confuses people.

Thanks

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================