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

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Mon, 04 February 2019 14:44 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 3214E1271FF for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 06:44:56 -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 4Jeth12S0PpJ for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 06:44:54 -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 2D285124BAA for <ipv6@ietf.org>; Mon, 4 Feb 2019 06:44:54 -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 m1gqfUT-0000K8C; Mon, 4 Feb 2019 15:44:53 +0100
Message-Id: <m1gqfUT-0000K8C@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> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <62b74cf1-9cb0-bba3-b078-cb6f48e90145@foobar.org> <m1gqeb9-0000GCC@stereo.hq.phicoh.net> <95f65ece-0f12-c2b0-860d-540db4b335b9@foobar.org>
In-reply-to: Your message of "Mon, 4 Feb 2019 13:53:19 +0000 ." <95f65ece-0f12-c2b0-860d-540db4b335b9@foobar.org>
Date: Mon, 04 Feb 2019 15:44:48 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Bpnpdvv3vRGmoydWWq7Up8zWtDM>
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: Mon, 04 Feb 2019 14:44:56 -0000

In your letter dated Mon, 4 Feb 2019 13:53:19 +0000 you wrote:
>Philip Homburg wrote on 04/02/2019 13:47:
>> In theory we could specify how access routers could do the right thing. And 
>then
>> get CPEs to do the right thing as well.
>> 
>> But I think it would be more productive to make hosts more robust.
>
>making hosts more robust is a good deal more difficult and error prone 
>than making ISP provisioning systems more aware of maintaining state.

It seems to me that setting the preference time to zero for all addresses
derived from a PIO from a particular router that are not covered by
the PIOs in a received RA would basically solve the issue for common
use cases.

The way I see it, there is a relatively simple interaction between a host 
and a CPE. Something we can understand. There a lot of weird stuff surrounding
access routers making it unlikely that all of that gets fixed. Even
in simple cases with static prefixes, access routers (and surrounding 
infrastructure) already do lots of weird things. Getting support for rolling
prefixes properly is an uphill battle.

At the same time, for IPv4, NAT will hide most of these issues. We can only
hope that CPE vendors will not add some kind of IPv6 NAT to deal with this
problem.