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 12:40 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 8A29E3A0C58 for <ipv6@ietfa.amsl.com>; Fri, 8 Jan 2021 04:40:04 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qebpZAr74mHX for <ipv6@ietfa.amsl.com>; Fri, 8 Jan 2021 04:40:01 -0800 (PST)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 3BCF43A0C93 for <ipv6@ietf.org>; Fri, 8 Jan 2021 04:40:00 -0800 (PST)
Received: by mail-io1-xd2b.google.com with SMTP id e22so9035902iom.5 for <ipv6@ietf.org>; Fri, 08 Jan 2021 04:40:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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=qGrKtdiX7TwQzkPJ33I6dlQS/Iyhk1QJBTcMzWkbqKGVVfxWaSkQwFpuhy16xygGLm KRhT/r3a8V6qpL/NcUskBTB116ZtcjPI8y7BAcDB2E4uiY8YqCasyuOdgAy6gaEtbSZT 6nknyABa4azSxeLdQncz7WPUGModcJ9VDwS+/WkuGAuH9bqSd8LnWIFo0dV/4+FLyBcN lnOxX1RuE1aMpQpfOtf+N4YDG/y4J9c7DsGQDxlzrHDinR2MLeSHpzDxEt+X5bgSbS44 rvmk/CKHrUoTmLllSGVulBempSAtTvsBSCq/hxNu+nv7gkSlv/KrGHX8Z3makDFOmXeq xJlw==
X-Gm-Message-State: AOAM533U+z6Na1tngPfwaIOlaUqFSBZzUmMBFt+7sgU8hafHfHwnhui3 35I2l2qQTSmZOiWltMN09WsXVtAJEWDz9Q==
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 (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 9sm5248985iob.28.2021.01.08.04.39.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jan 2021 04:39:59 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <4E62C135-009D-409A-941C-E2F44C43759B@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F975737A-96B0-4BFE-87CC-9AFB3D766FAC"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.2\))
Subject: Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)
Date: Fri, 08 Jan 2021 07:39:57 -0500
In-Reply-To: <057ABF22-4C44-4EB7-8AF5-E9F173D67F2E@isc.org>
Cc: IPv6 Operations <v6ops@ietf.org>, IPv6 List <ipv6@ietf.org>
To: Mark Andrews <marka@isc.org>
References: <E3625337-3A59-4F0A-9EEE-EC8F6B39C965@isc.org> <537EBE5A-6554-4904-8701-03940C914FE3@fugue.com> <5A9F034B-64AB-4A96-BB8C-7A9286EF2654@isc.org> <057ABF22-4C44-4EB7-8AF5-E9F173D67F2E@isc.org>
X-Mailer: Apple Mail (2.3654.60.0.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2ezUOgw1PNrjWthE9127A1wsF24>
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 12:40:05 -0000

On Jan 7, 2021, at 10:18 PM, Mark Andrews <marka@isc.org> 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.