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

Ted Lemon <mellon@fugue.com> Fri, 08 January 2021 01:43 UTC

Return-Path: <mellon@fugue.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 29AAE3A100A for <ipv6@ietfa.amsl.com>; Thu, 7 Jan 2021 17:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 sNLC-dK3rJoo for <ipv6@ietfa.amsl.com>; Thu, 7 Jan 2021 17:43:29 -0800 (PST)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 DF4543A1003 for <ipv6@ietf.org>; Thu, 7 Jan 2021 17:43:28 -0800 (PST)
Received: by mail-il1-x12a.google.com with SMTP id v3so8768446ilo.5 for <ipv6@ietf.org>; Thu, 07 Jan 2021 17:43:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=8J5gFQ2761GivqJ2GMSAh8u54jZpfCOfPDNj0hNvxgs=; b=WsJnKYY0DrYgSvmaE+MGr20HwxywcxRHtOw/V7Xw69IsUgYvYp8AXAVfLE2KLNVhs0 no8R0ezHOy1CQvjzxySp3SkY9T4c+Zv3z9zsuQeT9mISj3QxDOWvZgpKefwUa2UaS3DY ifKxMY06QxxIUQwgv5tBQ5q4kAYuE+hwl8dPYWlf5P/1dyh1tmLtU3bwf9FNITiNGA8L ka7zQ5RlDrwFgmco366x59imGtr3PRENSzt+VqRa0951AChIELbsgPz/UOE+sF/lZTio /MGeg5TQlpONUOryTeFHbDc3ASY1SL7GM8kUu56ZI7Nr+sk8tzPt/J1ZXlOGDLsdsIkm qVLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=8J5gFQ2761GivqJ2GMSAh8u54jZpfCOfPDNj0hNvxgs=; b=rQzijXMqyRt65R4o23peHclSyjwwOzj4xdGibqoJptZUtbln+EIHZb9zLSsiR86USj 20W4FDWtsIDXvDA4QKVbSdhKkCgEN3NeG2vCb8k0Hx6JvOYTwhn9aiMUWYhRSq5MSUE2 d/tiGeVGO22CmsGziwpWRBetXbiXBY7Hgdhk2fjKfsq062g4jruiufjDO5Ew3Gd2lLR7 m1M8xM8aThLAGY/7HX+ioaW845BAsTadveNOkuaZDNACE7KZEJS7mF0O9O4CbBOo+kib 7tSzchKlve7LT6KL/zBXncrvEojbDHI2dpz+fM/Qo0+dPDLSxkLbT5l8KwY3mRXANlEN NK4w==
X-Gm-Message-State: AOAM533TuYvGzjNWko11duf3wfXuhCHKqaqrIzvI2XCrWvtoMyPvZ6/W E455+ZHHs+QRihdyr8tdF82abg==
X-Google-Smtp-Source: ABdhPJzPWzyTJgRE06yUBRz34bDK2tuahTAywlkfExpzpIxdEpp7oQqYlIaA4oncSpqjXV4b2qoZGA==
X-Received: by 2002:a92:9a42:: with SMTP id t63mr1713230ili.176.1610070208041; Thu, 07 Jan 2021 17:43:28 -0800 (PST)
Received: from [192.168.4.114] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id v3sm5655977ilj.28.2021.01.07.17.43.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 17:43:27 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
Date: Thu, 7 Jan 2021 20:43:25 -0500
Message-Id: <AD20A505-14C4-4E8D-B28C-F237ECE55227@fugue.com>
References: <78D0D84C-53DB-4661-BA43-CFEB1F377BB4@isc.org>
Cc: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>, IPv6 Operations <v6ops@ietf.org>, IPv6 List <ipv6@ietf.org>
In-Reply-To: <78D0D84C-53DB-4661-BA43-CFEB1F377BB4@isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (18E118)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hyOldx0r72iV6DSTq0sjqn-sRCg>
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, 08 Jan 2021 01:43:31 -0000

Who determines what names to use?  What is the scope of the names? How is uniqueness guaranteed in that scope?

> On Jan 7, 2021, at 20:18, Mark Andrews <marka@isc.org> wrote:
> 
> 
> 
>> On 8 Jan 2021, at 02:08, Ted Lemon <mellon@fugue.com> wrote:
>> 
>>> On Jan 7, 2021, at 9:55 AM, Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com> wrote:
>>> I can see a few benefits of Mark's proposal. One is that it is good to
>>> have a standard representation of information. In particular,
>>> Mark's proposal would make it possible to have a master zone file that has
>>> both public and private DNS entries. Then a split-DNS server could serve
>>> only the public data to the outside world. 
>> 
>> That’s a good point, although it would still be a good point if this were just a feature of the zone file and not of the wire format.
>> 
>>> At the same time, I think it would be great if we can put link-local addresses
>>> in DNS. 
>> 
>> That sounds like a really heavy lift.
>> 
>>> It may tie in nicely with scope IDs in socket addresses. If a DNS
>>> record specifies that is valid only on a VPN link, then maybe we can already
>>> tie the address to that link. No need to change applications, it can be
>>> hidden in the stub resolver.
>> 
>> Now we need to standardize a way to identify links. This is a Hard Problem. I say this based on experience, not supposition. HNCP tried to do this, not as successfully as I’d hoped. I’ve been working on it for the Thread Border Router work, and haven’t come up with a general solution. Sure, if you have a data center and a managed multi-subnet LAN, and you can just type in configurations, this works, but most networks aren’t like that.  I think the VPN case is probably tractable, but it’s really hard to see a path to broad adoption for this idea.
> 
> 
> My idea would be that there would also be a RA option(s) which advertised the names in the SA records that where applicable to the link.  Implicit to that is that there would be a API that allows getaddrinfo() to retrieve the
> RA options for individual links and for all links on the node.  getaddrinfo() would use the later.  The former would be used to construct UPDATE requests for the DNS etc.  LLSANAME (link-local SA name), ULASANAM (ULA SA name), and perhaps others.
> 
>> If there is a path to broad adoption, it probably involves bottom-up work, not top-down design. Most of the ideas I’ve had about this that I think are practicable are very context-dependent. E.g., you can identify that you are on the same link because you received a link-scoped multicast.
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>