6renum alive again? [A common problem with SLAAC in "renumbering" scenarios]

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 20 February 2019 04:02 UTC

Return-Path: <brian.e.carpenter@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 62380130D7A for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 20:02:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 FcOk3u5EoWDy for <ipv6@ietfa.amsl.com>; Tue, 19 Feb 2019 20:02:28 -0800 (PST)
Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 8030E12F1A6 for <ipv6@ietf.org>; Tue, 19 Feb 2019 20:02:28 -0800 (PST)
Received: by mail-pl1-x643.google.com with SMTP id 101so11503422pld.6 for <ipv6@ietf.org>; Tue, 19 Feb 2019 20:02:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ebk1XEps1u6zxsUkKtxl6Nw/3lTIUNnYwJywmTzxgi0=; b=npUYSoTvwtX2/rlRKX08QJ7D6Gg0NwFFI+nFWz/ythfWjk6O5n2CvPdSC33z2dkKO1 WTB3wfkSS6JGrjG6ns8YG74uqLXL5eC7h+Rx7l4GHyfHnnRqPG3B+tGQKz+r6W74Q+qM aeW07eOlr+JNTMOUcoo82rh1LtXErbmgymG7DfweX3a7UvdqSegaWihaatLqi4KAK9v1 haXeAeIJCUclK12tgJKtIHOx+dhFqZNUpfSFPQ6FSjUWT31k4etVeS5sAOJ0OUxP/ZO0 z2IzpzM5Jug+r5AlSsBzFuy2QbXGhdRT0WIps9tN8sUzEavGQ2ekd/+rt9/kJ6nxF4rt 6wmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ebk1XEps1u6zxsUkKtxl6Nw/3lTIUNnYwJywmTzxgi0=; b=PLG9yCVuuIkAZ0z0Js6X2sxuFa3keIas1Ap/qihQVQhd/XvA1nL6O3eyETcFZPvTAR 5ByH7UQmqRJbDgrROgJT3htOSu6s9aa9FdHwt8XY2Wpca3XTuKLFMrQqV0cjaIYbBwIk ohzd1SoOWhXMyHcj/j8ubxpBgHtJZAFYGMWBnRkph/yjMCDWdVUQdbbS1pMXW1bGGec+ bbWCFcp8QBO8R0LnbmqcmFT6u7f97jg6gFEvMzhn8FWybKBp+ujTBP4Cls/0VSaXNxPi +wiEZ0rrsohCXRESr+ZNromp96FdM+q9SQlrRl2+UFAcaUwSwt2HTiW+r7LKG5A/QZ7p clvA==
X-Gm-Message-State: AHQUAuYOkVdEdHOKWrUdubVAzRZD8bJBAnjNb/1jI8JnXQM217cH1ipM 7nYAE3rsKuZXnUN9JB/oUhZRfSQl
X-Google-Smtp-Source: AHgI3IZbmbZxFL5mHZsciTiLHTBl44Sho0lmV4CCmE+EyLnXRpS7ALAzzlSsi0xTwiTfZXo04W5HTQ==
X-Received: by 2002:a17:902:aa01:: with SMTP id be1mr34317114plb.60.1550635347259; Tue, 19 Feb 2019 20:02:27 -0800 (PST)
Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id e63sm32458663pfc.47.2019.02.19.20.02.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 20:02:26 -0800 (PST)
Subject: 6renum alive again? [A common problem with SLAAC in "renumbering" scenarios]
To: Ole Troan <otroan@employees.org>, Fernando Gont <fgont@si6networks.com>
Cc: 6man WG <ipv6@ietf.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <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> <12EA4FAE-BE3D-4CFE-9837-DF052F79A998@employees.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <3f38c28b-76c5-6f07-c271-777f1374737a@gmail.com>
Date: Wed, 20 Feb 2019 17:02:20 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <12EA4FAE-BE3D-4CFE-9837-DF052F79A998@employees.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/df4sTXdqDxghefp1DsM2hWn24Hc>
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 04:02:32 -0000

Maybe everybody could read up on previous rounds of discussion:

https://tools.ietf.org/html/rfc4192
https://tools.ietf.org/html/rfc5887
https://tools.ietf.org/html/rfc6866
https://tools.ietf.org/html/rfc6879
https://tools.ietf.org/html/rfc7010
(In that last one, the section "Gaps Considered Unsolvable"
might be of interest.)

Yes, the topic was site renumbering, not host renumbering. But
the assumption has always been that renumbering should be a routine
event in IPv6. (Those of us who had to manage IPv4 site renumberings,
especially before the advent of DHCP, have always been sensitive on
this topic.) Thus, hosts need to be ready for renumbering at any time,
without notice.

Better I think to focus on Fernando's specific issue.

Regards
   Brian Carpenter

On 2019-02-20 16:11, Ole Troan wrote:
> 
> 
>> 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
>>
>>
>>
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>