IETF Logo Mail Archive

RE: draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5)

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 16 August 2022 08:08 UTC

Return-Path: <vasilenko.eduard@huawei.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 E5041C1595FB for <ipv6@ietfa.amsl.com>; Tue, 16 Aug 2022 01:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 pfTmHEW1lSzV for <ipv6@ietfa.amsl.com>; Tue, 16 Aug 2022 01:08:26 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97454C159826 for <6man@ietf.org>; Tue, 16 Aug 2022 01:08:26 -0700 (PDT)
Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M6Nv94V5pz67Nm9 for <6man@ietf.org>; Tue, 16 Aug 2022 16:03:33 +0800 (CST)
Received: from mscpeml100002.china.huawei.com (7.188.26.75) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Tue, 16 Aug 2022 10:08:23 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100002.china.huawei.com (7.188.26.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 16 Aug 2022 11:08:23 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.024; Tue, 16 Aug 2022 11:08:23 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>
Subject: RE: draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5)
Thread-Topic: draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5)
Thread-Index: AQHYrnZCnyxkVldvC0yHDPg2Xibn8K2vx3DggAAqLgCAAT868A==
Date: Tue, 16 Aug 2022 08:08:22 +0000
Message-ID: <cee12e3b9b0a4423ac9eb0fb92f16a65@huawei.com>
References: <020f2bf2-a381-ed7c-203b-3bfeb02921e2@si6networks.com> <9ecf0e7783fa4c72ae63dfd2bb1d795c@huawei.com> <603b39e4-bc74-798a-a212-02179cf3b2ec@si6networks.com>
In-Reply-To: <603b39e4-bc74-798a-a212-02179cf3b2ec@si6networks.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.208.67]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6IS9YS5sKbdMy1_PciRbeIXfjoY>
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: Tue, 16 Aug 2022 08:08:32 -0000

I do not agree. Section 6.7.3 has a very clear name "Sending Router Solicitations" (assuming all cases)
And the list of permitted cases is very strict:

Router Solicitations may be sent  after any of the following events:
      - The interface is initialized at system startup time.
      - The interface is reinitialized after a temporary interface
        failure or after being temporarily disabled by system
        management.
      - The system changes from being a router to being a host, by
        having its IP forwarding capability turned off by system
        management.
      - The host attaches to a link for the first time.
      - The host re-attaches to a link after being detached for some
        time.

IMHO: it needs to be extended.

Ed/
-----Original Message-----
From: Fernando Gont [mailto:fgont@si6networks.com] 
Sent: Monday, August 15, 2022 7:02 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; 6man@ietf.org
Subject: Re: draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5)

On 15/8/22 07:33, Vasilenko Eduard wrote:
> Hi Fernando,
> 
> Currently, you have no right to send RS at the time you wish (RFC 4861 prohibits it for you).
> Hence you need to release this restriction

That's incorrect.

Section 6.3.7 of RFC4861 is talking about sending multicasted RS. It's not prohibiting anything about sending unicast RSes to specific routers.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

v2.46.0 | Report a Bug | By Email | System Status