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

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Sat, 23 March 2019 14:31 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 4660E1286C8 for <ipv6@ietfa.amsl.com>; Sat, 23 Mar 2019 07:31:28 -0700 (PDT)
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 whtFuuGj1cWO for <ipv6@ietfa.amsl.com>; Sat, 23 Mar 2019 07:31:26 -0700 (PDT)
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 67145127964 for <ipv6@ietf.org>; Sat, 23 Mar 2019 07:31:25 -0700 (PDT)
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 m1h7hgA-0000HfC; Sat, 23 Mar 2019 15:31:22 +0100
Message-Id: <m1h7hgA-0000HfC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Fernando Gont <fgont@si6networks.com>
Subject: Re: [v6ops] 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: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <CAHL_VyD34V=TRcsCp0DOO9HJNHyy5xkiMQ_cZoBa7zTE4fe5OA@mail.gmail.com> <ead01e0a-9211-7944-88d6-ae8d037c03a8@si6networks.com> <FB8B77EE-CC16-4418-BB5E-D44EE66D6B72@jisc.ac.uk> <29dcc6ed-03f6-3ead-6866-eecbefdf1483@si6networks.com> <F4F90B88-3EED-4AF2-82FE-5F1023A05605@employees.org> <c3562b5b-0eec-636b-3bb1-1b0381109542@si6networks.com> <CAJE_bqdttuCfqbjyVRiyZrUOvckLhWMNr21eMfeXBVmv+UbTkA@mail.gmail.com> <924e562a-82e8-e224-d5c3-859c493657e8@si6networks.com> <CAJE_bqfHcL202E+t+RdtdnFMdGNX7NbbFQ8v_rcc1u_gd4Yqog@mail.gmail.com> <81aa4ec3-82 77-794a-4da1-9855d2b6b97f@si6networks.com> <m1h6DxP-0000F3C@stereo.hq.phicoh.net> <8906689d-f9eb-ed74-ae4d-e72d51e d8866@si6networks.com>
In-reply-to: Your message of "Sat, 23 Mar 2019 09:25:59 -0300 ." <8906689d-f9eb-ed74-ae4d-e72d51ed8866@si6networks.com>
Date: Sat, 23 Mar 2019 15:31:21 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hZ9c7s4qQBe0RVrOxTUqbp2HvlI>
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: Sat, 23 Mar 2019 14:31:28 -0000

In your letter dated Sat, 23 Mar 2019 09:25:59 -0300 you wrote:
>> I find the following issues in draft-gont-6man-slaac-renum-01:
>> - In the notes it says "The aforementioned processing assumes that while
>>   network configuration information might be split into multiple RAs, PIOs
>>   will be spread among *at most* two RAs."
>> 
>Note:
>The same concept can be implemented as follows:
>keep a counter of consecutive RAs with PIOs that have not advertised the
>existing prefix. And trigger actions after some locally-defined value "n".

I'm not sure that will work. If you set 'n' high to be safe, then it will
take long time before the hosts takes action. If you set 'n' low, then you
still have a risk that a particular network exceeds this value.

>> - The draft proposes many changes to router behavior in particular 
>>   increasing the frequency of RA multicasts.
>
>It's not really a change in the behaviour. It is playing with the knobs
>that the protocol has, within the acceptable boundaries.

I think 'playing' with knobs should be left to operators. If we change 
default values of timers, then effectively we are changing the protocol.

>> - Increased multicast rates may have a negative effect on battery lifetime.
>
>Point taken. However, it would seem to me that if you care about battery
>life, rather than banning what a protocol does, the strategy
>would/should be different. You have lots of protocols,
>HTTP-based applications, etc., etc. You cannot police all at the
>protocol level to save battery life.

I think we should design protocols such that the use of periodic multicasts is
minimized. A node receives these multicasts even if it is otherwise idle.

Making these multicasts more frequent is a step in the wrong direction.

>> - The algorithm has a tight coupling between modifying the preferred and
>>   valid lifetimes of addresses. In most cases, accidentially marking an
>>   address as deprecated has little effect on connectivity. Deleting an
>>   addresses by setting the valid time to zero immediately disrupts all
>>   communication that uses the address.
>
>But if you don't, you cannot communicate with the new "owners" of your
>stale prefixes.

I don't think that's true for two reasons:
- If the ISP re-assigns the prefix within the valid-lifetime of the
  IA_PD prefix option, then the ISP is violating the DHCPv6 RFC.
- The source address selection algorithm avoids deprecated addresses.
  So the only way this can lead to trouble is if the a new node would
  use the exact same address. With SLAAC that basically cannot happen.

>
>>   What is worse, these changes to the valid time are not necessary do deal
>>   with the problem at hand: flash renumbering situations.
>
>Not sure what you mean.

In my opinion there is no need to actually remove old addresses to deal
with flash renumbering. It is sufficient to make them deprecated.

>> For each PIO with A bit set and preferred lifetime non-zero, collect
>> the label values (based on the policy table in RFC 6724 "Default Address
>> Selection") in a set.
>
>What do you mean by "label"?

See Section 2.1 in RFC 6724 (the 'Policy Table')

>Counting RAs or using timers is essentially the same...

It is not clear how to me could get the same effect using counters. Maybe
you can give an example algorithm.

>In timeframe of 60 seconds you'll get at most one RA. If it happens to
>be lost, you will not get any.

Yes, the algorithm will perform worse in the context of packet loss.

>> (I guess that for battery lifetime it is best to send all multicasts
>> together). If a router would spread RAs out over a longer period, 
>> hosts will follow the RAs causing load to be distributed over multiple
>> prefixes in a predictable fashion.
>
>>From the pov of the folk doing troubleshooting, this is not of much help.

You are right. I have an idea how to deal with this issue.