IETF Logo Mail Archive

Re: draft-ietf-6man-slaac-renum: Conveying Information in Router Advertisement (RA) Messages

Fernando Gont <fgont@si6networks.com> Fri, 10 June 2022 09:09 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 6ABE9C1527AF; Fri, 10 Jun 2022 02:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.775
X-Spam-Level:
X-Spam-Status: No, score=-3.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zndGwyImh3oC; Fri, 10 Jun 2022 02:09:36 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D7EC14F726; Fri, 10 Jun 2022 02:09:35 -0700 (PDT)
Received: from [10.0.0.137] (unknown [186.19.8.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B21612834A9; Fri, 10 Jun 2022 09:09:30 +0000 (UTC)
Message-ID: <49898606-b956-8c8b-58c4-64e8f21a30fd@si6networks.com>
Date: Fri, 10 Jun 2022 06:09:26 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Subject: Re: draft-ietf-6man-slaac-renum: Conveying Information in Router Advertisement (RA) Messages
Content-Language: en-US
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Cc: "draft-ietf-6man-slaac-renum@ietf.org" <draft-ietf-6man-slaac-renum@ietf.org>
References: <971cee77-6cf5-513f-c72b-458b1f0b581c@si6networks.com> <07637e195f2b43d7a38890ca697e91eb@huawei.com> <dd154578-2e93-25c8-8623-fe16cbea9b10@si6networks.com> <fc8ef78521664e96b590a1b52fb0c587@huawei.com>
From: Fernando Gont <fgont@si6networks.com>
In-Reply-To: <fc8ef78521664e96b590a1b52fb0c587@huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/O7XhHvyFBObYNpwRfR4J06H5ByU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 10 Jun 2022 09:09:37 -0000

Hi,

On 10/6/22 04:38, Vasilenko Eduard wrote:
> Hi Fernando,
> OK. More openly: your solution does not work.

This it is not supposed to be "the solution". This draft, as a whole, is 
a multi-pronged approach to mitigate the problem in question.

When it comes to the behavior being discussed in this thread:

1) It simply more explicitly aligns the specs with the running code. --
    i.e., what we normally see is also what is formally expected: send
    all info in as few packets as possible, and keep options of the same
    type together.

2) This helps propagate the info better, and also helps the mitigation
    we'll incorporate in Section "6.4.  Recovery from Stale Configuration
    Information without Explicit Signaling", which right now is simply a
    placeholder.



> You have forgotten to introduce a timer of a flag or something else to inform the host that it is the last RA in the chain was received
> Then host could start concluding what are discrepancies with his states and what to deprecate.

Please raise this, if needed, when we discuss Section 6.4., since it is 
unrelated with what is being discussed in this thread.

    -- you´ll see that when we discuss Section 6.4, such complexity is 
not needed, though.

Thanks!

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

v2.23.0 | Report a Bug | By Email