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 D58023A129F 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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OalOb_Qxpwox for <>; Thu, 7 Jan 2021 09:00:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1AC733A1294 for <>; Thu, 7 Jan 2021 09:00:44 -0800 (PST)
Received: by with SMTP id 186so6050402qkj.3 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=ZgH9KgcmQ2MvfjwbjXtyUFvZtcGItgnwiPRmF4s1EMfm3RYLSfhX54TkPEvKuOaXrS NjAlVkp+wFZ1sYkDgZsIJQ21TbU1M6jUpl66W7JGFJeYEt05CeXxUEbeN7nqoNYJLLhv Nw1IppIaqMbpV/M+Q/MymD7Gh7jR11c8MpK8JvppFXWykqnFOkBue5DvVqG6e8j1S0HF P3jT2jd8QoarrZXZNyvPA3cTaCnew24WRUZJmKq8XNZ2mSOpDK4EyxFtFqMdJO5zyvun Hj30/xxA/a3FEBfsIVyOSQmgFzhBGC4yUwTpI4ErjQ91V9WkkHxz3wHsxP7stIZ3IkPL eZ6A==
X-Gm-Message-State: AOAM532Ic7HsuOfaPMWPI/OJNFcSblQx8ERQ1g02NtgqaBwiI1Qg9ff/ wEhVvCSp6iRHp9LnWLuApIOpcA==
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.\))
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: <>
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 17:00:48 -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. :)