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

Lorenzo Colitti <> Tue, 28 February 2017 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 853251294B4 for <>; Tue, 28 Feb 2017 05:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eiriE-5Ap6kl for <>; Tue, 28 Feb 2017 05:39:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66E7512951B for <>; Tue, 28 Feb 2017 05:39:24 -0800 (PST)
Received: by with SMTP id 40so13257676uau.2 for <>; Tue, 28 Feb 2017 05:39:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2t7ZwM9j+2ruzJvbeLZ5goRPdp5wZQ/rQ+3hIBVg2RE=; b=rUHd2bzsnCebLMQqBre2OQuFHkrkICQj0j5enmnTg01FjasOcPMKW2Ifsnu+zUP24d Np/K5oUoOixzzotv9SNn4OOiPJCpk4qM81K8/h5VcOHAWEGbUSDnh/35FL/xuIeKGOl9 /NLrXP39G2Y0yWNBSayCXb708GqD4v4ZMBhT0sbjqO14zyAofLNU4493rKXtpwn4E3aG 4ZmooavPDFRQ9gd0xbA8mbjOU/nX9d5HAhN8b3xSwfC1SAtqqZnwIUATX7+nT5CcD8Np SHHkOjH0dIHalvJC2PwkHj8TLuElCoRdlCFiBVbcJmdnZyUQMyRxf3uPhHVfhCTbviT+ FhrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2t7ZwM9j+2ruzJvbeLZ5goRPdp5wZQ/rQ+3hIBVg2RE=; b=Sr6719KWJXhdJy+bVoiGoyQT3zBCgnrl2tD0VF2wK7W+qkmzq6byXEvcAlg/SUZ2QS E5cAm+Rc3Bs217LzNyenKWHFnez9hD8bTDr4wbm32oRNSZ5V3d91tF1ROrQ0Zd2jR5ea 88LVzwhlZC92kGI9xz2jacHpkNFBLwdYBFsCAO99tciKniVEyQV/Y4MaiiX4qk5h43Zp FOdjKB4hzKDjnL9IwfpOQhr8j3rsd8c9h9oEn8O+GzHXSYlHfQ282f7SHbQspOcrSCqx yMKZz6B+U0WJOZ4y8tbDHzIXCNI/Agzxcx24gacqXPSNQBuFqTb3PtlB70YqHuZtZed3 63gw==
X-Gm-Message-State: AMke39kShYLEL/jbUpBXUGPxecQXMF8ut+8ijR+fyZu1gbwPndp8qZIGcFyXo5Tu43iugQt9zJa8Xal0I0KNB8Nz
X-Received: by with SMTP id q195mr981719vkf.155.1488289163230; Tue, 28 Feb 2017 05:39:23 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Feb 2017 05:39:02 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Lorenzo Colitti <>
Date: Tue, 28 Feb 2017 22:39:02 +0900
Message-ID: <>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: james woodyatt <>
Content-Type: multipart/alternative; boundary=001a114388cce60f6b054997523a
Archived-At: <>
Cc: 6man WG <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Feb 2017 13:39:26 -0000

On Sat, Feb 25, 2017 at 3:11 AM, james woodyatt <> 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
<>. 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.