IETF Logo Mail Archive

Re: A common problem with SLAAC in "renumbering" scenarios

Jan Zorz - Go6 <jan@go6.si> Mon, 04 February 2019 11:01 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 194821294D0 for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 03:01:39 -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, 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 72nwPjBxG1WE for <ipv6@ietfa.amsl.com>; Mon, 4 Feb 2019 03:01:34 -0800 (PST)
Received: from mx.go6lab.si (mx.go6lab.si [IPv6:2001:67c:27e4::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 3AE5112872C for <ipv6@ietf.org>; Mon, 4 Feb 2019 03:01:34 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.go6lab.si (Postfix) with ESMTP id 159C260749 for <ipv6@ietf.org>; Mon, 4 Feb 2019 12:01:32 +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 yy2mStsyRAiX for <ipv6@ietf.org>; Mon, 4 Feb 2019 12:01:13 +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 32121660BF for <ipv6@ietf.org>; Mon, 4 Feb 2019 12:01:13 +0100 (CET)
Received: from haktar.local (unknown [IPv6:2001:67c:27e4:5::19]) (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 65DEA809E6 for <ipv6@ietf.org>; Mon, 4 Feb 2019 12:01:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1549278072; bh=jQzA2RHSkZL83JFqlGYqFBPE46nQN+zuJ67aiiY3100=; h=Subject:To:References:From:Date:In-Reply-To:From; b=sQaZ3E7vV8J64y4WyYp8tLzw7EV+lVpkUxRj7u+umw8xOTNGy+jyCQqLAwuJVv3RP aSnd043Qt2WZyWEUhFAFtsAKYpXI9uHiTeuhQm9nWDKe5D4o0nWfijdRvTHTKjS+QL eUknKfNV+Gr5mBw3DvcTnermlD2R7t8eU4FIX9yE=
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: ipv6@ietf.org
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <alpine.DEB.2.20.1902011942460.23912@uplift.swm.pp.se> <5AEA3935-F25D-4F5E-BB7A-88693DB5362F@gmail.com>
From: Jan Zorz - Go6 <jan@go6.si>
Message-ID: <e8e0779e-6242-9c99-513d-46a9c636555c@go6.si>
Date: Mon, 04 Feb 2019 12:01:11 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <5AEA3935-F25D-4F5E-BB7A-88693DB5362F@gmail.com>
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/BK1Q1otinKxkx9GPDUaeTt9IFdM>
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, 04 Feb 2019 11:01:39 -0000

Dear Fred,

On 03/02/2019 04:47, Fred Baker wrote:
> It sounds to me like you needed manual intervention to fix things.
> Mere mortals need for it to sect that it was down and do the right
> thing, then detect that it was restored and address that...

I'm not sure that my grandmother would be able to do that, nor I'm 
convinced that many other average Internet users would be interested in 
all this hassle :)

Internet access is becoming a simple utility that people use, let's keep 
it that way...

Cheers, Jan

> 
> Sent using a machine that autocorrects in interesting ways...
> 
>> On Feb 1, 2019, at 11:02 AM, Mikael Abrahamsson <swmike@swm.pp.se>
>> wrote:
>> 
>>> On Thu, 31 Jan 2019, Fernando Gont wrote:
>>> 
>>> Question: How about making the update to the "Valid Lifetime" a
>>> SHOULD or MAY, instead?  Or, maybe, at least, set it to the
>>> current "Valid Lifetime"? Otherwise, with the default values for
>>> the "Valid Lifetime", the addresses might lie around for 1
>>> month....
>> 
>> I had a real life example today. I have OpenWrt 18.06.1 HGW. This
>> morning, I lost Internet access. After diagnosing I realised that
>> WAN was not working correctly, so I did "ifdown wan" and "ifdown
>> wan6", switched to my secondary provider (which I was still on
>> contract with but don't normally use) and then did "ifup" on both.
>> I received new IPv4 GUA and IPv6 GUA PD /56, which was then
>> announced on my br-lan. I then ran on that for 3-4 hours until my
>> regular provider had fixed their hardware problem. Then I did the
>> whole ifddown procedure, swapped WAN cable to normal ISP, and did
>> ifup again.
>> 
>> Now, I saw IPv6 IA_NA for the temp ISP /56 with a week lifetime on
>> wired LAN device so I was a bit worried this would cause long-time
>> problems, but the prefixes were deprecated and I couldn't find any
>> actual issues (source address selection worked properly). A few
>> hours later all these addresses were gone even from my purely wired
>> devices that hadn't seen any link down/up events.
>> 
>> So potentially RFC7084 style solves most problems together with
>> https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05
>> style WAN down/up detection for the IPoE deployment case (PPPoE
>> already have this).
>> 
>> OpenWrt since 15.05 has been very much aimed to be RFC7084
>> compatible so I would propose to investigate further what hosts
>> today actually do in reaction to RFC7084 signalling.
>> 
>> -- Mikael Abrahamsson    email: swmike@swm.pp.se
>> 
>> --------------------------------------------------------------------
>>
>> 
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>
>> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email