IETF Logo Mail Archive

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

Fred Baker <fredbaker.ietf@gmail.com> Sun, 03 February 2019 03:47 UTC

Return-Path: <fredbaker.ietf@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 67AFD130EF2; Sat, 2 Feb 2019 19:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6Wn_3dWmnt-I; Sat, 2 Feb 2019 19:47:32 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 585471295D8; Sat, 2 Feb 2019 19:47:32 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id q1so5207103pfi.5; Sat, 02 Feb 2019 19:47:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0HuYjuS8oKLDgFcAJHnx62jexoVFEDK1gJRMP6APpko=; b=iPtWQRe704b+KC5dI+ACWbqAg1Ubh2ey80gy4bPa5H2QnufKhteZT4zJl45NpX+1Xh RMC688yCTbuFgnUzy4qVaRaUbF37wa8LdlT+k/Gw0ADa9W/WXHz5SoxpClw/zpDnr9pO K6NE5F2xBEs1rGraNvGW0ouSmWHaChtBuaNsGqQOEF9h35dVJE/dvyqhF84J2/Gr+joY 9n0GNGnfhjHX4TmzPA9ac4vzMBTKobgabiPpCLKEsQ8+DAnnLWROnGuOevtShLoDopox v5A3UB3h8RWFZXMdCkQm+jmnEiY0c/aNT28YyI6x0RsL4wrkHKniq1VgyO4kphDVkAJT UAyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0HuYjuS8oKLDgFcAJHnx62jexoVFEDK1gJRMP6APpko=; b=JLst759An3j2p8+TbN4sWg2OXjtdDg4XO3tcAIRvKS/ix6QSxMeSR42v2cuoCsCJji DaYTZbFx1YEFMIfbWVZy7nLtIHPRp3sGmOVHrioK8YWQrsfLoxVkd9TDrIeeMQdzh4ff 7/1hC3MLuPRG+YSwG637Q0lEg6baDrujNLSJ/2biGlmV9jPqWRARj4t3y3ZlNk1YJCkL ohi/rdd+WVpPOnW4fgnK+MpvrbHPXkGsahMXnvA/kVE8PDqGdyhkeBUXR+S5G2+dN5qC 7XoVKMezLzFP8PeIA20dHkKZc3Sdh7/XiUXtGpOF6ZfrP379kYaP5wMUWWfx+m4cjtkw k3jw==
X-Gm-Message-State: AHQUAuZKh6jQrnYrSMk6pRIS7EE+2JuOvP42H7u2eJxl3orougM0ZAMe eBz6K6k+tpdTYIDb9FYZ8VWvyOWF
X-Google-Smtp-Source: AHgI3IbpPqXv8uyt1aPkgYt+qaZtRnb3KH6r01Q8rlC0pFW7UpxPDeg39iDlOAMF4Gu7nMVKjoH/fQ==
X-Received: by 2002:a63:b105:: with SMTP id r5mr8284887pgf.442.1549165651719; Sat, 02 Feb 2019 19:47:31 -0800 (PST)
Received: from ?IPv6:2600:8801:d000:14a4:60ff:d5a1:a297:23b7? ([2600:8801:d000:14a4:60ff:d5a1:a297:23b7]) by smtp.gmail.com with ESMTPSA id a195sm25612638pfa.7.2019.02.02.19.47.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Feb 2019 19:47:30 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Fred Baker <fredbaker.ietf@gmail.com>
X-Mailer: iPhone Mail (16E5181f)
In-Reply-To: <alpine.DEB.2.20.1902011942460.23912@uplift.swm.pp.se>
Date: Sat, 02 Feb 2019 19:47:28 -0800
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>, ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AEA3935-F25D-4F5E-BB7A-88693DB5362F@gmail.com>
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>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wpfCu5Sk-l797ybwhsOnXbq5bgk>
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: Sun, 03 Feb 2019 03:47:34 -0000

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

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

v2.23.0 | Report a Bug | By Email