Re: I-D Action: draft-gont-6man-slaac-renum-02.txt

Fernando Gont <fgont@si6networks.com> Mon, 09 March 2020 16:50 UTC

Return-Path: <fgont@si6networks.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 B55003A13F7 for <ipv6@ietfa.amsl.com>; Mon, 9 Mar 2020 09:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 EY_4tKBtGEdM for <ipv6@ietfa.amsl.com>; Mon, 9 Mar 2020 09:50:23 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172F93A1433 for <ipv6@ietf.org>; Mon, 9 Mar 2020 09:50:22 -0700 (PDT)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (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 1343A8051F; Mon, 9 Mar 2020 17:50:10 +0100 (CET)
Subject: Re: I-D Action: draft-gont-6man-slaac-renum-02.txt
To: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>, ipv6@ietf.org
References: <158191113600.5878.10760004246455372944@ietfa.amsl.com> <35f3e826-81ce-d505-3c27-def73983d291@gmail.com> <CAMGpriVTPPcc9bKuKANp1BLnDLU2gmmeq9yfcNFm+sZaNtgoBg@mail.gmail.com> <m1j9lU7-0000JCC@stereo.hq.phicoh.net> <m1jA9CY-0000F8C@stereo.hq.phicoh.net> <299db2f5-3dad-ebe4-a5b4-76d1d6e942a1@si6networks.com> <m1jBGe0-0000KrC@stereo.hq.phicoh.net>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <66be9d89-2e38-4e91-3186-a09fa13df82a@si6networks.com>
Date: Mon, 9 Mar 2020 13:48:34 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <m1jBGe0-0000KrC@stereo.hq.phicoh.net>
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/ipv6/RT8R5otW_OL5_sRAdI8oQgIBsEo>
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, 09 Mar 2020 16:50:30 -0000

On 9/3/20 08:32, Philip Homburg wrote:
>>> I forgot to mention. The current algorithm in Section 4.4 fails if a
>>> router sends multiple RAs with a different prefix in each RA.
>>> As far as I know, that behavior is allowed.
>>
>> Nope. The algorithm can accommodate such behaviour by setting
>> LTA_RAS_UNPREFER and LTA_RAS_INVALID appropriately.
>>
>> For exampple, with the currently specified default settings, PIOs can be
>> split into two RAs, without the prefixes becoming un-preferred. The
>> values of those configuration variables could be increased as deemed
>> necessary -- albeit at the expense of sacrificing responsiveness.
> 
> This doesn't work. LTA_RAS_UNPREFER and LTA_RAS_INVALID are fixed in the
> host implementation. So the host has to guess what the router is going
> to do.

That is correct. I'd say, though, that the guess is based on empirical 
evidence. I haven't seen any implementation that intentionally splis the 
contents of RAs among multiple RAs.

In fact, it would seem to me that from the pov of protocol development, 
that might have an unnecessary negative effect on he network.




> We have no limit on what the router can do so any guess is wrong by
> definition.

That is, from a theoretical point, correct. From an engineering point of 
view, though, it's debatable (I don't think your e.g. house is prepared 
to be hit by a meteor... but it could).

That said, more on this in another email.



> At the same time, responsiveness goes completely down the drain for higher
> values. Rendering this draft mostly irrelevant if we set those values to
> something 'safe'.

There are two things going on here:
1) Unpreferring an address
2) Invalidating an address


#1 is of utmost importance. But if the algorithm fails, you just 
unpreferred the address. -- Yes, there might be undesirable oscillations 
of the preferred address,but nothing has brokon down.

#2 is what might cause breakage. In such case you can increase 
LTA_RAS_INVALID, at the expense of maintaining potentially-invalid 
addresses for longer.



> In short, I consider this a bad algorithm. I have said so many times in the
> past, so I'm not quite sure why the authors want to continue pushing this.

This is the first time I see you objecting to the algorithm, but my 
memory might be failing. Could you provide a ref to any previous post, 
such that if there were other things that you raised, we can try to 
address them? (and also to figure out what happened with my mail system).

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