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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 28 February 2017 14:49 UTC

Return-Path: <alexandre.petrescu@gmail.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 4EC701295A9 for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 06:49:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSjbSJmKah7z for <ipv6@ietfa.amsl.com>; Tue, 28 Feb 2017 06:49:10 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CD012953F for <ipv6@ietf.org>; Tue, 28 Feb 2017 06:49:10 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v1SEn8KN030751 for <ipv6@ietf.org>; Tue, 28 Feb 2017 15:49:08 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 92858208D7D for <ipv6@ietf.org>; Tue, 28 Feb 2017 15:49:08 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 867E4208E8F for <ipv6@ietf.org>; Tue, 28 Feb 2017 15:49:08 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v1SEn8sB012590 for <ipv6@ietf.org>; Tue, 28 Feb 2017 15:49:08 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: ipv6@ietf.org
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: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <c690af05-c102-f917-8933-433bc8b1dbac@gmail.com>
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: <CAKD1Yr0qk_njAGnex_FZsYisCVw=eM8hXTr1v+wqvcfX_09wiQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4OiwGp8BzASR3Lu-Z_0IV_aqcJw>
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 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 <jhw@google.com
> <mailto: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.

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.

Alex

>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>