Re: A common problem with SLAAC in "renumbering" scenarios

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Tue, 19 February 2019 13:16 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 AD42D130EE2 for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 05:16:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 c4RQYnVDb1gg for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 05:16:02 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 AD722130ED7 for <ipv6@ietf.org>; Tue, 19 Feb 2019 05:16:01 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1gw5Fg-0000FLC; Tue, 19 Feb 2019 14:16:00 +0100
Message-Id: <m1gw5Fg-0000FLC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com> <CAO42Z2yb47OyXk__Sz-kO00pfcBJgLAhff5DF=mpAddR0iCnAA@mail.gmail.com> <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org> <56F813F4-C512-40A9-8A68-1090C76A80F6@consulintel.es> <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org> <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org>
In-reply-to: Your message of "Tue, 19 Feb 2019 12:57:10 +0000 ." <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org>
Date: Tue, 19 Feb 2019 14:15:59 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/--ONwr_QFALQ3LkIb_D4uzrEu4g>
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: Tue, 19 Feb 2019 13:16:05 -0000

> if recommending static IP addressing is an idea that 6man wants to
> push, you'll need to reach out to the security and ops areas to
> get their input on this.  I'm not sure this is an issue that 6man
> can resolve fully.

I like static addresses, but it strikes me as a bad idea to limit ourselves
to static addresses at relatively low protocol levels. 

SLAAC already has plenty of protocol mechanism to deal with changing addresses.
What is left is tying that to DHCP-PD.

I have observed many cases where a host that moves from one network to
another doesn't see a link down event. This is most common with VMs that run on
a laptop. 

This means that hosts need to have a robust way of detecting that the network
environment has changed. There is no reason to assume that routers will have
either unique link local address or unique mac addresses.

At the same time, CPEs that are not cheapest-of-cheapest typically have a 
logfile and record diagnostic information. Adding a bit of flash that lasts
the lifetime of the CPE doesn't cost that much. So there is plenty of room
to specify what a CPE should do.

Whether users get stable prefixes or not should be a matter of policy, not 
something we hardwire in protocols. The latter just leads to situations
where users get told to reboot all of their devices.