IETF Logo Mail Archive

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

Lorenzo Colitti <lorenzo@google.com> Sun, 04 June 2017 01:29 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 6938C12871F for <ipv6@ietfa.amsl.com>; Sat, 3 Jun 2017 18:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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, 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 Q9eRLo9TzyJ3 for <ipv6@ietfa.amsl.com>; Sat, 3 Jun 2017 18:28:59 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 5E38912941C for <ipv6@ietf.org>; Sat, 3 Jun 2017 18:28:59 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id p62so19047045vkp.0 for <ipv6@ietf.org>; Sat, 03 Jun 2017 18:28:59 -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=y1LYiXxU0pyPnObkrTJmTXyEvuUFy0izEAVBZB1Ia98=; b=CDkqJi7IDGF+MXLW61O27DWaIRFR1NsrBj663S6LtGF3s9mTlASC2jcJy7NuMlNbM2 dT8G6riHkE5us73QMoeAjHJiYg8s4CJJ+72QbQSF+Bm+Uy62uVbYaUfgwnQCijqe2AD+ 2adghUmRnDKrn3FNU4QOLwqyMw9BhjGsRtiljYSfp3+H/WlGIrvB1qcFt5fP66OKur4u tGxx/MTsq4jUi9p9MucM7jyxuZ0qdNIndaUEZLOIsj/k/3uQX6AbC4xsnP7kVc0vaf0d ptYa6APVi1/4F01ld+Q5WaBUlrCsMc3lnBQwfIo0tIrCDwlKUflXSN2BPZhFmYmHMQeI oq7Q==
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=y1LYiXxU0pyPnObkrTJmTXyEvuUFy0izEAVBZB1Ia98=; b=BZad+cZQI9Gzb2tYxvXXJ95K+KHcllnZuTFnI9E533rjrhPm8VPild2xdHUbiOda71 aD9rkj1TD/4Resc+XOFwGzF4W+A9aDmxmKb7R1z94eLD966MA9IGa05vtGkK45Kzz9D7 mqvuozgfmcCBXEEXL9064sHNab9H79Cy7mNNUgNtjIhQkPWQCFUeAMwUXeECMA3SA8Pf Nc22rH6VZrD8g59iM58x1lWuWumZwUId+EMn6o8nfH6izNhEc4aoylKQYpkrr5yKBIvB Nh7eUkz2zX7GHaVgLbp5/ZDhzvkdst1BGBJvG7IC8SGKf3uJCcnWzb6nZTVuYnp2DPfb c41g==
X-Gm-Message-State: AODbwcCLSuVAXD+mPPJH6NLqQdCBs8RJ1LFa9CGtsKVHhz4/TBNB7x+t AXIuNiOlmaA+5wDlbvToQVg96ztH/lUz
X-Received: by 10.31.170.2 with SMTP id t2mr7061509vke.100.1496539738183; Sat, 03 Jun 2017 18:28:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.168.138 with HTTP; Sat, 3 Jun 2017 18:28:37 -0700 (PDT)
In-Reply-To: <CALx6S36SfkvmPpeOfrXLYUhjRusjOiimh8u1c-gtQ=wat2=u5g@mail.gmail.com>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <CAKD1Yr0DtQYvCYLQexhXe_nhb5rjeyhnB4bCveqyO5Xbuwdg1A@mail.gmail.com> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <CAKD1Yr3gqFgq3dxFaBEV++q5cgx1AHzFLGRJ50DYJjVE69C7iA@mail.gmail.com> <f2260ee557014429a1fef32de040547b@XCH15-06-11.nw.nos.boeing.com> <d62ce5e3ea0f486eb4c9d54609a86b24@XCH15-06-08.nw.nos.boeing.com> <04bdfdfe018145e6aedbaa62ed6cbfb0@XCH15-06-11.nw.nos.boeing.com> <78fe298cb5484d50a56cf6ed4ddafb54@XCH15-06-08.nw.nos.boeing.com> <6bba4c2b58964787860f2c7acf130959@XCH15-06-11.nw.nos.boeing.com> <d3558856-6faf-1d50-870a-c9db1e91e34c@innovationslab.net> <20170603003552.7A0327ADD848@rock.dv.isc.org> <67a85067-2150-62cf-0eab-bca3d7827a4c@si6networks.com> <CAKD1Yr1VMES3cdm6pWrgvoX5YxhwfEwQa+f=RSnsRsY95eC4kw@mail.gmail.com> <CAKD1Yr3cXwM+2TBnuq9rnVHKgR6QY9naXVqzxQV4Hw9uB8926g@mail.gmail.com> <CAKD1Yr3oSQfM+gPJzfpK3sagb456dWvC6ab7t4D=FnFuahHqLg@mail.gmail.com> <CAKD1Yr0tGNvAZX1+UsSNdiuXQjtZo_iTmskzN1BCZKT9_UYm1A@mail.gmail.com> <CAKD1Yr1ub3XRTJf_d+rzUYDkvb=-R75JdZBRgUVTZxfCmH5XCQ@mail.gmail.com> <CALx6S35Ye67CHmqDF0AW5SX_-P6p16A1i6pFp5nOUwRB-r_GPA@mail.gmail.com> <CAKD1Yr2T4Xu3_CCrCPoHSDC6L+U0HB9vNvXA0n2UPDxjiu0Vgg@mail.gmail.com> <CALx6S36SfkvmPpeOfrXLYUhjRusjOiimh8u1c-gtQ=wat2=u5g@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Sun, 04 Jun 2017 10:28:37 +0900
Message-ID: <CAKD1Yr3yzGqH5LfbB09iO81Fjbym1=gb=hijskdUSiTZWKX18w@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: Tom Herbert <tom@herbertland.com>
Cc: Mark Andrews <marka@isc.org>, IETF IPv6 Mailing List <ipv6@ietf.org>, Brian Haberman <brian@innovationslab.net>, Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="001a11430a727d22fe0551184fcc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gWrhIeHfohuOJYRZi9BT93W5Ygo>
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: Sun, 04 Jun 2017 01:29:00 -0000

On Sun, Jun 4, 2017 at 12:49 AM, Tom Herbert <tom@herbertland.com> wrote:

> RFC7934 presents the arguments why hosts need multiple addresses, not
> why hosts need 2^64 addresses. For RFC7421 the arguments seem to be
> around operational simplicity. These don't answer my specific
> question: Why does a low end device, like a phone, _need_ the
> equivalent of four billion IPv4 address spaces assigned to it?


Read the document again? The goal is not /64. The goal is that no general
purpose host should ever be constrained in the number of IPv6 addresses
that it gets. That means it should be able to form new addresses without
asking the network, or it should get enough from the network that it never
needs to asks again. Currently the only ways to do that are SLAAC, which
operates on 64-bit prefix lengths, or DHCPv6 PD of a /64 or shorter, which
allows other devices behind the host to run SLAAC.

v2.23.0 | Report a Bug | By Email