IETF Logo Mail Archive

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

Richard Patterson <richard@helix.net.nz> Wed, 13 February 2019 15:00 UTC

Return-Path: <richard@helix.net.nz>
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 390431274D0 for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 07:00:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.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 9UkQf_HKALa5 for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 07:00:13 -0800 (PST)
Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 D116812867A for <ipv6@ietf.org>; Wed, 13 Feb 2019 07:00:12 -0800 (PST)
Received: by mail-yw1-xc36.google.com with SMTP id p17so1007188ywg.0 for <ipv6@ietf.org>; Wed, 13 Feb 2019 07:00:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Zn+nr9gS9PuLDxojgk563nUVkZKhE5HDZPAxnOgfmbE=; b=iS230R/GCItjU5n0ptHNFGJOhzEWTb21huTlUMFeb6M8qavfrz2GzyQo0XxJT7M/jO Ng+kIqJ79eKpbHLUdVY0gtRsy1gtP9Kva5Ehv9I0H5GQLvG1gCC+kMqVWMZ2lRrqwtZg kPu+pKCqVjOHgq3W9NqC1uuhD8CBjr/hCqvIrxP+vsrZbUhcSHDuawRAJUAi4xKo5qRu CBYuAzq65KqCXyeaSRBNNU694NOh742JF8w6JNxidG4xwuqhjwf3xdIzoLPvSXfSbOHt 5a/rNHj6K/DJM8qejpUh5VHMnG5P3NSCNDYwuuHelP1LGXwQCidEmgfooMAQGK/D7c+J Pevw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Zn+nr9gS9PuLDxojgk563nUVkZKhE5HDZPAxnOgfmbE=; b=OH9hw8DjoWwvpw5iYCbHuAw47z3rmugwfOuVs33XRInX9Kbl/7YAEhEqObtCV1xQ8+ Yc/YFKlzUsYPLP7c77ixlIheZp+xbZYvOQOSsjEevrDTUJsvu/w3TwsX8jFxWhqXQ4RR SHAQUHfj8rKg5seI3hrCEAQBRIlhOlRA2H/ov9EjDlruu7bHmVU/PQ6xvkU8SBtA0mAN bvoeLhgPtW9XVomsYwCmm4xQvCWYLEprpOeRVTkr3i8nKKQa9j3xKGw3U+W0T/vqrxrV 9hGLBYhi5OnBGfRUwbEYBrZu+aepDcaYWm8+1/KfqVuVjw9M2/GQt963Nyf15pSZbGhZ KRiQ==
X-Gm-Message-State: AHQUAuaA3BlJZbVtMUjC+N/tQ4rGKZugmOjfEvZ7WlXbGSVRlbs8rnQO EXvt4cUJLthPja8YtsXkU3GSsJ391/E=
X-Google-Smtp-Source: AHgI3IYgUv8j+t++yPXtnZ0msqRSUM4z2+SDOUGjQDTLJfqJ6aMywkJf8ouZypK0ZXMd6OYBzx2dyA==
X-Received: by 2002:a81:b185:: with SMTP id p127mr5013291ywh.158.1550070011306; Wed, 13 Feb 2019 07:00:11 -0800 (PST)
Received: from mail-yw1-f51.google.com (mail-yw1-f51.google.com. [209.85.161.51]) by smtp.gmail.com with ESMTPSA id h205sm853541ywh.85.2019.02.13.07.00.10 for <ipv6@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 07:00:10 -0800 (PST)
Received: by mail-yw1-f51.google.com with SMTP id q128so984650ywg.8 for <ipv6@ietf.org>; Wed, 13 Feb 2019 07:00:10 -0800 (PST)
X-Received: by 2002:a81:ee07:: with SMTP id l7mr4952518ywm.489.1550070009965; Wed, 13 Feb 2019 07:00:09 -0800 (PST)
MIME-Version: 1.0
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> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <77ecf321-b46e-4f25-7f68-05b15714a99e@si6networks.com> <CAHL_VyDdHuEAc9UdeiRp9f+c0tdzyoLwPY1rJbZmbWAuq96Uuw@mail.gmail.com> <alpine.DEB.2.20.1902051127510.23912@uplift.swm.pp.se> <7a401098-ef51-86d4-064b-056e061a4472@gmail.com>
In-Reply-To: <7a401098-ef51-86d4-064b-056e061a4472@gmail.com>
From: Richard Patterson <richard@helix.net.nz>
Date: Wed, 13 Feb 2019 14:59:58 +0000
X-Gmail-Original-Message-ID: <CAHL_VyDACS172yQoSiz7s+FvrQWchesGXNx73FkA2T057q0YPQ@mail.gmail.com>
Message-ID: <CAHL_VyDACS172yQoSiz7s+FvrQWchesGXNx73FkA2T057q0YPQ@mail.gmail.com>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, Fernando Gont <fgont@si6networks.com>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6XD2sRdKXu8S5V9s-0E0FjOOavM>
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: Wed, 13 Feb 2019 15:00:15 -0000

On Wed, 13 Feb 2019 at 14:50, Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:

> Le 05/02/2019 à 11:31, Mikael Abrahamsson a écrit :
> > On Tue, 5 Feb 2019, Richard Patterson wrote:
> [...]
> > If the device has permanent storage then it could ask for the previous
> > PD it had,
>
> Yes, it could be done with a DHCPv6 message called 'CONFIRM' - it's sent
> by the Client to the Server, and it 'confirms' the intention to use an
> address that was allocated earlier.  It was specified for when like
> waking up from standby mode.  It's specified for allocating Addresses,
> so it would work the same when specified for prefixes.
>
> Alex

It could also just include it as a hint in the first SOLICIT.

Storing the old lease to persistent storage also gives the CPE
visibility if the prefix does change.  If it does, it can then send
RAs with lifetime 0 to deprecate the old prefix on the LAN side.  This
seems to have resolve all of the issues for us, as far as we can tell.

-Rich

v2.23.0 | Report a Bug | By Email