Re: Extending a /64

Mark Smith <markzzzsmith@gmail.com> Fri, 20 November 2020 02:49 UTC

Return-Path: <markzzzsmith@gmail.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 A64293A16DF for <ipv6@ietfa.amsl.com>; Thu, 19 Nov 2020 18:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 14Nf-28nHVtL for <ipv6@ietfa.amsl.com>; Thu, 19 Nov 2020 18:49:40 -0800 (PST)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61ED93A1691 for <ipv6@ietf.org>; Thu, 19 Nov 2020 18:49:40 -0800 (PST)
Received: by mail-ot1-x32c.google.com with SMTP id j14so7469458ots.1 for <ipv6@ietf.org>; Thu, 19 Nov 2020 18:49:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lIAMapI5FHrArqasTvrWTJjKZRWGsAbgZZq1xHanbh4=; b=cMbzTKLt8oLPDFxCCrAhfZ7bKSbExedJf+RVcsjPIXN2Ds6i8YD9QCe0H6kxod4t4q 6DmqJcahrUf95ABWcx38vLBEB27VK/mIDjht3WKBGbV4H8X+uxnrTNjXhypDDuhabuoQ rSgoYXddE3gl6EjA7f7xc2bd+SCQbH6ABdKkolyuddqICTHP1PsoHnYQFD38nw9coY76 My+qfmNc03fZLVZxTxXkW4LhSu+e9ArsLHOpv2ak8TyIci+aiR+sJyffTUVADbcxt7Nq +CE2dHyJnK4TLZP+OQ3yOyAt6PJdHHihsiVljvsHow9mCZSKOuPBDteGNwULDcoCFLzy BfMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lIAMapI5FHrArqasTvrWTJjKZRWGsAbgZZq1xHanbh4=; b=I1cydt9ASdEytKiVA9ELZf9M8bBJy/WX1pancwD8azEDOZkeBKzkaNBcSKzYlQpxSA Re2pfEsWxn5uSnb2mI6y1wl5a3X/Z3Uc61Q0rfMJbPLjH1SFe8dWQUHcszj4L65Khbhr jzwDhza33iTtuNNI7/qJxDNSaBzhjArMbVg+QMtI5f3aZcECxf3QJfMnCgRFOKzqh0rZ JpOuSpcdRWfR0k/01CLO4Z1ISVVhqcaMx2LcD4nQuFA2FwhT6ibOglJOH7H86rGo9CSW 3ORGH2uXpbz5LxTRjcOTTCgTKnleUhM2ZeC+tKhNRMaCu/FTJMs+FJO+Xotc53xxQN62 vuAg==
X-Gm-Message-State: AOAM530q7zCl+H4LAFloWKR93rMcZdV/KAkzTSkRsJ1E3Qx5LkKRtZe4 iq32sM3OiUS+2iEjkW84kqzh/N2lIrrvVsFrfH35DpSS
X-Google-Smtp-Source: ABdhPJxP9rViUtR5rVg9/wy9mHl8laDX6gOjWCOBTfJVYPAoSIbVNUzB8tgAxO06fEMwEcQfgN95vrnOsQVwrMLz9k0=
X-Received: by 2002:a9d:a0d:: with SMTP id 13mr11539533otg.348.1605840579539; Thu, 19 Nov 2020 18:49:39 -0800 (PST)
MIME-Version: 1.0
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> <5f505585-1328-d942-2ec2-a2d96b7b4779@foobar.org> <CAO42Z2yk5pEKGFEYk3MDDDybVDZt6GiE1Pw932n4gLaqSxGH7A@mail.gmail.com> <23487.1605731956@localhost> <CAO42Z2yesLcdRw0HrNBsUAm-x=T9OneCjPMLmq8oZ4_ZH99Tsw@mail.gmail.com> <8f6bab4b-4171-66ba-cff4-742adc10ceea@foobar.org> <01cd5a82-be72-54b8-0171-3720f25cae0d@mccallumwhyman.com> <CAO42Z2xYAut_dfQtGrwkm7VWw9NPhsa5xaE9NqjCaK9L8RoMQA@mail.gmail.com> <7c500d2b-bc44-d00e-9cc2-96046c6ec5d6@foobar.org>
In-Reply-To: <7c500d2b-bc44-d00e-9cc2-96046c6ec5d6@foobar.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 20 Nov 2020 13:49:27 +1100
Message-ID: <CAO42Z2wgWeHDpShz3zn4WH4aRvNHoGjntENMpiy9JqTAJQe-gg@mail.gmail.com>
Subject: Re: Extending a /64
To: Nick Hilliard <nick@foobar.org>
Cc: Tony Whyman <tony.whyman@mccallumwhyman.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004f3b0005b480e57c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vMO5UPT1IyHtNrJjXCz_rEwzFq0>
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: Fri, 20 Nov 2020 02:49:42 -0000

On Fri, 20 Nov 2020, 09:27 Nick Hilliard, <nick@foobar.org> wrote:

> Mark Smith wrote on 19/11/2020 19:56:
> > What makes you think that once you have a high order prefix, you have
> > the freedom to arbitrarily define the format and semantics of any of the
> > low order bits?
>
> the cart needs to go before the horse.
>
> If Tony is saying that ipv6 assignments to aircraft could - even
> possibly - be used to directly connect to other third party networks,
> then ULA is inappropriate and we can park that discussion.


ULAs are specifically designed to allow interconnecting to other ULA
networks without resorting to renumbering or IPv6 NAT.

That is why the Global ID is required to pseudo-random, so that when two
ULA networks are interconnected, there is no overlapping or duplicate
address space. Subnet prefixes and therefore the hosts attached to them
already have globally unique addresses, even though they don't have global
reachability or access.

This was one of the problems with site-locals. Merging two site-local
address spaces would have involved renumbering or NAT.




This leaves
> GUA or something else from other IANA-reserved address space.
>
> Thing is, if an organisation feels that their needs for ip address
> allocation are sufficiently different from everyone else's in the world
> that they need to bypass the RIRs and apply for a direct IANA
> reservation - whether that be in GUA space or not - then the
> organisation needs to make a case which justifies this ask.
>
> Obviously there's no problem discussing ideas on 6man to get the lay of
> the land, but bypassing the RIRs for addressing requirements seems to be
> an extraordinary ask, and an extraordinary request will need
> extraordinary justification.
>
> Nick
>