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

Ted Lemon <> Fri, 08 January 2021 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 905E13A0C99 for <>; Fri, 8 Jan 2021 04:40: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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y68qLcbgkE5l for <>; Fri, 8 Jan 2021 04:40:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38D953A0C58 for <>; Fri, 8 Jan 2021 04:40:00 -0800 (PST)
Received: by with SMTP id q137so9562646iod.9 for <>; Fri, 08 Jan 2021 04:40: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=tWXBINd+2WSFdvxjA90D/T0UTJ8fb6qwJEt0W2fLYDw=; b=DKvHs19ln+Gq5xyx9R5hTQFRq1Hl5fxqqLhopNmIEdt/pVJJfMIAz3aX8lycS8S7+3 Vvc9GJBdB7CnaNWZx6VN/jjYwka8M9Nl4V//Kv14tg5QDevtGqRIHajo18ZhzBEyZcpk 35LUnCG9v1tzK7Lm/K1p/xJMU6hgr1XM9fschqcFC+ynwQP9ewfTA6d5h4tbN7s+BQpl Bfy5s0ALOZ3Brb6pMR4+8RxosOdAglwZWX+4JkNwlKFwSGy1C8lH+wmq1Qaz5BNGbj0+ Rqt/NX8ljxucN9M+1LoMm+jMDoq/6sIzngvg0nNFTmCHfW5yvt16O5VDSMLV49y0VUW+ u18w==
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=tWXBINd+2WSFdvxjA90D/T0UTJ8fb6qwJEt0W2fLYDw=; b=V614OrJ/rNOUBNl55Yi26sBNom+vb/WLZv5NdTeD2IFm80+u5fSjxpAuc1v4RhPAob h/fc+wZ+HavSObWNv1aC3oZLFWwR8M7N3MOtz8UrcxglTkMxw6/xlFmVAcsCHVNt4VEs ChuXzzwflDjELB5vSbZHFDh5lAqjSlMe4xFiROxh6f/X88E6v6qvaN8gt5/kQ+LBCJ7E l4t0DJYvNOdYPbZ5yv9cYN2yOZHINM98voh8h6JKERdYVK1s3w5NfmzFksi7DVaUsgjk CWq8xNc9RRpBNpKujqcDAJnJMfryhHqKURpi9IEpfgQRbgUXpPBUWgYAMvWOTBnlo3og zOBQ==
X-Gm-Message-State: AOAM532oAcp+zMgFjR6SxFlE14Vh1/NxPqlc0KxvcxlWcpPYwJLYJP3N hncKF5D7FOmA2adpGj3sAG8dVg==
X-Google-Smtp-Source: ABdhPJz1Ap8BbUJRE5Kja/50mZwzOGnf/aCaIPuRMcdpY4vqXqBL4KRfWAu8vfj5LzdYEe1jx4ntvw==
X-Received: by 2002:a02:354a:: with SMTP id y10mr3298201jae.126.1610109600139; Fri, 08 Jan 2021 04:40:00 -0800 (PST)
Received: from mithrandir.lan ( []) by with ESMTPSA id 9sm5248985iob.28.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jan 2021 04:39:59 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F975737A-96B0-4BFE-87CC-9AFB3D766FAC"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Fri, 8 Jan 2021 07:39:57 -0500
In-Reply-To: <>
Cc: IPv6 Operations <>, IPv6 List <>
To: Mark Andrews <>
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: Fri, 08 Jan 2021 12:40:04 -0000

On Jan 7, 2021, at 10:18 PM, Mark Andrews <> wrote:
> When you change topology the node will see new RAs and getaddrinfo() will filter out all the old addresses.  The node has a set of link identifiers for links it is attached to.  Remember machines don’t care about these names.  They are just ways to filter out the currently useful addresses.  Each node
> will maintain its own mapping from applicable names to sin6_scope_id which will be filled in by getaddrinfo() generated by the RAs it sees.

I think link identifiers as you describe might be useful for some applications, but putting them in a database has a lot of issues. If every router on a link multicasts a link identifier to a link, then it’s not a link identifier—it’s a router interface identifier. That’s fine, but now my node has to track what router interface identifiers are present on the link, and publish its information on each identifier. Now suppose a router is unplugged from one link and plugged into another. It starts advertising its router interface identifier on the new link. Now you have stale information in the DNS, but the host doesn’t know, because there’s no positive indication that that router has gone.

You could track the router's reachability in the neighbor table, but now you have a different problem: it’s only going to be in the neighbor table if you’re using it, or if an RA has been received recently. So now you have a router link identifier that’s fluctuating. Do you update the database on every fluctuation?

Furthermore, DNS has TTLs. What’s the TTL on the data? How quickly does it fall out of your cache? Remember, you wanted to do this because Caching Is Good, so if you use a short TTL, your Good Caching isn’t happening.

What if you’re on an IPv4-only link? How do you publish your IPv6 LLA with a router link identifier? Your router isn’t giving you one. You can’t use the RFC1918 subnet prefix you got from DHCP as a link identifier, because they are non-unique.

This is what I mean when I say this isn’t practicable. Sure, it’s theoretically possible to imagine an environment where it would work. But it’s a tremendous amount of work that fails in ways that will create delay in many corner cases. And all it gets you is a hint from DNS as to which interface to use to communicate with a named host using its LLA. This isn’t much of a benefit.

If I just wanted hints, I could just do ND on every multicast-capable interface and get much more reliable hints: in most cases I’ll only get an answer on one interface, and then I can just send the packet on that interface and be much more assured of correctness than I could be based on stale data in the DNS.

Look at this from the other direction. A DNS full service resolver on your network can in many cases know where the query is coming from. BIND 9 already does this—I can define a set of prefixes that are “local” and allow queries from those prefixes, but refuse queries from other prefixes.

This generalizes well: I can do the same thing for ULAs. I could very easily mark some set of ULA prefixes as “reachable for hosts with addresses in prefixes on this list.” And then when I get an AAAA record query that has both ULA and GUA addresses, I can return just the GUA address for queries from prefixes that aren’t on the list, and I can return the ULA only for queries from prefixes that are in the list. Or ULA+GUA.

This works well because minor changes in topology aren’t relevant. We know who owns the ULA prefix. We don’t need to know the details of where sub-prefixes of that ULA prefix are being advertised. We know what GUAs we have. If our upstream renumbers us, we need to update the prefix list, but this is a very lightweight change. And particularly if we _only_ return ULAs when the ULA is valid, this prefix change doesn’t affect any host that has the answer cached: our upstream GUA prefix change doesn’t affect our internal ULAs.

So from an operational perspective, this is a really useful feature—it’s one that I’d dearly love to see in BIND.