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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 29 June 2020 02:10 UTC

Return-Path: <brian.e.carpenter@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 321493A102E for <ipv6@ietfa.amsl.com>; Sun, 28 Jun 2020 19:10:53 -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 rH4NGTzZGUdZ for <ipv6@ietfa.amsl.com>; Sun, 28 Jun 2020 19:10:51 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 C8E813A102D for <ipv6@ietf.org>; Sun, 28 Jun 2020 19:10:51 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id h4so395792plt.9 for <ipv6@ietf.org>; Sun, 28 Jun 2020 19:10:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8anGd1kW7nzBTkBSbuOFrtisRPaRWe9lLcLX5hEzIGk=; b=leAalt5mKOtzq53XZclYFEBOREpnLk52pDZnqk5+hT8lrCfqUQLY5/zjbp3HFzgZZC yMIfRwk8N0AvtXeSmj3d6yKD+2d2cfF+45kIFGOZ3XZfWbE4vVgZANckY+bmmjV6pXFs pPlBNns/Vfk5eoGskCg4aV8XCP7I5HdhhWamGko6OGRBBN/srz3k6U7jBYQKcca3CFAv WUUL71m6pNb2NDJUsRrgkkHw335s+tnXXcIV0iTSFib6u1G6MpUzr7XkNCl8tovdi+TX iZVgjv9b+RDQYHpt29lqcC86mQrEy4HtjlBeYscisvrOFRzwK9vP15LqnP2Uv65VtSv4 WTjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8anGd1kW7nzBTkBSbuOFrtisRPaRWe9lLcLX5hEzIGk=; b=KmiZwOoTHqV0ESXfu9VTUDWwCwVuV5GOXoVh6jtWIQSBMwaKQPavZjevZwWS4erx09 DAvJ20hi7bGRjyLE6ZOiu1NPfF0vBXm2/6+VMH2tuzLXarwfSHqS90rvY22fMSLVkPG2 WjmN426glPPrhvaFCRiWHD4wwwXT1Ls87t0jN7+5Fp1Ip5V2NkrArBMrZJanB1m4ycCT eW3RNZ7XvYrQbqrR5wVQsIBvIEDTGOaXR6XH85PunHu1ZPkNXqR78eLMRO5DTH5eZ6FT /wMmt+o6oUECNTDGphIQ9zRAObN9XqXdL+KwdHdbNB6F7QgTES5qzw+GXihgYmjR4tb6 1Kxw==
X-Gm-Message-State: AOAM5322fQ56zsjfudsW4AkQXtob1RZYxoxDGcbcVgWzT3TnzglBusXj BMVxJcMhHX6ikGOO9T0aJtg=
X-Google-Smtp-Source: ABdhPJxoAaG9s1pomCRQGXzEvxKr+b9+OYPmjrixbEYfQdkV5t4UUZzDB2xR/Vpp/FVriw3E0+Ed7g==
X-Received: by 2002:a17:902:7c09:: with SMTP id x9mr11943402pll.27.1593396651303; Sun, 28 Jun 2020 19:10:51 -0700 (PDT)
Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id w135sm12560520pfc.106.2020.06.28.19.10.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jun 2020 19:10:50 -0700 (PDT)
Subject: Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
To: Fernando Gont <fgont@si6networks.com>, Gyan Mishra <hayabusagsm@gmail.com>
Cc: IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <23914f04-b29d-4834-4aa7-b30b9fc18ba5@gmail.com>
Date: Mon, 29 Jun 2020 14:10:46 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <3f1c62de-1e58-f063-3907-6e139ada6504@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/belwnmPJHucYPAmv98ap6ouca-8>
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: Mon, 29 Jun 2020 02:10:53 -0000

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.

    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,
>