Re: draft-bourbaki-6man-classless-ipv6-00

Lorenzo Colitti <lorenzo@google.com> Fri, 02 June 2017 16:08 UTC

Return-Path: <lorenzo@google.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 28D3B1270B4 for <ipv6@ietfa.amsl.com>; Fri, 2 Jun 2017 09:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, 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 PbQnwf8ujr4W for <ipv6@ietfa.amsl.com>; Fri, 2 Jun 2017 09:08:34 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 932431243FE for <ipv6@ietf.org>; Fri, 2 Jun 2017 09:08:34 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id w1so42461298vkd.2 for <ipv6@ietf.org>; Fri, 02 Jun 2017 09:08:34 -0700 (PDT)
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=T4z9pQFfL1mToQ46McSiTDE93hV3m5ak9cxDqeNTbH4=; b=eaD3DQuxq94OYsBOW1rzVc+Pas9nCxoGfwxvNKZ8synkMFCnO7sbcDR2w1EhH3u3a9 d76cjc0XyCCcvGsDmC9BNuwNDIcOjisjWQOHYFuFN2jnHVD9Xnot1wIHroj9US6BRHSn /yvUFeIs8yRbWksencGN90NThu6jpSHcSP+dArf+haYqD+TxQcumlzgXlzEAP3e+5Lrf 1pfPwzU1j5C5Z72cvOsODbchFvH21/UNjl7v6P+s7cVjuMHduXie3HxPBuySx2EMV7ru Pq0RSDJpZLQPhNhJjetPO4h+MC7cIXJzeZaaHSDPEjvaqoLVLhl/WtEH4yLr4nEooYFm PF4g==
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=T4z9pQFfL1mToQ46McSiTDE93hV3m5ak9cxDqeNTbH4=; b=GjNPPlbPtXYgN/mGg6dwJUMtNhOOQyVSIGzeF+GL/iKzElO2jwSEJpeQWELZhcYwWD p7Q2rRe3j0C626uoLGQXqDkCCjnS+XRp6oHZGbfioZjS3v0+8bLCnP6AG0h8C3BxbHCk F3rIECiA02O3dg9g0SidFyDj1Ww/WQnsUSBJ52784CaZONuDbwDzUfEBtU4GR20WACu0 q1sVv/nrCuZNJaWTSgulgkj8DCSrp6gzLEp6jextDuMnR3A+fYJI6lhxr0OldHzNzeyc 64cVJx8GEl8Le9QVbGqzRo1CGPY5VRj4S+rAeD2Stqqidrrp1MrnfTgKGRPh1uuIjh72 Wr3Q==
X-Gm-Message-State: AODbwcBmQtqOvTJ2sHDdqWXiFLDqApON54kzVQGcxS9FatkcWEiFfpnP zX6WJj4DbEz2lwAyD4zEGBV9WKrrrsyt
X-Received: by 10.31.33.3 with SMTP id h3mr3829615vkh.29.1496419713430; Fri, 02 Jun 2017 09:08:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.168.138 with HTTP; Fri, 2 Jun 2017 09:08:12 -0700 (PDT)
In-Reply-To: <20170602145655.msfjw35qhoev4sm2@Vurt.local>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <CAKD1Yr0DtQYvCYLQexhXe_nhb5rjeyhnB4bCveqyO5Xbuwdg1A@mail.gmail.com> <20170602145655.msfjw35qhoev4sm2@Vurt.local>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Sat, 03 Jun 2017 01:08:12 +0900
Message-ID: <CAKD1Yr3gqFgq3dxFaBEV++q5cgx1AHzFLGRJ50DYJjVE69C7iA@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: Job Snijders <job@ntt.net>
Cc: draft-bourbaki-6man-classless-ipv6@ietf.org, Peter Hessler <phessler@theapt.org>, IETF IPv6 Mailing List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c0087e749b510550fc5dd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/nfNtvxQl2Ni4uLIwtyRD4mNDAOw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Jun 2017 16:08:36 -0000

On Fri, Jun 2, 2017 at 11:56 PM, Job Snijders <job@ntt.net> wrote:

> >    - The document lists no compelling use cases of what you can do
> >    with less than 2^64 addresses per link than you can't do with a
> >    2^64 addresses per link.
>
> This is not true. The security section for instance shows: "In such
> cases, the use of smaller subnets forces an operational limit on such
> data structures, thus helping mitigate some pathological behaviors (such
> as Neighbor Cache Exhaustion attacks)."
>

I said "compelling". Those attacks have relatively simple operational
countermeasures. They were discovered several years ago, and we're coping
just fine.


>
> >    - The only technical motivation in this draft seems to be "classful
> >    addressing was a bad idea in IPv4". That's not a valid argument in
> IPv6
> >    because the address space is completely different. A /64 is *four
> billion
> >    times* bigger than the IPv4 internet. That's 10,000 times more than
> the
> >    difference between a grain of sand and the whole planet we live on.
> Such a
> >    huge scaling difference pretty much invalidates any argument that
> solutions
> >    that worked well in IPv4 will work well in IPv6.
>
> Would be a shame to throw away lessons learned from IPv4.
>

I think that's exactly the fallacy here. It is not useful to apply
something you learned about IPv4 addressing to IPv6, because the number of
addresses is incomparably bigger. Rule of thumb in software engineering is
that a solution usually scales by one or two orders of magnitude. Here we
have something like 34 orders of magnitude. Even a single /64 is 9 orders
of magnitude larger than the IPv4 Internet. It really doesn't make sense to
assign addresses the same way.


> Making IPv6 look more like IPv4 (for instance through broader adoption
> of DHCPv6 w/ routing options, and classlessness like in IPv4) will
> positively impact IPv6 deployment.
>

But the deployment we get will be dumbed down to the level of functionality
that we can support (and suffer from) in IPv4. It's not worth it.

Example: I don't want us to have to deal with NAT any more, ever. If you
think we can use DHCPv6 without ending up with NAT, then please read
RFC7934 in a loop until you understand why we can't. :-)