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 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47C853A12A4 for <>; Thu, 7 Jan 2021 09:00:47 -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 cT9qElSHY0yc for <>; Thu, 7 Jan 2021 09:00:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 338D33A129F for <>; Thu, 7 Jan 2021 09:00:44 -0800 (PST)
Received: by with SMTP id 22so6016442qkf.9 for <>; Thu, 07 Jan 2021 09:00:44 -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=0zjDd9zBeMMx7wlSt7B/rMozcs8c0Djrh+/nOzBJwcM=; b=fxveEez1yVPCpFfGoEB6M6EJQz6smV8H2ZvSp03zyCpdWQFU8JuAu+2tb2fKHWD+Pw h2K/Kk5wbM/RIbG5b27HIleoISs6MrVK8wGdRqeg7nM4LnEAZFsFzRrgSQxKPfaRqIiD zyRGwaYBbZxf9zqYFYEbzWvY+mopHgkdOxGgmYrE6bWGXgP9oP1cH3ihgJfE/yzZQJqM BcXpX0JUsZRgvNjkLSIsBXRJU2qLUP5ehAtiDQ/YnlGwLvTLlBuo4fikn0H+E+rOazpJ IllnMy6zfI0ILucGIPvHawRuZaC0pW5HMjHhqtbscj/OIwd9jMAFF7/13UolbXb9tiq3 skXQ==
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=0zjDd9zBeMMx7wlSt7B/rMozcs8c0Djrh+/nOzBJwcM=; b=dPIU1bUf6gSV8ARrh7p465RhQhvh39RUB8K6F43jsj5dCQj4iw5dz1Ajpi3ALeEzD3 /mDt0hcLj3l1pqYccZ1SsDlvDF8CiuH6nEi7ahJw5PikNzdv8dRJ5R1s/Vz/HX0NIJve 5GpO3k///VqE5Yc/P466nCeM59APbnQD7uJuYfsDpLp11WbkZ41IZQwnm/0ThJNpF99X w656JYuXzTMmRzuvDYitmZNS6oBiAlJorvTUQ+gMgLFIH1WP/QyaUA7zfZcFOep/o304 aElpQIxrjc2n8NAC0ze2LZbq1NuaotZclXCI7sMKDbS712sN5LvwZCPDJ9edqCTmuVdP U2AA==
X-Gm-Message-State: AOAM5335bQBGMv9vSJgw1LOZwUfnhuWI+c9yVW8f7gyZmEjCMTtoV18D pLn49+OVqQq3V89c4FGYArfrylhdiMej7w==
X-Google-Smtp-Source: ABdhPJyKLEZDW5P8ewdnNcg/RMV+RD28BFdoK91zy6NfGsWC/sYybnLtrOWO5kkIfMAfwJj/j8cJiw==
X-Received: by 2002:a05:620a:2297:: with SMTP id o23mr10099066qkh.149.1610038843972; Thu, 07 Jan 2021 09:00:43 -0800 (PST)
Received: from mithrandir.lan ( []) by with ESMTPSA id p15sm3356844qke.11.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 09:00:42 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4CCC9A5D-F6AB-494A-AFDD-6B29A4F37DAF"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
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 12:00:42 -0500
In-Reply-To: <21510.1610035383@localhost>
Cc: IPv6 Operations <>, IPv6 List <>
To: Michael Richardson <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <21510.1610035383@localhost>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jan 2021 17:00:47 -0000

On Jan 7, 2021, at 11:03 AM, Michael Richardson <> wrote:
> No, it has to get into the wire format, and it has to be cachable on the
> client, and it has to evaluated on the client as close to the application as
> possible.
> Why? because caching is good, and throwing away your cache each time you have
> a link up/down is dumb in my opinion.

I don’t think this would help, because you’re assuming that the data would be correct, and that the host would be able to tell which view to use. This is Really Hard. I don’t think that relying on this operationally could ever be a good tradeoff to save a few round trips to the nearest cache.

Since we don’t have a way to reliably identify links, and for that matter to tell which link is in which zone, we can’t do the efficient thing you are talking about. In practice, all resolvers that I know of (admittedly, this is just one, mDNSResponder) do in fact throw away the cache whenever the link changes, for exactly the reason we are talking about: just because the info I got from the resolver was valid on the link I was previously on, doesn’t mean it’s valid on the link I’m currently on.

Remember, just because something is efficient in principle, doesn’t mean that it’s efficient in practice. :)