Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)

Mark Andrews <marka@isc.org> Fri, 08 January 2021 03:02 UTC

Return-Path: <marka@isc.org>
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 6F4A63A0127; Thu, 7 Jan 2021 19:02:49 -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 Q4Yf8dEE5_se; Thu, 7 Jan 2021 19:02:48 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 C9B173A011D; Thu, 7 Jan 2021 19:02:47 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 703543BD447; Fri, 8 Jan 2021 03:02:47 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2AA3716005A; Fri, 8 Jan 2021 03:02:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 10FD7160056; Fri, 8 Jan 2021 03:02:10 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8yG40Pm4Frfd; Fri, 8 Jan 2021 03:02:09 +0000 (UTC)
Received: from [172.30.42.68] (n114-75-149-106.bla4.nsw.optusnet.com.au [114.75.149.106]) by zmx1.isc.org (Postfix) with ESMTPSA id 12C85160051; Fri, 8 Jan 2021 03:02:08 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <537EBE5A-6554-4904-8701-03940C914FE3@fugue.com>
Date: Fri, 08 Jan 2021 14:02:06 +1100
Cc: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>, IPv6 Operations <v6ops@ietf.org>, IPv6 List <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A9F034B-64AB-4A96-BB8C-7A9286EF2654@isc.org>
References: <E3625337-3A59-4F0A-9EEE-EC8F6B39C965@isc.org> <537EBE5A-6554-4904-8701-03940C914FE3@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/HoZCvlmQMDQsiUQU0Rw9TH50nlY>
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
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: Fri, 08 Jan 2021 03:02:50 -0000


> On 8 Jan 2021, at 13:54, Ted Lemon <mellon@fugue.com> wrote:
> 
> Right. That’s how you do it. And then what happens with the topology changes?  The random ids are no longer referring to the same links. Solving this problem adequately is way more work than it’s worth. The thrashing in the database would be brutal. 

You publish updated records.  If you are changing topology the addresses of the nodes are almost certainly changing anyway. Publishing new L-L SA records along with new ULA and GUA is minimal extra expense.

>> On Jan 7, 2021, at 21:48, Mark Andrews <marka@isc.org> wrote:
>> 
>> 
>> 
>>> On 8 Jan 2021, at 13:04, Ted Lemon <mellon@fugue.com> wrote:
>>> 
>>>> On Jan 7, 2021, at 9:02 PM, Mark Andrews <marka@isc.org> wrote:
>>>> The example names I used where using the individuals suffix (id.au) but the idea is to leverage the existing global DNS to provide uniqueness. 
>>> 
>>> That works pretty well for ULAs, but not for LLAs. For LLAs you need to identify the link, and that’s just not a simple thing to do, as I explained earlier.
>> 
>> Actually you haven’t explained.  You have stated.  You said it was hard.  Hard is not intractable.
>> 
>> If you are willing for a link to have multiple names just have reach router generate its own random 160 bit base32 encoded label for each interface, append the well know suffix and advertise it.  You will get multiple SA records for the same interface if there are multiple routers but that should not be a issue.  With 160 random bits the need to do collision detection is really non-existent.  We’ve resolved this for NSEC3 and DNS changes 15 years ago.  This will scale into millions of router interfaces.
>> 
>> If you want to have a single link name then we need to define a protocol for the routers on the link to select one of the names.  This may end up being technology linked.  Router with smallest L-L address wins would be one solution to this.
>> 
>> Yes, I really do expect every machine to update its own addresses in the DNS.  We do know how to do that securely with SIG(0).
>> 
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org