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

Fernando Gont <fgont@si6networks.com> Mon, 09 March 2020 20:52 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 297403A16E6 for <ipv6@ietfa.amsl.com>; Mon, 9 Mar 2020 13:52:22 -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 VwjvjFv97Mo1 for <ipv6@ietfa.amsl.com>; Mon, 9 Mar 2020 13:52:19 -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 727123A16B5 for <ipv6@ietf.org>; Mon, 9 Mar 2020 13:52:19 -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 39D46801FB; Mon, 9 Mar 2020 21:52:14 +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: <5c0660a8-b78c-cadc-ebf0-863678587b14@si6networks.com>
Date: Mon, 09 Mar 2020 17:47:09 -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/0tTXGxwUMdQ9_FEluCYF_mqKRV4>
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 20:52:22 -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.
> 
> We have no limit on what the router can do so any guess is wrong by
> definition.

Section 6.2.3 of RFC4861 says:
    A router MAY choose not to include some or all options when sending
    unsolicited Router Advertisements.  For example, if prefix lifetimes
    are much longer than AdvDefaultLifetime, including them every few
    advertisements may be sufficient.  However, when responding to a
    Router Solicitation or while sending the first few initial
    unsolicited advertisements, a router SHOULD include all options so
    that all information (e.g., prefixes) is propagated quickly during
    system initialization.

    If including all options causes the size of an advertisement to
    exceed the link MTU, multiple advertisements can be sent, each
    containing a subset of the options.


So while a router might opt to omit information (I know of no 
implementation that does this), that doesn't translate into spreading 
information among multiple RAs. The second paragraph seems to convey the 
meaning of "put as much information into the packet as possible. If the 
packet becomes larger than the MTU, convey the information via multiple 
RAs".

In any case, we have added a clarification to our document.

Thanks!

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