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

Loganaden Velvindron <loganaden@gmail.com> Tue, 30 June 2020 05:54 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 4A5823A084C for <ipv6@ietfa.amsl.com>; Mon, 29 Jun 2020 22:54:32 -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 PYYnSR02J4sM for <ipv6@ietfa.amsl.com>; Mon, 29 Jun 2020 22:54:31 -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 D8C873A084B for <ipv6@ietf.org>; Mon, 29 Jun 2020 22:54:30 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id q8so19726304iow.7 for <ipv6@ietf.org>; Mon, 29 Jun 2020 22:54: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=iQi4VgGBsUzusm7g1edxv6SVobZcvfdk5dTOkFFt6wQ=; b=Mk2TO970ErWfHnL+TLr9X3iBE6MqKaWom0tagFWxSFqtuCRBeq8+iF0R6RVyY4rCMX eRdm6C/ahdykw8yAvBwyzJCHf8kPlRNMcfgYjNzkCuMut+GpFVvSikYIh4y71fId2GFB b2zFyTIciNZNr2Rplwuj2KPCpoXEf3If3XQghsZfBqyGzW06xq7HbDDz+6yDKp1Tm+bz NeI0wpCmqI9iplGazmH9yoPLmAGl5a4cqEGXrhHLbSElX8pJLs+u98YQGuhxd9zK87Tq YivmymC7ChFYDf7tpWS9WxVfkrRXssANuFO85RNem7dEyBp/IgXlzLmeUaEV1b3lK8LH BMrg==
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=iQi4VgGBsUzusm7g1edxv6SVobZcvfdk5dTOkFFt6wQ=; b=RoiBI8HaVZst+xQT/cRBLo7UZbhPsg1f6sMObHsE3I8XQVsiB9boYz6PFXrQyp0dkj 1uVxsTPW+MSHjbXqIVw2Y8hLx3x6zf/hgAsy8U6wcD0PUkiANwNwgn3fHuFx/HkVm1tU gc+KdeAW087KnPfOqkWmt7uXuvoV2VWXSnirjVUOotF7DsEq+FYBNYfaEpbvi3uYVyWK Gte0pdIyHLIiP6npyUIrTLf1H4ksuZdISZi2i7y7vUzRr83inH6lwQwtwgrZyxsTp/9J syqEv7mTbjRJWAZWOb4qsXVQbiYF+gT/pBbB3UrTfQ0tSNmkvxfljeblvDnRrZ8Rn2Cn Wx9g==
X-Gm-Message-State: AOAM5337v9KlMmTOhZ+f3JiO/eCJpHkGCA1LxbzDsy/7TDanvFk92MYp qL9QpnguMRwOB8M1n57Q9cXYacl0BC4Y4Tovp7T5cw==
X-Google-Smtp-Source: ABdhPJwX0ZLIWQ/0BuU5YlG8SAQi56x0Tj2k8qpru+W9f8J7zJKwk9U/9RhOnc+7A+ZwrCVqZFWRnQpuT9gLw68avmc=
X-Received: by 2002:a5e:9703:: with SMTP id w3mr20035822ioj.29.1593496469729; Mon, 29 Jun 2020 22:54:29 -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> <3f1c62de-1e58-f063-3907-6e139ada6504@si6networks.com> <23914f04-b29d-4834-4aa7-b30b9fc18ba5@gmail.com>
In-Reply-To: <23914f04-b29d-4834-4aa7-b30b9fc18ba5@gmail.com>
From: Loganaden Velvindron <loganaden@gmail.com>
Date: Tue, 30 Jun 2020 09:54:18 +0400
Message-ID: <CAOp4FwStK59Sc4UY2Hre4ZMUAnUCXeM0GYv0qNBTnGA+XXGMiA@mail.gmail.com>
Subject: Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, Gyan Mishra <hayabusagsm@gmail.com>, Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4ooqfQwrqpbu4ZBCM9EiomUlGcg>
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, 30 Jun 2020 05:54:32 -0000

On Mon, Jun 29, 2020 at 6:11 AM Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> On 29-Jun-20 13:48, Fernando Gont wrote:
> ...
>
> >> Since the flash renumbering is such a corner case I think we really have
> >> to vet the impact of changes in all other scenarios.  Also the fact that
> >> users at home are causal users not business critical that can result in
> >> revenue loss I think that would be a consideration.
> >>
> >> Also maybe having a v6ops draft that talks about corners case issues
> >> which below does exist.
> >
> > Would you mind elaborating on what you mean by "corner case"? Operators
> > have repeatedly noted on the v6ops list that these scenarios do happen.
> > And as noted in another email, work on this topic was indeed triggered
> > by an ISP that asked for guidance while dealing with this issues.
>
> I'll repeat something I think I said many months ago. While I was in an
> apartment that had a defective POTS twisted pair (eventually traced to
> water ingress to a defective junction point under the road), I had multiple
> ADSL resets every rainy day for months, and because of my ISP's policy
> that led to multiple flash renumberings per day.
>
> Yes, OK, it shouldn't happen but it does happen.
>

Dynamic IPv6 is a real pain to deal with. This was pushed as a
"business" decision to
avoid customers from hosting their own services at home in Mauritius.

[I keep pushing for static ipv6 for home users and explaining to local
ISPs that this is a bad
business decision as the cost of electricity is too high to bother
hosting a server at home.]

>     Brian
>
> >
> > https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum should make it
> > evident that this is a general issue with SLAAC, as opposed to a "corner
> > case" that happens in one particular scenario.
> >
> > Thanks!
> >
> > Cheers,
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------