Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

Loganaden Velvindron <loganaden@gmail.com> Tue, 07 July 2020 11:00 UTC

Return-Path: <loganaden@gmail.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 98AF23A0B13 for <ipv6@ietfa.amsl.com>; Tue, 7 Jul 2020 04:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dbogHTlhudBr for <ipv6@ietfa.amsl.com>; Tue, 7 Jul 2020 04:00:38 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739803A0B1B for <ipv6@ietf.org>; Tue, 7 Jul 2020 04:00:30 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id y2so42668613ioy.3 for <ipv6@ietf.org>; Tue, 07 Jul 2020 04:00:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p5aC1TyI3Sr9n2NaMDWf6pfGTdmyqG1ONKwrkcFII9Q=; b=Jy6vycENIo/OiJyqdwuZJY9HH3LKMyeJunAPnVT8P0LbGouexN0FFUjRbAnDkWmhEf ZGPA8XXt/Zv3gbaMJ5L2croQS9H9tEHpUO259h4kXGrs5woY5/57UzjQxzMfI4jpGCML x9dGmFDRQZAnXf8p8OMr01zmj7r4R0Om5krHFXHTeNLnqtJ8xlO9qtzJ9FSx14jDgUs4 BPoa50Gxo8WLGB3wTsTEXCKTTvqTxBTkMYT26jB21vgPAzUpdF/G0/U6sf5lxleooEVs 9LW1WkuWb9aynoADVihOoWW2HIR2udpywr1Q2i3lA7Dn7y1kNgpgGAcgwTH4+oefFjL4 oCRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p5aC1TyI3Sr9n2NaMDWf6pfGTdmyqG1ONKwrkcFII9Q=; b=TXQlPa601/Fwu6qIwUf/LHw4W4/wCxnc+bNoMlea0AcmZjtxrdoJm8I4OWemIA9C/a xngFznoqX2F/pyQu2g+opRG1FMBaYputw7x5b4WbUcsjf/2lIZbYtCoQ76SklOBjI9x2 Kyo463EVztEbesfsrEa7CvUpZPteMkYRJ8zO+Va8sd0xEuQiMzimm0s0fLyfzGmyRQkp kZWH5o5nde1ofaJ6ZWnWiGkSYWB3ejIlO6s6cOV0OG5lNI3fhdGjV/TE+tnJYznM1zyg qRtNndUQCE1sJWFrm2qFt9dKAV4xoy0Prf7Zjrk+xOkrC8TskFhLeQdbTGt3yC3NOh9j 8jxg==
X-Gm-Message-State: AOAM533YRUkf0oivNC/uOZSvDaTt3g+VzDpuCoUjlEBQ/sNdd+C8WCWx V6fe9OLXE8txyP+N/YFgoW4AMYddgY/1Tg+dJUk=
X-Google-Smtp-Source: ABdhPJzt+vCXHA0eOJxH20jyJOuYDg5KEBqAk/hKa5dp42Ad0KGBJYa3/TK2eNRVMP99xxGyBzAokVuQ7D2nGtovdG0=
X-Received: by 2002:a05:6638:2508:: with SMTP id v8mr54555344jat.94.1594119628486; Tue, 07 Jul 2020 04:00:28 -0700 (PDT)
MIME-Version: 1.0
References: <CC295D49-5981-41C3-B4DB-E064D66616CE@gmail.com> <adddbd07-2262-b585-68a1-00fc28207a84@gmail.com> <CABNhwV0MFe-d6-DL2SuhuyPSq7Mn0-TS=poDn9ynAqn1ZWXOKA@mail.gmail.com> <CAKD1Yr3zEcZ5=1ttDbZGDtN86qy+wRbFXmOHXqngqu6NuYYJ5g@mail.gmail.com> <2759b55c-871f-dc41-c180-47c1ebd1135d@gont.com.ar> <CAKD1Yr2Uv=2PaoJschS_a6KSE_V8CgL=WkUxnUnBFqQ9Rkoe4Q@mail.gmail.com> <201C51F9-B196-4EE1-82BE-2312FD70E217@gmail.com> <CAMGpriXfDn_zyKAaiDSE1OAhB_yqR_22U_UxfJQ7k+3PU=apTg@mail.gmail.com> <28342.1593545115@localhost>
In-Reply-To: <28342.1593545115@localhost>
From: Loganaden Velvindron <loganaden@gmail.com>
Date: Tue, 07 Jul 2020 15:00:16 +0400
Message-ID: <CAOp4FwTy+5q50JssBDQuJjUVS2XXZQ=XKLqH38yM2qt3RBLqhw@mail.gmail.com>
Subject: Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: IPv6 List <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tc0Yl_ret-GKjhQ7KMGlETsbkPc>
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: Tue, 07 Jul 2020 11:00:40 -0000

On Tue, Jun 30, 2020 at 11:25 PM Michael Richardson
<mcr+ietf@sandelman.ca> wrote:
>
>
> I think that we have a rough consensus that there are events that seem to
> cause long-connecting devices (such as desktops, TVs, appliances) to
> sometimes fail to notice when there is a renumber.
> ("Short-connecting" devices like phones tend to join/leave often enough that
> they usually get recent info. and they get tested more for this)
>

There is a problem to be solved there and I support adoption of this Draft.


> It seems that for the non-flash case, that there is a lack of complete
> testing/implementation for the various cases, most of which are probably
> already dealt with given proper implementation of the protocols.
> The result is that many of us see renumbers which do not get deployed
> smoothly, and we assume a flash renumber when in some cases, it was not.
> ("Your failure to plan ahead is not an emergency to me")
>
> The result is that the urgency of this situation varies by experience, and by
> quality of implementation.  It seems that if we had an RFC that dealt with
> the **FLASH** renumbering situation, that by construction, devices that dealt
> with that would also deal smoothly with the planned renumering situation.
> (Didn't we have an entire WG at one point to renumbering? I think it didn't
> end that successfully, but that was during years I spent less time on IETF)
>
> As Erik points out, I think that there a number of active measures that can
> mitigate the situation without changes to RAs, but I also think that we can
> plan long term such that each end of the conversation is trying to make
> things go smooth.
>
> To clarify: I think we should adopt this document, provided we can more
> constructive understand that we do not all see the same part of the Elephant.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------