Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt - 2^64 addresses for a single Host is way too much

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 20 December 2022 14:43 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D34EC14F606 for <v6ops@ietfa.amsl.com>; Tue, 20 Dec 2022 06:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.33
X-Spam-Level:
X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvcJjsSmMEj8 for <v6ops@ietfa.amsl.com>; Tue, 20 Dec 2022 06:43:08 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB44FC14F5E1 for <v6ops@ietf.org>; Tue, 20 Dec 2022 06:43:07 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 2BKEh541059876 for <v6ops@ietf.org>; Tue, 20 Dec 2022 15:43:05 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 429F4203105 for <v6ops@ietf.org>; Tue, 20 Dec 2022 15:43:05 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 38A12205392 for <v6ops@ietf.org>; Tue, 20 Dec 2022 15:43:05 +0100 (CET)
Received: from [10.11.240.247] ([10.11.240.247]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 2BKEh57J003527 for <v6ops@ietf.org>; Tue, 20 Dec 2022 15:43:05 +0100
Message-ID: <0d884180-9651-b3fe-b3b8-1246618db591@gmail.com>
Date: Tue, 20 Dec 2022 15:43:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0
Content-Language: fr
To: v6ops@ietf.org
References: <167107554671.48477.568330207202509840@ietfa.amsl.com> <CAFU7BATp=gEB3S8AzhCYDMN3fzLQrYY9pzcWJ=LQnrjC9bRKEA@mail.gmail.com> <Y5sy2ikgQEWSnCsM@Space.Net> <CAKD1Yr0EchmQ11eKCB4AfEJaG7_aFDDv_bavYJY4Zb3iDmhALg@mail.gmail.com> <4277d4e5a962400f8438e8f01c884654@huawei.com> <CAO42Z2y_SWybfLQE3g5a-kVieY05XSxaKTv-UG8kvfbYzJLH6w@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <CAO42Z2y_SWybfLQE3g5a-kVieY05XSxaKTv-UG8kvfbYzJLH6w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/pkDcOIStDLKI_qNODOzIrcsp4c4>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt - 2^64 addresses for a single Host is way too much
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2022 14:43:12 -0000


Le 20/12/2022 à 11:07, Mark Smith a écrit :
> 
> 
> On Tue, 20 Dec 2022, 18:14 Vasilenko Eduard, 
> <vasilenko.eduard=40huawei.com@dmarc.ietf.org 
> <mailto:40huawei.com@dmarc.ietf.org>> wrote:
> 
>       * A /64 provides "infinite" addresses.____
> 
>     /96 is infinite too (for the host)____
> 
>       * In practice, /64 is the only prefix length that supports SLAAC.____
> 
>     Not a problem. The SLAAC may be on the different /64____
> 
>       * SLAAC is the only address assignment mechanism required to be
>         supported by all hosts.____
> 
>     No problem. Hosts may support SLAAC and “/96 prefix per host” for a
>     long time, even at the same time on the same link.____
> 
>     I do not see a reason why the new address acquisition mechanism
>     should stick to the /64 prefix boundary.
> 
> 
> Why not?
> 
> Why do you think a /96 is a good prefix length?
> 
> Have you considered the privacy address implications of only having 32 
> bits to work with instead of 64?
> 
> What about address discovery via unsolicited address probing? Sending 4 
> billion packets is much, much easier than sending 4 billion times 4 
> billion packets to try to discover live addresses within a /64.
> 
> Are you worried about IPv6 address space running out?
> 
> The early designs of IPv6 only had 64 bit addresses. RFC1710:
> 
> "SIPP supports addresses which are twice the number of bits as IPv4
>     addresses.  These addresses support an address space which is four
>     billion (2^^32) times the size of IPv4 addresses (2^^32).  Another
>     way to say this is that SIPP supports four billion internets each the
>     size of the maximum IPv4 internet.  That is enough to allow each
>     person on the planet to have their own internet.  Even with several
>     layers of hierarchy (with assignment utilization similar to IPv4)
>     this would allow for each person on the planet to have their own
>     internet each holding several thousand hosts."
> 
> IPv6 today with 128 bit addresses is equivalent to the first designs of 
> IPv6 with 64 bit addresses, except that a host can have 2^64 bits for 
> itself, instead of only a single address.

2^64 addresses for a host is way too much.

An IP address - even in the IPv6 world - is for a computer Host, and not 
for a... single transistor in all massively parallel supercomputer Hosts 
of the Top500.

One would strangely need an entire computer inside that single 
transistor in order to run an IP stack...

One would need the Moore law to continue way beyond what we have ever 
seen in transistor size, and the current TSMC multi-billion investments 
be peanuts compared to what we will do in the future...

Rather - we should be using IP routing, because it might scale better.

Alex

> 
> Regards,
> Mark.
> 
> 
>     ____
> 
>     Ed/____
> 
>     __ __
> 
>     *From:*v6ops [mailto:v6ops-bounces@ietf.org
>     <mailto:v6ops-bounces@ietf.org>] *On Behalf Of *Lorenzo Colitti
>     *Sent:* Tuesday, December 20, 2022 10:00 AM
>     *To:* Gert Doering <gert@space.net <mailto:gert@space.net>>
>     *Cc:* V6 Ops List <v6ops@ietf.org <mailto:v6ops@ietf.org>>;
>     xiaom@google.com <mailto:xiaom@google.com>;
>     draft-collink-v6ops-ent64pd@ietf.org
>     <mailto:draft-collink-v6ops-ent64pd@ietf.org>
>     *Subject:* Re: [v6ops] Fwd: New Version Notification for
>     draft-collink-v6ops-ent64pd-01.txt____
> 
>     __ __
> 
>     On Thu, Dec 15, 2022 at 11:44 PM Gert Doering <gert@space.net
>     <mailto:gert@space.net>> wrote:____
> 
>         Something like a /96 per host - so "limitless amounts of host would
>         fit into a single /64" would avoid that, and still fulfill the
>         stated necessity of having many many many addresses per hosts.____
> 
>     __ __
> 
>     The reason the draft mentions /64 is:____
> 
>       * A /64 provides "infinite" addresses.____
>       * In practice, /64 is the only prefix length that supports SLAAC.____
>       * SLAAC is the only address assignment mechanism required to be
>         supported by all hosts.____
> 
>     That means that a node that gets a /64 is guaranteed to be able to
>     extend the network indefinitely to all IPv6 nodes while maintaining
>     end-to-end connectivity to all of them. That's a major improvement
>     over IPv4's current capabilities. It's true that a /64 is relatively
>     expensive in terms of address space. That said, this proposal is
>     targeted towards larger networks. Fortunately, smaller networks tend
>     to be less tightly managed, and for many of those networks, directly
>     using SLAAC is fine.____
> 
>     __ __
> 
>     That said - based on past experience I fear that there is no single
>     number that will get consensus in this group. For example, I
>     definitely wouldn't want to *recommend* /96, because /96 would lose
>     the above advantages. So, how about we just state the facts?
>     Something like:____
> 
>     __ __
> 
>     =====____
> 
>     Delegating a /64 prefix to the client allows the client to provide
>     limitless addresses to IPv6 nodes connected to it (e.g., virtual
>     machines, tethered devices), because all IPv6 nodes are required to
>     support SLAAC.____
> 
>     =====____
> 
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org <mailto:v6ops@ietf.org>
>     https://www.ietf.org/mailman/listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops