[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [212.247.200.143]) (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 [127.0.0.1]) 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
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
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] RFC7217 and flash renumbering and IID cha… Mikael Abrahamsson
- Re: [v6ops] RFC7217 and flash renumbering and IID… Fernando Gont
- Re: [v6ops] RFC7217 and flash renumbering and IID… Ted Lemon
- Re: [v6ops] RFC7217 and flash renumbering and IID… Simon Hobson
- Re: [v6ops] RFC7217 and flash renumbering and IID… Fernando Gont