Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information

Ted Lemon <mellon@fugue.com> Tue, 16 August 2022 13:50 UTC

Return-Path: <mellon@fugue.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 17856C1524A9 for <ipv6@ietfa.amsl.com>; Tue, 16 Aug 2022 06:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
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 rb7hePC_d2Ji for <ipv6@ietfa.amsl.com>; Tue, 16 Aug 2022 06:50:26 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 3890BC159A3F for <ipv6@ietf.org>; Tue, 16 Aug 2022 06:49:53 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id mk9so7862133qvb.11 for <ipv6@ietf.org>; Tue, 16 Aug 2022 06:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc; bh=lNx2JrKZcmVaeWz1sLhwOku9AuUwP9L/Awp9Q02q2Ds=; b=KKtGDR2tYsJCWz6vRdX5/nALzEzeNGWy31s30eoHbItLBu00YGLKudo0LgzjTdGuHh lGXbGBIuo3arwxkGAzF8zDy3DsKTpk9SkEwM0MBjqFWPBZrmul2dxmza7F/rV7DxjRbF y1I7s5NU5k5ZbbLdueo6x7Uy3iDM+KTv25uLgA6A8qg67KdCN/NJrgvo219ahHUhekBK GK9hJHoepqkB3tL6U4IcB7+JVmTXrxLH8ZxsLtJJ+XygqEQEsmW/9HZR63Ogwp5Kt1fs Enw8EmcIC+rMrG05KwQzkRQINRyYLw0vmFj60RQgJCItbALLREgTFC9PweyUAb2URzTH 6rsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc; bh=lNx2JrKZcmVaeWz1sLhwOku9AuUwP9L/Awp9Q02q2Ds=; b=KNqZPID9B/ykR7xFg+gGmopQcRqhzdZ+1+jMXBalC4Mj8RN9ZPVL7cmMbtKT1OqQNm 8Eulfv5hrPw+mFfC/e1ECOlJUgXuujgz5fFtTHtermr4U+7azmhpgqttoBgK3VouzCLT mPntgaSpBlE4vyAwM0jrpGa88uGggCklvmNQyw5STr3408haeDodhMV88VwR2taoa5eM Wqum6uqWO85j79wslnlQYu0bfDJl0/1ewAlUgEa2x8uCJpfdTqB9BDsKwthxkA58X2xc az3XSN2HDQzkmfzcqIYYFuOcv4070IKs6wJvHy6G09ob0Bw/SexwoM/HZFnnU+nvOJ5t Y73w==
X-Gm-Message-State: ACgBeo1H/5lq0c8ZWzzpYr2JdVwZCfAd8eyPZDsM2b+F5BZn5PXIjp6Y Ppp4lCvK98oTiTUFkWU8i8Q1xY8CHXOQ8w==
X-Google-Smtp-Source: AA6agR592yQBbLTAXrk7JhymeyWlA8Zr2Kn6n6pgYJwJ8YTXGkYPb070hucdAO9qJUvZTJdO11c1Sw==
X-Received: by 2002:a05:6214:2342:b0:473:bcd6:a3b7 with SMTP id hu2-20020a056214234200b00473bcd6a3b7mr17874884qvb.88.1660657792525; Tue, 16 Aug 2022 06:49:52 -0700 (PDT)
Received: from smtpclient.apple ([2601:18b:300:3380:dd8:5e33:3815:4f86]) by smtp.gmail.com with ESMTPSA id 128-20020a370786000000b006b941e994fasm11395499qkh.14.2022.08.16.06.49.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Aug 2022 06:49:51 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Subject: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information
Date: Tue, 16 Aug 2022 09:49:51 -0400
Message-Id: <83C838D4-8741-4643-9809-4EAE500F6DE7@fugue.com>
References: <0f93a951ee174382803bea2729e8e605@huawei.com>
Cc: Fernando Gont <fgont@si6networks.com>, ipv6@ietf.org
In-Reply-To: <0f93a951ee174382803bea2729e8e605@huawei.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
X-Mailer: iPad Mail (19F77)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7B8Q8zSIgstbDSQDZ5Bh_Pk9sus>
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 13:50:31 -0000

On Aug 16, 2022, at 5:04 AM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
> I do not understand the benefit to keep stale ND information

It might not be stale. The router might just be briefly offline. You don’t want to break all your connections because of that. If the prefix is genuinely no longer valid, then a more advanced implementation could notice that all the connections on that deprecated prefix have timed out, and then flush it, but flushing it immediately seems premature.