Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Jan Zorz - Go6 <jan@go6.si> Fri, 22 February 2019 20:13 UTC

Return-Path: <jan@go6.si>
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 C4F2C130E66 for <ipv6@ietfa.amsl.com>; Fri, 22 Feb 2019 12:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=go6.si
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 e1GGfs1r7-iG for <ipv6@ietfa.amsl.com>; Fri, 22 Feb 2019 12:13:34 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [91.239.96.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDD91277D2 for <ipv6@ietf.org>; Fri, 22 Feb 2019 12:13:34 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id D6D29660DC for <ipv6@ietf.org>; Fri, 22 Feb 2019 21:13:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at go6.si
Received: from mx.go6lab.si ([IPv6:::1]) by localhost (mx.go6lab.si [IPv6:::1]) (amavisd-new, port 10024) with LMTP id 9VtnmUzQvy8O for <ipv6@ietf.org>; Fri, 22 Feb 2019 21:13:28 +0100 (CET)
Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.go6.si", Issuer "Let's Encrypt Authority X3" (not verified)) by mx.go6lab.si (Postfix) with ESMTPS id C14B8660DB for <ipv6@ietf.org>; Fri, 22 Feb 2019 21:13:28 +0100 (CET)
Received: from haktar.local (unknown [IPv6:2001:67c:27e4:5::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Jan Zorz", Issuer "COMODO RSA Client Authentication and Secure Email CA" (not verified)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 29BB7803CF for <ipv6@ietf.org>; Fri, 22 Feb 2019 21:13:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1550866408; bh=2S15IIILhNzkK6LjeXrmp9aU/rRtKPPlP9ZwIJ67xKk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=T8kJo6if0dKc14skLvHQtUucVZ+xuKPEp8QhPB6/48mluwlcEWoeIeHfs0G702yJ3 Pz7aXdPTIotXgBaHZPM6n31/VrISpLzOy8bLq7/p7B2YlaOam50RUAIKIqNHx0BrGg WSVeCOV2m2TZv34HDB88ltbKii/qOxU8ylzfado8=
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <A1B1BECB-3A64-437D-8D63-676B24F2340A@huitema.net>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <7d970b44-4463-2b6d-c428-fc05e2ad6590@go6.si>
Date: Sat, 23 Feb 2019 00:13:26 +0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <A1B1BECB-3A64-437D-8D63-676B24F2340A@huitema.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Rwvdd5tjfObQwRSzGhvDj9DXAjA>
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: Fri, 22 Feb 2019 20:13:37 -0000

On 22/02/2019 17:44, Christian Huitema wrote:>> Most people feel the 
outcome is undesirable when it happens.  Some
>> people feel that it's not worth getting too excited about because
>> assignment stickiness tends to ensure that prefix assignments are
>> long-lived enough that it probably won't cause too much difficulty.
>> Others noted that long SLAAC lifetimes and lack of application
>> workarounds (HE, etc) would make it a noticeable problem, when it
>> happens, but didn't comment on how frequently it happened.
> 
> I think that's a good summary: a problem that does not occur very
> often, but is very annoying when it does.

Since we documented this behaviour in RIPE-690 BCOP document and 
operators reached the consensus that it's least painful if they 
currently make PDs as static/stable as possible - this might happen less 
than before. I keep receiving feedback that many operators actually read 
the document and decides to avoid dynamic PDs despite the fact that 
their original network design choice would be different and they suffer 
in silence, waiting for SLAAC to be fixed and/or CPE behaviour to be 
improved.

Some of them can push CPE vendors to make their CPE better, some of them 
can't, but about improving SLAAC - they can just wait for IETF to react 
and potentially OS vendors to fix TCP stack implementations after IETF 
is done with the work.

>> Fixing or updating SLAAC is likely to take years to roll out and at
>> least one person was of the opinion that SLAAC was basically
>> unfixable in this regard.  This ignores whether it would be useful
>> or viable for the IETF to issue advice to CPE vendors and service
>> providers about how to avoid the problem from happening in the
>> first place.
> 
> Anything we do in this space can take a long time to roll out, but it
> does not take forever. In many cases it probably takes less time than
> it takes to agree on a potential solution in the IETF. For example,
> security bugs in operating systems can get patched in a matter of
> weeks or maybe months. Not all devices can be patched quickly, but
> many can.

Many modern operating systems gets patched often ;)

> 
> As usual, we don't want to see creative solutions popping in
> different devices. A common standard seems preferable. So, if a
> subset of the working group wants to work on the solution, we should
> be happy to let them do that.

Thank you.

Cheers, Jan