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

Ole Troan <otroan@employees.org> Wed, 20 February 2019 03:11 UTC

Return-Path: <otroan@employees.org>
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 998EA12D84C for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 19:11:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 kaSDbG2F3s1k for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 19:11:25 -0800 (PST)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE95129619 for <ipv6@ietf.org>; Tue, 19 Feb 2019 19:11:24 -0800 (PST)
Received: from [192.168.10.189] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 5123AFECBCD4; Wed, 20 Feb 2019 03:11:22 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
From: Ole Troan <otroan@employees.org>
X-Mailer: iPhone Mail (16D39)
In-Reply-To: <433607c1-dbc6-a42e-cb17-dc209e33bdaa@si6networks.com>
Date: Wed, 20 Feb 2019 04:11:19 +0100
Cc: Nick Hilliard <nick@foobar.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <12EA4FAE-BE3D-4CFE-9837-DF052F79A998@employees.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <2612280f-195a-ae7a-b3b1-9022d9282fa7@foobar.org> <56F813F4-C512-40A9-8A68-1090C76A80F6@consulintel.es> <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org> <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org> <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org> <433607c1-dbc6-a42e-cb17-dc209e33bdaa@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/RROcox2Py0B2GouP3GTiXZnmw-E>
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, 20 Feb 2019 03:11:28 -0000


> On 20 Feb 2019, at 03:50, Fernando Gont <fgont@si6networks.com> wrote:
> 
>> On 19/2/19 10:08, Ole Troan wrote:
>> Nick,
>> 
>>> On 19 Feb 2019, at 13:57, Nick Hilliard <nick@foobar.org> wrote:
>>> 
>>> Ole Troan wrote on 19/02/2019 12:22:
>>>> Indeed. Wonder how these pesky mobile phone operators manage to
>>>> deliver the same telephone number to a user, for years. Across
>>>> different providers and contracts.
>>>> I can’t think this argument is anything but a strawman.
>>> 
>>> Ole,
>>> 
>>> if recommending static IP addressing is an idea that 6man wants to push, you'll need to reach out to the security and ops areas to get their input on this.  I'm not sure this is an issue that 6man can resolve fully.
>> 
>> It’s been the IPv6 addressing model for at least 20 years, so I think the other areas have had ample time to provide their input.
> 
> For the reasons stated in draft-gont-6man-slaac-renum, I don't think
> this affects the discussion we are having. But, out of curiousity,
> where's the "addressing model" you are referring to documented?

I can’t see slaac-renum tackling these issues.Which reasons are you referring to?

With regards to the addressing model, your question shows a certain lack of history, but given that we all gave lived under the reigns of NAT for so long. Allow me to turn it around. How do you expect the network to work with addresses being of arbitrary lifetime (the effect of flash renumbering) and where is that described? Start with a long-lived TCP session, with the listening peer sitting in one of these networks. 

Ole


> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
>