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

Tony Whyman <tony.whyman@mccallumwhyman.com> Tue, 17 November 2020 15:02 UTC

Return-Path: <tony.whyman@mccallumwhyman.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 8A3E63A13A4 for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 07:02:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 0HVQfxRH2MFH for <ipv6@ietfa.amsl.com>; Tue, 17 Nov 2020 07:02:50 -0800 (PST)
Received: from mail2.mwassocs.co.uk (mail2.mwassocs.co.uk [IPv6:2a00:da00:1800:8030::1]) (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 BCBF73A13A3 for <ipv6@ietf.org>; Tue, 17 Nov 2020 07:02:50 -0800 (PST)
Received: from [IPv6:2a02:390:813f:1:69d0:fcb0:c90e:f108] ([IPv6:2a02:390:813f:1:69d0:fcb0:c90e:f108]) (authenticated bits=0) by mail2.mwassocs.co.uk (8.15.2/8.15.2/Debian-3) with ESMTPSA id 0AHF2jrZ017806 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Nov 2020 15:02:47 GMT
Subject: Re: Extending a /64 (ATN/IPS worked example)
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, ipv6@ietf.org
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>
From: Tony Whyman <tony.whyman@mccallumwhyman.com>
Message-ID: <b52e6eb4-142e-2442-2c6a-9997df91b2f6@mccallumwhyman.com>
Date: Tue, 17 Nov 2020 15:02:40 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <m1kezKE-0000FAC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eDjnxLl-ulhfKEVIZoe5PUXCWvA>
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:02:53 -0000

On 17/11/2020 11:39, Philip Homburg wrote:
>> Each aircraft operator could individually register (e.g.) a /32
>> with an RIR for their Home Network Prefix. However, there are more
>> than 5,000 airlines and if you want to have firewall rules that
>> refer to "all uplink packets", an un-coordinated registration of
>> Home Network Prefixes would lead to a big configuration maintenance
>> problem for every firewall in the ATN/IPS. The
>>
>> I believe that American Airlines currently has the largest fleet
>> with about 1,300 aircraft. You would need a minimum of 11 bits for
>> this fleet - rounded up to 12 for a nibble boundary.
> 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.

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.

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.