[v6ops] RFC7217 and flash renumbering and IID change

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 11 December 2020 10:58 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7FA793A09F6 for <v6ops@ietfa.amsl.com>; Fri, 11 Dec 2020 02:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kFLQf71YOOLc for <v6ops@ietfa.amsl.com>; Fri, 11 Dec 2020 02:58:30 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FCB3A09F5 for <v6ops@ietf.org>; Fri, 11 Dec 2020 02:58:30 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0EB80AF; Fri, 11 Dec 2020 11:58:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1607684307; bh=vMeFxFYglFiOjaZs9PppeUwREQs8ujLfvgYd7oE8yGA=; h=Date:From:To:Subject:From; b=GYWF47trBw8+dm6ZJQdQ8dNFsO9VBQCSpuYg5sfNIYgQ4D575M4KAt+3yomg+TC6F wdpecSwq4+xLCk7OQGKDqbCvm9gA55OEiqwP/380LomttmkG/ip/JBhL/ZtIBpY6Jb ukaxL89EBy3AYBRJLPVDBLX7bQsaeZ9YQZ0LYwWY=
Received: from localhost (localhost []) by uplift.swm.pp.se (Postfix) with ESMTP id 0A2B89F for <v6ops@ietf.org>; Fri, 11 Dec 2020 11:58:27 +0100 (CET)
Date: Fri, 11 Dec 2020 11:58:27 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: v6ops@ietf.org
Message-ID: <alpine.DEB.2.20.2012111147020.10335@uplift.swm.pp.se>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vVtfuMhE24KlVuhSvDwcBayGULM>
Subject: [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 10:58:34 -0000


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.


Mikael Abrahamsson    email: swmike@swm.pp.se