Re: [v6ops] Implementation Status of PREF64

Philip Homburg <pch-v6ops-10@u-1.phicoh.com> Tue, 12 October 2021 17:01 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 CA3283A0E5D for <v6ops@ietfa.amsl.com>; Tue, 12 Oct 2021 10:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 H3Y_Ik-Zvvsa for <v6ops@ietfa.amsl.com>; Tue, 12 Oct 2021 10:01:49 -0700 (PDT)
Received: from stereo.hq.phicoh.net (pch.xs4all.nl [83.160.102.151]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F85D3A0E26 for <v6ops@ietf.org>; Tue, 12 Oct 2021 10:01:48 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1maL9t-0000K9C; Tue, 12 Oct 2021 19:01:45 +0200
Message-Id: <m1maL9t-0000K9C@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-10@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CAKD1Yr34jv_N0jGKdg=sG76oGU7PdRjYFC_-w9Uvzs=7oGm38w@mail.gmail.com> <E6316781-AC7D-438F-B216-75B1DF9217DC@delong.com> <CAKD1Yr10OKMJ1y8bs5xpt6jS8ZWsqs66oFCXmp-QLySS5Yn4hg@mail.gmail.com> <5DF8D1AE-4B54-429F-962A-488F2AA1F895@delong.com> <CAPt1N1ma45GKqXcvjHUGCYFKVbEGp3OuT013pZhrnOkFFLMiQA@mail.gmail.com> <CAKD1Yr2Pe+=tNkA7Ou9KeMkgFhcdSb8WxgVn1w9MauusMEhRcw@mail.gmail.com> <CO1PR11MB4881076DFF8A145C8CD818B8D8B69@CO1PR11MB4881.namprd11.prod.outlook.com> <A188D974-3CEB-497F-93EA-B66C77D2CA90@delong.com> <YWW1ghmjueHmfCEb@Space.Net> <m1maKp6-0000I3C@stereo.hq.phicoh.net> <YWW8FPkRuxCBFp3o@Space.Net>
In-reply-to: Your message of "Tue, 12 Oct 2021 18:47:16 +0200 ." <YWW8FPkRuxCBFp3o@Space.Net>
Date: Tue, 12 Oct 2021 19:01:45 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/j8B6cDpihAhCgT577qQLj03KQHg>
Subject: Re: [v6ops] Implementation Status of PREF64
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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, 12 Oct 2021 17:01:53 -0000

>Because of hierarchy in routing.  Address space allocated is usually
>not "flat" as in "you can just use /64s one after another" but there is
>routing hierarchy built in - like, "this company has a /48, and needs
>to number a few buildings with it" (forming a "site" in whatever=20
>definition of "site").  Thousands of devices is not a problem with
>"part of a /48", but thousands of *subnets* can easily become one.

Somehow people managed to number universities with tens of thousands
of students out a single /16 IPv4.

Obviously, if you have an existing network, it is not going to be fun if
suddenly you would have to provide a /64 per device.

That said. Most wifi networks in the world are tiny, and do not benefit at
all from a /64 per device. It would be nice if devices could request
additional /64s for downstream networks. But we have homenet for that.

For big wifi networks, it might make sense to get rid of multicast and
run them as a collection of point-to-point links. In that case, lets make it
an optional feature that can be enabled by the operator.