Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 03 February 2019 18:30 UTC

Return-Path: <jmh@joelhalpern.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 F1435126BED; Sun, 3 Feb 2019 10:30:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 POeaKnaN7PiC; Sun, 3 Feb 2019 10:30:16 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 17616124B0C; Sun, 3 Feb 2019 10:30:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43szsg4v4wz1KC9g; Sun, 3 Feb 2019 10:30:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1549218615; bh=/x8NrZZbcMEeJjJT/oEwG6IDVk5XiB/Bx+MtSpQ1oOA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=M0p9QTIgFv/ETnZs2U6a/IljvHQx7ORRjm5j1oZgavwD8Q7BrHdwzCps1MxNh1TlV YxSvdtUW8v8wfeHE1/MXdgX77UHYfoPEl3xudRouxK9vyWJ4M8N1vRauEor6oeZuuE xXa2UUCyi9ibYAThT2bID9M32/CQE8kRVQuwvv8s=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43szsc2qvXz1KC5m; Sun, 3 Feb 2019 10:30:12 -0800 (PST)
To: Fernando Gont <fgont@si6networks.com>, Mikael Abrahamsson <swmike@swm.pp.se>, Mark Smith <markzzzsmith@gmail.com>
Cc: v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
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> <ac773bb5-0da8-064b-d46b-3a218b8c9e7a@si6networks.com> <CFAEACC4-BA78-4DF9-AD8A-3EB0790B8000@employees.org> <a4f6742e-f18e-3384-d4cc-06bfab49101f@si6networks.com> <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org> <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com> <CAO42Z2xzYQESqqsz4AEE89vx=AhvBEf8Yzyae9o7z1U1XYyarw@mail.gmail.com> <alpine.DEB.2.20.1902031813310.23912@uplift.swm.pp.se> <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <857eef9b-e37d-1e3e-cf7f-ce2122f4d645@joelhalpern.com>
Date: Sun, 03 Feb 2019 13:30:08 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <23b3ffc3-7f01-6d15-ae93-c0e6932d53a6@si6networks.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/cz68aDF4SiYvtDVaTiXbK6DmHps>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
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: Sun, 03 Feb 2019 18:30:18 -0000

I have been trying to follow the discussion.  I think I have been able 
to reconstruct the problem being discussed.

If I understand correctly, we are talking about CPE behavior when the 
CPE receives IPv6 prefixes via DHCP-PD, and then advertises prefixes for 
hust using RA PIO.  The assumptions that I believe Fernando is making are:

1) The CPE Does not store its delegations across reboots.
2) The CPE crashes
3) The CPE requests a prefix from DHCP-PD
4) The CPE receives a different prefix than it received before.

An Fernando seems to be saying that this results in the CPE violating 
its "contract" with the hosts from earlier PIO information.

Given that if the CPE had stored the delegated prefix, it could have 
continued to use it, one could equally (and arguably with more 
justification) argue that the DHCP server violated its contract with the 
CPE when it did not return the still-valid prefix (with a correct 
lifetime).  After all, the server madea "contract" when it handed over 
the address.

Have I missed something in the "problem"?  Robustness is nice.  But 
let's not bend over backwards trying to fix a problem of multiple 
failures.

Yours,
Joel

On 2/3/19 12:39 PM, Fernando Gont wrote:
> On 3/2/19 14:14, Mikael Abrahamsson wrote:
>> On Mon, 4 Feb 2019, Mark Smith wrote:
>>
>>> A first hop CPE rebooting and being given a different PD prefix is
>>> effectively changing a transient packet loss event into the movement of
>>
>> What about if it decides to choose a different /64 out of that /56? Do
>> we cover this in any documents? The result to end systems is the same
>> regardless if it's different /64 out of the /56 or if it's different /56.
> 
> Agreed. In that case, if it is able to detect that the advertised prefix
> has changed, you might *expect* that it also advertises the original one
> with appropriate lifetimes. However, that implies that the prefix had
> been recorded in stable storage.
> 
> And it all goes back to the same place:
> 
> * expectations != requirements
> * Robustness has a lot to do with dealing with entities that might not
> behave nicely
> 
> 
>