Re: Extending a /64 (ATN/IPS worked example)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 18 November 2020 03:51 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 679853A1396 for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 19:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XVe2szj0f4H3 for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 19:51:44 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3672A3A1390 for <ipv6@ietf.org>; Tue, 17 Nov 2020 19:51:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6FCBD389BF; Tue, 17 Nov 2020 22:52:37 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tSHGWsEntnp0; Tue, 17 Nov 2020 22:52:36 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6BAED389BE; Tue, 17 Nov 2020 22:52:36 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2A9516A7; Tue, 17 Nov 2020 22:51:42 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, ipv6@ietf.org
Subject: Re: Extending a /64 (ATN/IPS worked example)
In-Reply-To: <38503680-a3f6-4375-e1da-2b7be7253ca4@gmail.com>
References: <202011151920.0AFJKN9U003337@mail2.mwassocs.co.uk> <3d26bffe-b6c9-4ed7-6135-a515f9902fd7@gmail.com> <m1keOTi-0000EGC@stereo.hq.phicoh.net> <CAO42Z2wZkXryhw1u5WAFdtCvXHyyz1zeM22FP_gRxjurjsG-Jw@mail.gmail.com> <CAN-Dau2XTRJpR9S=ZXOXOD6PkxLTD7KAzN-CwoGhMUmSQTp0Zg@mail.gmail.com> <91d4b7d4-5477-50c0-fb34-5e7bbfdfb253@gmail.com> <ad5ee6e1-c402-f9d4-80a2-f9f0fd5c3da5@mccallumwhyman.com> <m1kezKE-0000FAC@stereo.hq.phicoh.net> <b52e6eb4-142e-2442-2c6a-9997df91b2f6@mccallumwhyman.com> <m1kf3Jt-0000LAC@stereo.hq.phicoh.net> <38503680-a3f6-4375-e1da-2b7be7253ca4@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 17 Nov 2020 22:51:42 -0500
Message-ID: <19619.1605671502@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QrZ0epAaco0XwdLNZd0f_QJt-Hw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Nov 2020 03:51:46 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > To be clear, the IPv6 *fixed length* address model changes the parameters
    > of allocation practice because of moving from (say) 24 to (say) 64 bits
    > of routeable prefix, but in no way changes the philosophy of allocation
    > practice. IPv6 has ~64 topology bits instead of ~24; the actual numbers
    > in the H-ratio calculation change; the potential lifetime of the address
    > space expands enormously; the economic value of address space collapse
    > enormously. But all of that breaks if you start assigning address bits
    > non-topologically. That's why IPv6 and IPv4 share CIDR as the basis
    > for both prefix allocation and wide-area routing.

ISPs that try to allocate their IPv6 residential customers based upon strict
geographical/network topology find two things:
  1) they have the wrong amount of space in the wrong place at the wrong time.
  2) they force users to renumber needlessly when they have to split
     customers in a neighbour among two routers/CMTS/BMS.

So I claim that in the 16 bits between /32 to /48 within an ISP, that there
is little in the way of network topology.  Yes, some structure, with some
layers of abstraction... when possible... but OSPFv3 deals.

I've heard that in the future that Smart ISPs will use some kind of
address allocation/management autonomic service agent over a secure autonomic
control plane.

So, instead of thinking of this as a non-topological address plan, think of
this as the internals of a really large confederated airline ISPs.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide