IETF Logo Mail Archive

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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sun, 03 February 2019 19:45 UTC

Return-Path: <prvs=19377bc400=jordi.palet@consulintel.es>
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 23D7212E036; Sun, 3 Feb 2019 11:45:57 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 1BX0BCR6ZCoQ; Sun, 3 Feb 2019 11:45:55 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FE5127598; Sun, 3 Feb 2019 11:45:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1549223152; x=1549827952; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=S69rl7h6AKT3Afyw01CyZAzlbQcURyMRxXXjEf1h8pE=; b=iXnN7/NuAnmkY eciGDEl1IpKr1nq/ZHCqwo9JTYlkW143F1sSL46IDhnnvmrwWUIfVjj/rNDimCSr n9Vg0VwhOCohqFWS0P10vi+iEXVTXf3FCd47EUz6IguGxb+JYlRo9pwXGpeH98Q6 O7xYQQXh9803SBzrQSa28oBEErIrtY=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sun, 03 Feb 2019 20:45:52 +0100
X-Spam-Processed: mail.consulintel.es, Sun, 03 Feb 2019 20:45:52 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006140166.msg; Sun, 03 Feb 2019 20:45:52 +0100
X-MDRemoteIP: 2001:470:1f09:495:ec7e:caa4:9d9e:92d6
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Sun, 03 Feb 2019 20:45:52 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=19377bc400=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.6.190114
Date: Sun, 03 Feb 2019 20:45:47 +0100
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Message-ID: <A0201A4B-77BB-40F4-A35F-F1491732D537@consulintel.es>
Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios
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> <ac773bb5-0da8-064b-d46b-3a218b8c9e7a@si6networks.com> <CFAEACC4-BA78-4DF9-AD8A-3EB0790B8000@employees.org> <a4f6742e-f18e-3384-d4cc-06bfab49101f@si6networks.com> <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org> <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com> <A40C5116-9474-4F2B-BD94-F57D155ECD4C@employees.org> <b05e3872-d63b-108c-6c00-21b951dad263@si6networks.com> <A9FBBED3-A858-4BB1-A02A-2A06CBEB7662@consulintel.es> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com>
In-Reply-To: <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6HftlYU0KyF52qgyfQguI7veySE>
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 19:45:57 -0000

Agree. Just wanted to clarify that assertion, as I've heard it too many times.

AVM/Fritzbox, if I recall correctly is one of the very very very few vendors that write the prefix in the flash ...

Regards,
Jordi
 
 

-----Mensaje original-----
De: Brian E Carpenter <brian.e.carpenter@gmail.com>
Fecha: domingo, 3 de febrero de 2019, 20:41
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
CC: "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Asunto: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

    On 2019-02-04 06:46, JORDI PALET MARTINEZ wrote:
    >     The RIPE document does not recommend it. In Germany, that's the expected
    >     default.
    >     
    > ---->  This is not correct, in the context of another mailing list, a few day ago, some people (including people from Germany) confirmed that this is not true for Germany, neither there is any law or anything similar that requires dynamic prefixes.
    
    It doesn't matter. The objective fact is that getting a new prefix after a CPE reboot, or after a DSL disconnect/reconnect, or every 24 hours, is common, and not just in Germany.
    
    Not that I've ever had any stale address problems as a result, even at a time when I was getting multiple ADSL disconnects per day due to a line fault. So with a FritzBox and Windows hosts, the "common problem" simply wasn't a problem.
    
       Brian
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

v2.23.0 | Report a Bug | By Email