Re: [v6ops] RFC7217 and flash renumbering and IID change

Ted Lemon <mellon@fugue.com> Fri, 11 December 2020 14:07 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED453A0C16 for <v6ops@ietfa.amsl.com>; Fri, 11 Dec 2020 06:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 cGXqWTxy4Uxq for <v6ops@ietfa.amsl.com>; Fri, 11 Dec 2020 06:07:24 -0800 (PST)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 EACC13A0C11 for <v6ops@ietf.org>; Fri, 11 Dec 2020 06:07:23 -0800 (PST)
Received: by mail-qt1-x82b.google.com with SMTP id y15so6434150qtv.5 for <v6ops@ietf.org>; Fri, 11 Dec 2020 06:07:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u20U+7kmkEMj/roOIUJpTlm1BIC9lNeWHB5oq/13NgU=; b=spljCXKoCJezX1MAFzExM/au5Rrcc1/5qubXHTYcObUxvgFoKhJ7D3MJjEfmSwn+Iz qUmMEAPy/K+eiKFz9CAYYOFEmCOoAtiXV2pD6aQYLbuHppsydlaD92XjGRaAwhLbtuhx j4gsmBuAe10WWJc6/44/XsMdg68TR68uqn0Rgny7eJV9gjPlsLbaTMl043yx9IHCQeNz 9brNiDyVJ5QDQOZAd8lCCL5Ns66K3Fx0Gkr7olOJVr1z+Rd6XdaWUv4gjB+a2EG2FvBV LbgQ6EzjTpIpjzLBqSb1VPawm0RBfeEiqSLvgr99GRby9Ff74NA853JQYMbHRA9ocR8A VzuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u20U+7kmkEMj/roOIUJpTlm1BIC9lNeWHB5oq/13NgU=; b=teugRu4FWg/iB4zvipb90STVTGssEh/F3RfbwTqXEYXaEkaBgUcVt89iFOE8zvlWi0 NO6bR+mPMo2lJ7tQqLEXH4PU34JfZdpAQdWRXzKAEKlnItxxu8RQ8aiEUzAw4oN+qiCE w4D4f2ik6So2uqtQfb+7XzI/7Jm2VUtZ+wxv0P2B5qXXgUQ2F0b5CclsIoA4Xf1TAPlj L1nd0bZSiSsExwlsww98CMBTSHxZaTBFrT7rf5rUIc70vxftUn3WhnlDiCePPOtNA6Ua um1xvgj5T1FPuy7kl35pcKF7nR5hNkOtP81a/mI5UJ/DFGeuWmq99tM/VfU0Wqr/s+zU 94CQ==
X-Gm-Message-State: AOAM5301Brr9Lzz7FGqKcZsOWmBnqzA0MavopUJgTyvEQ1/JzcJJNoHQ Tpp0kGtX/CHLinBtG+AMA36pLli7PW5oEV5S
X-Google-Smtp-Source: ABdhPJyeS5oOhMWWVyZPfTtYhm1S877uc6ScHfv6x4CjqQ5BmoA2v+0b5VnwtlpXeXpGh4ZWgTv07A==
X-Received: by 2002:ac8:5ccd:: with SMTP id s13mr15967711qta.87.1607695642424; Fri, 11 Dec 2020 06:07:22 -0800 (PST)
Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id h125sm6810080qkc.36.2020.12.11.06.07.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Dec 2020 06:07:21 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <alpine.DEB.2.20.2012111147020.10335@uplift.swm.pp.se>
Date: Fri, 11 Dec 2020 09:07:20 -0500
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CA446F0B-4E0C-436E-AFF9-ECFD76F7D2C2@fugue.com>
References: <alpine.DEB.2.20.2012111147020.10335@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3ZI1zwgsYCJ3jVFn2DLYZGMeW7Q>
Subject: Re: [v6ops] RFC7217 and flash renumbering and IID change
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2020 14:07:26 -0000

Mikael, it sounds like you want to be able to reliably find devices by IPv6 address. I think there’s general agreement that this isn’t a sustainable model. There are a couple of solutions that may work better than this, that you might consider.

1. Use multicast DNS. If you have an ssh host key, this should work pretty well.
2. Use DNS Update: track IP address changes in an appropriate way, and when the IP address changes, do a DNS update.
3. Use Service Registration Protocol. If you’re interested, I have an SRP client that I think will do the job; what’s nice about SRP is that once a name has been claimed, as long as the client continues to renew, the name can’t be taken by a competing client, as is possible with multicast DNS. I also have an SRP proxy that will take well-formed SRP updates, validate them, and then use them to update your DNS server. Works well with BIND, should work with other name servers that support DNS update.

That’s the guidance I would give.

> On Dec 11, 2020, at 5:58 AM, Mikael Abrahamsson <swmike=40swm.pp.se@dmarc.ietf.org> wrote:
> 
> 
> Hi,
> 
> just wanted to share my experience.
> 
> My home has a /56 PD from my ISP. For some (unknown to me) reason my home was flash renumbered little over 24 hours ago. I didn't notice, generally everything worked. What made me discover that this happened was when I tried to access something that had a static entry in my /etc/hosts file. This is understandable, and has happened to me before in my 10+ years of running IPv6 in my home.
> 
> I proceeded to change the first 64 bits of the address in /etc/hosts, and tried again. Still nothing. Investigated further, and then I discovered that the last 64 bits had changed as well.
> 
> This seems to be because ubuntu 20.04 machines (and others) are using RFC7217 to generate the last 64 bits, and reading RFC7217 in the light of this, it says to generate a unique IID when it "moves". Now, my machine certainly didn't "move" (for some definition of move), its NIC always had link, default gateway was the same etc, but RFC7217 says to generate unique IID per Prefix, so that's what it did.
> 
> There are HGWs where the firewall allows you to configure rules that take the PIO Prefix first 64 bits and then a static IID, so that if the Prefix changes, the firewall rule but not IID changes, it'll still be correct.
> 
> With the current behavior of IID change when PIO Prefix changes, above functionality doesn't work.
> 
> So I guess my question is, how do we want these things to work? What's the guidance we want to give? I'd like people to be able to configure their HGW with firewall rules that keep working across renumbering, so what should these firewall rules be based on?
> 
> If we augment RFC7217 and say that new IID should not be generated in a flash renumbering event (for instance, if default gw is the same, a new Prefix being announced, keep the IID) that would work.
> 
> Another way might be to suggest some more advanced logic for the HGW in handling these firewall rules, perhaps based on MAC address or something? However, I don't know how the HGW would figure out what addresses are which from temporary privacy addresses, stable RFC7217 etc.
> 
> Thoughts?
> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops