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

Erik Kline <ek@google.com> Wed, 14 June 2017 13:23 UTC

Return-Path: <ek@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 704B312E91F for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 06:23:10 -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 gPLMJNfyE3IC for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 06:23:08 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 270581294FF for <ipv6@ietf.org>; Wed, 14 Jun 2017 06:23:08 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id 63so215538ywr.0 for <ipv6@ietf.org>; Wed, 14 Jun 2017 06:23:08 -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=NUoCLdtkOagLW9MDW8odmV2wC/RBFh1JlW6jilBZmoQ=; b=o5ObYTFflWy8qVjrVRJYnpFqONnwT5i5hOoQ75ffDrufoGIajKDmvZiOUFhuyMXbIw 6jvRmwucaMcfSvnFqiKwtidj12iu4gkPgN4K+tZ0oQJCRWIEwBQPZfwAneDRodKy+npe ZuGGRzzrdlHJW5fWFaAf9rOg5tgXNyRm6+DTwc+y8jPpnxD+Mb0hu2BO4qL8e4o9ehgn ygp09aKgR+XGN+wE3KOCIRhwwR0DecXeI8d//KkHH7foeFtmI8gB+iXM5BZWNkoD1OiX 1WV8KHqovZug72kDmVVg4vwwX6kuJoWDZoio14Tld9IIy3fzTaeqqhaQuebcnA8uIIv9 qPtw==
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=NUoCLdtkOagLW9MDW8odmV2wC/RBFh1JlW6jilBZmoQ=; b=t+S2j4BQc9trO7emUb3iV0FXUgzca0HVoSOMbnVNPM63CX0r17SaCjBjhFR4LDhgDR mL/wyWJfyGS9hg96n5BF2H5Vnp1aa9BRRmaFnUoZIJa4RmEL9EC9s6RLDqMOUFfWgcUz VpEn0Pql3Lk3NUWhpExeOzUga9Z5YWWQzhZiL7rSROhhXKQOBATFX6jXGRITXpsaQ0Fe uKbqMY28txZgn9EAgbGFUBBSoB/w2q2oSx5AMwO6rMiXQBmZ0YSXRsJJF15UZnu6Wuue c0cIDjyW3nRjKFog3sgYmC8TwaoLAqlMVmqUNpAPRNzmNRbEfZKVsw0B98pnte3zhOgS mD1g==
X-Gm-Message-State: AKS2vOye3dfcItRkCxFtY9XlvSFK+f0PHqib9aU0l7b9a80KJwEMSuHV Q7cR/8u5S+8u1WeWdYkJf7p6kjHiGPG6
X-Received: by 10.129.138.194 with SMTP id a185mr17915ywg.207.1497446587151; Wed, 14 Jun 2017 06:23:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.50.141 with HTTP; Wed, 14 Jun 2017 06:22:46 -0700 (PDT)
In-Reply-To: <20170614130649.E97607BB0491@rock.dv.isc.org>
References: <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <FA3032F9-F44B-45B4-9AFF-01EBC84F1448@employees.org> <b1c5c13d-ef69-ef30-546c-9178a2655caf@si6networks.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <E61AFFF1-0354-41EE-8E11-50433B26BAF7@employees.org> <20170614094034.GC30896@gir.theapt.org> <A7502902-245B-499B-916B-28630CD5A824@employees.org> <20170614095910.GE30896@gir.theapt.org> <20170614130649.E97607BB0491@rock.dv.isc.org>
From: Erik Kline <ek@google.com>
Date: Wed, 14 Jun 2017 22:22:46 +0900
Message-ID: <CAAedzxrb2ii48KhOgqDbtMBDmsmenXn7iGnnCCcn20d_gX7ykA@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: Mark Andrews <marka@isc.org>
Cc: Peter Hessler <phessler@theapt.org>, IETF IPv6 Mailing List <ipv6@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="94eb2c07f7d8ecb1de0551eb7329"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VAbbE-lu6hnuuyyHfpcwLt3iBMQ>
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: Wed, 14 Jun 2017 13:23:10 -0000

On 14 June 2017 at 22:06, Mark Andrews <marka@isc.org> wrote:

>
> In message <20170614095910.GE30896@gir.theapt.org>, Peter Hessler writes:
> > On 2017 Jun 14 (Wed) at 11:52:27 +0200 (+0200), otroan@employees.org
> wrote:
> > :Peter,
> > :
> > :> leaving a RECOMMENDED for /64 subnets is fine.  forcing it to be a
> MUST
> > :> is not fine to me.  While the arguments in favour of /64 subnets are
> > :> valid, there are many differently valid reasons to have non-/64
> subnets,
> > :> as mentioned many times in this (and other recent) threads.
> > :
> > :Which arguments matter to you?
> > :What _problem_ does changing the 64 bit boundary solve for _you_?
> > :
> > :Ole
> >
> > The problem is wasting space (I acknowledge your arguments, and reject
> > them), uglyness of the addresses, and the fact that _my_ network is not
> > _your_ network.
> >
> > I'm already running non-/64 subnets on my personal networks.  I'm also
> > running non-/64 subnets on my $work networks.
> >
> > mandating /64 subnets in the _architectural specification_ is a bug,
> > period.
> >
> > IPv4 got rid of classful subnets in 1993, IPv6 can join the last century
> > as well.
>
> We got rid of classful subnets in 1993 *because* there were not
> enough subnets to go around with them.  We didn't get rid of them
> because as a concept they were bad.
>
> Do you say that 18446744073709551616 subnets is too few to go
> around?
>
> 2^64 address would have been enough to support the world using
> variable length subnets.  IPng evaluated this and decided that it
> was not a good idea as variable length subnets really are too
> complicated.  Instead IPng went initially with 128 bit addresses
> and, initially, /80 subnets so that we didn't have to deal with
> variable sized subnets.  This was later changed to /64 bit subnets
> to handle 64 bit mac addresses.
>

Thank you.