IETF Logo Mail Archive

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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 13 February 2019 14:50 UTC

Return-Path: <alexandre.petrescu@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 6D31512867A for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 06:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 cTurQvpSYefe for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 06:50:42 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 A549A1274D0 for <ipv6@ietf.org>; Wed, 13 Feb 2019 06:50:42 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1DEodMP039120; Wed, 13 Feb 2019 15:50:39 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CAFBC200C37; Wed, 13 Feb 2019 15:50:39 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B7B61205853; Wed, 13 Feb 2019 15:50:39 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x1DEodAI000762; Wed, 13 Feb 2019 15:50:39 +0100
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Mikael Abrahamsson <swmike@swm.pp.se>, Richard Patterson <richard@helix.net.nz>
Cc: Fernando Gont <fgont@si6networks.com>, 6man WG <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> <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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <7a401098-ef51-86d4-064b-056e061a4472@gmail.com>
Date: Wed, 13 Feb 2019 15:50:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1902051127510.23912@uplift.swm.pp.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/nsdy4g3gImg5O8GnezQNllmllTo>
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 14:50:44 -0000


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

  and if that's free then it'd get it. So as discussed earlier
> in the thread, having the HGW just store the last PD it had could be 
> helpful even if it never updates it with information as long as it's the 
> same.
>

v2.23.0 | Report a Bug | By Email