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

Alexandre Petrescu <> Tue, 28 February 2017 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EC701295A9 for <>; Tue, 28 Feb 2017 06:49:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kSjbSJmKah7z for <>; Tue, 28 Feb 2017 06:49:10 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89CD012953F for <>; Tue, 28 Feb 2017 06:49:10 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1SEn8KN030751 for <>; Tue, 28 Feb 2017 15:49:08 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 92858208D7D for <>; Tue, 28 Feb 2017 15:49:08 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 867E4208E8F for <>; Tue, 28 Feb 2017 15:49:08 +0100 (CET)
Received: from [] ( []) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1SEn8sB012590 for <>; Tue, 28 Feb 2017 15:49:08 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
References: <> <> <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Tue, 28 Feb 2017 15:48:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
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 14:49:12 -0000

Le 28/02/2017 à 14:39, Lorenzo Colitti a écrit :
> 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.

Because with this 64 limit the network can not grow at the edges.

Cellular network operators dont assign multiple /64s per connection - 
just one.  I would like to ask you what do you think about this?  Do you 
think cellular network operators could assign multiple /64s per one 
connection?  Or a /63?

Extending a network with bridging tools can only grow that much (not 
enough for some settings like vehicular networks).  IP routing can grow 
it much more.  I would like to ask you what do you think about this?  Do 
you think bridging is enough to grow at the edges?

SLAAC/Ethernet can not work with plen 65 or a bigger value.


> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------