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

Ted Lemon <> Thu, 07 January 2021 15:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C54543A11FC for <>; Thu, 7 Jan 2021 07:09:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Da9HP5do_7wQ for <>; Thu, 7 Jan 2021 07:09:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2227F3A11EF for <>; Thu, 7 Jan 2021 07:09:00 -0800 (PST)
Received: by with SMTP id b9so4410415qtr.2 for <>; Thu, 07 Jan 2021 07:09:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i/xEVBkSieHZArJg8d3oJd2WhMQxpjhvY8+lzHUpDWg=; b=NEYlJ1RT9rcLO8WdESHVD5gmEiSPslWDLLKDVneWUICINTMP2W0BVS8o9K/oWGd04X bNvHxElMhwV7Wj5nA3dya+P6X00Z5XMuyJ1wGZUpLXPKzsZL+61lmBLr+VpkWKEr10zX B3Zf5uLBOpl1VC4SGn4OaWV2Bw7q5zcprtTN8qVhRs4IgAq4/YmGH+YCPGKdTnFaeO94 dQmfcBpmdCfSu8LwtT5lee3faKO67EHdp8yi4uvu9MTJD1f2h6AHKFb2arbGTDdPlwju npjcl5mv6mJLwqDSs+SRrQsLT1dxbp/iWzb5netN+JC9CZ+rmpRHtkkwkhKaaJuwbWz2 zQLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=i/xEVBkSieHZArJg8d3oJd2WhMQxpjhvY8+lzHUpDWg=; b=Pw6jctNJBZkbh+8JYR+lWTJNPtzxDfCPXFW4Ksz/gVE5Y9V9JqhfH/MK2BjyiPL2pv IZ8yIktMxQ+m1/0qDi2ozyn8Exts5NyvhSJhRv+NWEF4KaeDi8lYgrU9rDK3cDN/iyii 65Lx/JFD0NVcazS+73Hxl9X/bBIUMMzS18DeJmsQHEmwrEI1BXVx8/Wy+nHzDelK5XtK 4svegMw/SLNzQ6iLomakninocC658tzo2zOP66NQiuOffuJs0HK6L3Wscrt1NfJMtixa g4MOgxLhBIzsetCQv+TQ3q3q6mvIi76vHIqa4Ks0LnUZdEjhbnJVAIvxeEgdUeU7ZTGU 6LEA==
X-Gm-Message-State: AOAM531xX6P6QdiQaK/6OLazvs06IAHAGH1SPYg0G0dPMmO0NoZXYc/b 2YAh1z6X9rMxCAuz3CqjCAPLHoHtnn8sFQ==
X-Google-Smtp-Source: ABdhPJxJZ5tXCkLrHP76EIBlwK0wUSI3A6bNT2GfpPFHwIQ+sKAjRYCGWKaBargVi/6VvzVHrLGFQA==
X-Received: by 2002:ac8:47da:: with SMTP id d26mr8681000qtr.4.1610032139164; Thu, 07 Jan 2021 07:08:59 -0800 (PST)
Received: from mithrandir.lan ( []) by with ESMTPSA id c2sm3196157qke.109.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 07:08:58 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6C76C077-BFCE-4960-8931-385B55739E09"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Thu, 7 Jan 2021 10:08:56 -0500
In-Reply-To: <>
Cc: IPv6 List <>, IPv6 Operations <>
To: Philip Homburg <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2021 15:09:04 -0000

On Jan 7, 2021, at 9:55 AM, Philip Homburg <> 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.

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.