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

Fernando Gont <fgont@si6networks.com> Sun, 03 February 2019 15:00 UTC

Return-Path: <fgont@si6networks.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 AE788130D7A; Sun, 3 Feb 2019 07:00: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 bKRjc3SXmGI0; Sun, 3 Feb 2019 07:00:53 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B5812426A; Sun, 3 Feb 2019 07:00:53 -0800 (PST)
Received: from [192.168.3.66] (unknown [186.137.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D2A2884544; Sun, 3 Feb 2019 16:00:46 +0100 (CET)
From: Fernando Gont <fgont@si6networks.com>
To: Ole Troan <otroan@employees.org>
Cc: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, 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>
Openpgp: preference=signencrypt
Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA==
Message-ID: <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com>
Date: Sun, 03 Feb 2019 12:00:27 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Zeul8NExT7jlmcc-fQDHQF_Jb4Y>
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 15:00:57 -0000

On 3/2/19 09:27, Ole Troan wrote:
> 
> 
>> On 3 Feb 2019, at 12:49, Fernando Gont <fgont@si6networks.com> wrote:
>>
>>> On 3/2/19 07:32, Ole Troan wrote:
>>>
>>>
>>>> On 3 Feb 2019, at 05:29, Fernando Gont <fgont@si6networks.com> wrote:
>>>>
>>>> On 2/2/19 08:57, Ole Troan wrote:
>>>>>> One question is whether it makes sense for routers to have valid lifetimes of
>>>>>> more than a day for prefixes that are obtained using DHCP-PD.
>>>>>>
>>>>>> Another is whether general purpose hosts should accept lifetimes of more
>>>>>> than a day. Maybe hosts should just truncate.
>>>>>
>>>>> The (original) intended lifetime for DHCP PD is a lifetime equal to the length of the contract with your ISP.
>>>>> Lifetimes become meaningless with “flash renumbering”. Neither SLAAC nor DHCP PD is designed for that.
>>>>>
>>>>> The simple solution to this problem is “if it hurts, stop doing it”.
>>>>
>>>> FWIW, lifetimes are mostly irrelevant to the problem that *we* are
>>>> discussing (which is rather orthogonal to the problem mentioned above):
>>>> our case is that in which the router just reboots -- so no matter what
>>>> the lifetime was, the information will be invalid anyway.
>>>>
>>>
>>> That’s not how SLAAC and PD are designed. Lifetimes are not invalid just because of a router reboot. Look at advertised lifetimes as a sort of contract. 
>>
>> Well, the problem is that you are making a contract on the LAN side for
>> a contract you may not have on the WAN side. If the router reboots and
>> the CEP no longer "owns" some prefix, then that contract is void.
> 
> You have the contract on the WAN side. What makes you think not. E.g via PD learns that given prefix is valid until March 1 2020.
> A reboot doesn’t change that. 
> 
>> Ideally, the CPE will advertise that the contract is void. But it is
>> clear that for most deployed CPEs, that will not happen.
> 
> So a bug. 
> What you are talking about is the case where the ISP breaks the contract. While it previously promised to delegate you a prefix until 20200301, all trace of that has gone. 

The CPE is the middle-man between the ISP and the LAN. No matter what
you may *expect* the CPE to do, the CPE is currently not actually
required to e.g. clean after the contract that the ISP broke (if you
assume/think there's such a thing), or even adjust prefix timers
according to the DHCPv6 lease times -- talk about under-specification of
the glue between e.g. DHCPv6-PD and SLAAC.

Besides, the layer-8 contract between the user and the ISP may be that
you get dynamic prefixes. This means that whenever you request a lease,
you get a different prefix. You might say that if you don't do another
DHCPv6-PD request, you should be able to use the same prefix. But if you
do ask a new prefix, you might indeed get a new one -- and this is what
normally happens after reboots.

The CPE should -- if possible -- be faithful to its LAN hosts, and
advertise if previous contracts between the CPE and the LAN hosts are
void. i.e., if the CPE does  not get leased the same prefix as before,
it shoudl notifiy its "clients". However, possibly for simplicity sake,
CPEs don't record what
information was previously advertised on the LAN -- they are not
required, so.... when they reboot, they may not not be in a position to
notify hosts accordingly.

That's the environment hosts operate in -- no matter whether you or me
like it.

In that environment, hosts can and should be smarter.



>>> What you seem to be talking about is either a bug a misconfiguration or both. 
>>
>> It's neither of those. If anything, it's the result of
>> under-specification of the necessary glue between automatic
>> configuration on the WAN side, and automatic configuration on the LAN side.
>>
>> e.g., there were no requirements for CPEs to keep track of prefixes that
>> they have been leased in the past -- if at all possible.
> 
> DHCP PD will give you the old prefix back. 

Not necessarily. In fact, it may intentionally not do that. If you no
longer own the addresses, the sessions will have to be torn down.




>>> If you want something like session survivability,
>>> that’s not a trivial problem to solve.
>>
>> Not sure what you mean by "session survivability"
> 
> Try to keep a TCP session active while changing addresses. 

Of course that's not what we're trying to solve here.



>>> Currently the network will give an ICMP destination unreachable code 5 and deprecate the invalid prefix if it has information to do so.
>>
>> Where in RFC4443 do ICMP unreach code 5 get to invalidate prefixes?
>>
>> Answer: Nowhere. They don't get to do that. All ICMPv6 error messages
>> are soft errors. And it would be a huge mistake (and huge
>> vulnerability!) to behave otherwise.
> 
> It’s a strong hint to the host stack to pick a different source address. 

You said "deprecate the invalid prefix if it has information to do so."
-- selecting a different address is a very different thing than
deprecating an address. In fact, for connection-less protocols that
might not even make sense -- since it implies resending stuff that you
might not even be able to resend (send buffer is gone).

Besides,

* You are assuming somebody will send an ICMPs. But they may not.

* You are assuming that if they do, they will send code 5. But they may not.

* You are assuming that code 5 is an indication of wrong address... but
it may be an indication of incorrect route.

* You are assuming that nodes will process icmp code 5 in one specific
way. I don't know of any implementation that behaves in the way you
describe.




>>> Without getting into the multi-homing discussion and requiring hosts to “throw spaghetti on the wall”, I don’t see how your draft improves on that. 
>>
>> Not sure what you mean. If the same router that advertised those
>> prefixes doesn't advertise those prefixes anymore, why would you think
>> they are still valid?
> 
> Because that’s what the network previously advertised. 
> If source addresses from that prefix no longer works that’s a good hint to the host to try something else. There’s a list of heuristics the host must use. 
> 
> I still don’t see how your draft improves much on this. Can you explain?

What our document wants to address is this:

* Initially, unprefer addresses for the deprecated prefix.

* subsequently, clean up the lagging addresses.


One (more complex) way to achive this would be to e.g., wait for N *
ROUTE_ADV_INTERVAL (I've just made up the parameter name), and if at
least M RAs with PIOs have been received, but none of them contain PIOs
for the (now invalid) prefix, deprecate the prefix.

The solution we currently propose in the I-D is simpler, and just
involves one additional bit per prefix in the local data structures.

For a sample scenario, please check Appendix B of our draft. THe idea is
simple: if two consecutive RAs with PIOs don't contain the
previously-advertised prefix, un-prefer addresses for such prefix.
Subsequently, once addresses have already been un-preferred, if you
receive two additional RAs with PIOs that don't advertise the
previously-advertised prefix, remove (invalidate) the corresponding
addresses.

So, after two RAs, the lagging addresses are not preferred anymore.
After four RAs, you get rid of them.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492