IETF Logo Mail Archive

Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Owen DeLong <owen@delong.com> Fri, 01 November 2019 15:49 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FC712091F for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 08:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=delong.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 LWwtkTo-DOVq for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 08:49:14 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B9F6012095C for <v6ops@ietf.org>; Fri, 1 Nov 2019 08:49:14 -0700 (PDT)
Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1FmYBM015508 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 08:48:35 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1FmYBM015508
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572623316; bh=yMrGu5S79MTJcIyIhuXkK4/JHRsctZLlPheJPz5dAF4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=fsTVP3/WMx+j1bJx1WYqMAdNl/3vrUVNHeZYrRiwFrHGlUQobJ5imxuqGZ0x728sm otKxVfjZnL3YNQKSncOKY+qC4nAEGn7/x9GKGon6DnNikQtd6NFIx7BN6OmO7VoN6m F8m31Yg1D7QyRPJfKPySRI5fZhqAv50Oq2RuVm9U=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <abbf9cae-5ed1-add6-a963-83edf671b5aa@si6networks.com>
Date: Fri, 01 Nov 2019 08:48:33 -0700
Cc: Mark Smith <markzzzsmith@gmail.com>, Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <34AF500F-388E-4F59-B4B2-7B98B6057303@delong.com>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <CAO42Z2w5kDSMXCUTM3nQNO_Jhm0ShTo9OW_njLsno7Dhk7LLdw@mail.gmail.com> <abbf9cae-5ed1-add6-a963-83edf671b5aa@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 08:48:36 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/77I1X5DSK0VKuuHOO6i4Hfw6S68>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2019 15:49:21 -0000


> On Oct 31, 2019, at 8:18 PM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> On 31/10/19 21:20, Mark Smith wrote:
>> 
>> 
>> On Fri, 1 Nov 2019, 06:34 Ted Lemon, <mellon@fugue.com
>> <mailto:mellon@fugue.com>> wrote:
>> 
>>    On Oct 31, 2019, at 3:21 PM, Fernando Gont <fgont@si6networks.com
>>    <mailto:fgont@si6networks.com>> wrote:
>>>    On 27/10/19 09:02, Ted Lemon wrote:
>>>>    Indeed, this would also not actually solve the problem.   At present,
>>>>    the ISPs are doing something that is out of spec and causes problems.
>>>>    If we “fix” this by accommodating what they do, does that help, or
>>>>    does it just encourage them to continue doing it?
>>> 
>>>    Did happy eyeballs encourage broken IPv6 connectivity, or did it
>>>    actually help IPv6 deployment?
>> 
>>    Don’t get me wrong—I’m not saying we shouldn’t do things to improve
>>    the situation.   I am saying that we should be strategic about it.
>> 
>>>>    What should be happening on the host with a prefix that’s deprecated
>>>>    is that TCP connections should be timing out.   This doesn’t take
>>>>    very long.  
>>> 
>>>    ~9 minutes, IIRC.
>> 
>>    Should be 90 seconds.
>> 
>> 
>> You've got no more than 10 seconds unless you want end users to actively
>> try to do something to recover, which can include calling their ISP's
>> helpdesk.
> 
> I'd argue the opposite. But, anyway, for the most part the user timeout
> is not under the control of the user.

It depends on which user time out you are referring to…

The TCP stack user timeout is not under user control.

The time between when the user clicks on a URL and the when the user starts
hitting the refresh button in the browser with a frequency that increases in
proportion to said user’s frustration level is entirely under the user’s
control.

Which of these timers is more significant is left as an execrcise to the reader.

Owen

> 
> 
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email