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

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Tue, 17 November 2020 15:55 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 B07233A11CB for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 07:55:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 gLwATz4fvBry for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 07:55:25 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D743A1487 for <ipv6@ietf.org>; Tue, 17 Nov 2020 07:55:03 -0800 (PST)
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 #157) id m1kf3Jt-0000LAC; Tue, 17 Nov 2020 16:55:01 +0100
Message-Id: <m1kf3Jt-0000LAC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: Extending a /64 (ATN/IPS worked example)
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.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>
In-reply-to: Your message of "Tue, 17 Nov 2020 15:02:40 +0000 ." <b52e6eb4-142e-2442-2c6a-9997df91b2f6@mccallumwhyman.com>
Date: Tue, 17 Nov 2020 16:55:01 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/01b5mcYL4RlgCUYW4rYb55lbnBY>
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: Tue, 17 Nov 2020 15:55:27 -0000

In your letter dated Tue, 17 Nov 2020 15:02:40 +0000 you wrote:
>> This a clear example of a bad addressing plan. If you have 5000 airlines and
>> the biggest has 1300 aircraft then you don't give all tiny airlines the
>> same amount of space you need for the biggest.
>>
>It's only a "bad addressing plan" if your sole success criteria is dense 
>allocation. IPv6 should have liberated us from such a narrow success 
>criteria. The success criteria that I am invoking include cost of 
>administration and legacy support.

'should have' is an interesting concept. We can't really go back in time.

Technically we can just do a complete overhaul of the IPv6 addressing 
architecture. But I doubt that people who now have existing IPv6 networks and
products would be interested in that. Changing a widely adopted
architecture also has a huge cost.

>I also do not see the point in having a different (shorter) prefix 
>length for aircraft in smaller airlines compared with those in larger 
>airlines.

Well, ISPs with few customers have a longer prefix than those with many
customers. I guess you propose that we should have taken the shortest
prefix needed for the largest ISP in the world, and then give the same
prefix to every last tiny ISP as well?

>If you are arguing for dense allocation as a general rule then this 
>should apply to the whole /64 prefix. I assume that you are demanding 
>that ISPs allocate a /64 to all their users unless they can make the 
>case for multiple subnets and, even then, are parsimonious in their 
>attitude and push back hard against any user that wants more than a /60, 
>demanding proof that they have more than 256 subnets.

You can make that argument, but is not part of the design of IPv6. The
design of IPv6 is the endusers should always have enough space to number
their networks.