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

Christian Huitema <huitema@huitema.net> Tue, 05 February 2019 22:10 UTC

Return-Path: <huitema@huitema.net>
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 B5551131249 for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 14:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 u6Jon6Zy653y for <ipv6@ietfa.amsl.com>; Tue, 5 Feb 2019 14:10:16 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 DDE8A1310CB for <ipv6@ietf.org>; Tue, 5 Feb 2019 14:10:15 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gr8uw-0005pi-UL for ipv6@ietf.org; Tue, 05 Feb 2019 23:10:12 +0100
Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gr8ur-0003VH-5b for ipv6@ietf.org; Tue, 05 Feb 2019 17:10:07 -0500
Received: (qmail 30474 invoked from network); 5 Feb 2019 22:10:04 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ipv6@ietf.org>; 5 Feb 2019 22:10:03 -0000
To: Lee Howard <lee@asgard.org>, 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> <m1gqyJC-0000FkC@stereo.hq.phicoh.net> <CAO42Z2wKh-vXmv=dNmr6oEmGnw09ajrr2geYJ=H1DbSYSm=VuQ@mail.gmail.com> <m1gqzYT-0000F5C@stereo.hq.phicoh.net> <e8eabf0f-191a-a293-8051-35268a62a2bd@go6.si> <37ae87fb-93f5-4ec4-6e55-e35ce308f91c@asgard.org> <2aa19534-4856-f01d-8184-6c7ed125ca1b@go6.si> <9cdf8405-e777-6769-4d4f-f123c13a9456@asgard.org>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <f4eaaf13-aff3-439f-4426-d32d3722abfe@huitema.net>
Date: Tue, 05 Feb 2019 12:10:02 -1000
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: <9cdf8405-e777-6769-4d4f-f123c13a9456@asgard.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
X-Originating-IP: 168.144.250.232
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.21)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5iiX4DgTlajvHuuyDuhQy6R602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO0+c5LB5+AaOnyUGHzplYThs1ujulqUFmMITHM77eiViqufDzQuhIzbsKbEg2v7h887i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaK+j4RF6bTjkOxgQRV5+xFmP20HY6wg+I9tFZDQIEK2TQEli2DHjiri uL85r3TF5nmAImxrekFydH4DojSCKJXVXfdz0+Q1eHsqtFQKXUaZ+h596SWGosiQ15/fAFUBngWU swziTuoonQBgr0dS5AZLiwQzKw+6v3CaIMG6s7LqJFA2+ajytfCzORPDOH6X2/5SyaRgIwuFZktu hI3SFVknEkdz2J7OnLXx9jmOh8eUlNXOYVaaykPI8m1zqlpEBkvtOuTWXXIj0TpQpfUxR/zGwBdV FCAdssvNXtvdLBNmqz5Gegm2Di+XkC+U0gjMGGKSn11dj1tX732somwMviE4rNLMkKiSx4DbX99P +gh4iWPT5m4OdqWMdE0b4Joz08+J+cv73CChOPjKA0/DVd830vHLIFSGGMV7x6CHvZpJG/9P/4OG qJ5dkO1xTEy0joEwyGTHIAoNFX+jcW7DGmdEezpuI9IICsCKA/p66v7fhw==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/q53XgOyM1mkp8UDBY90EYeaiqCw>
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: Tue, 05 Feb 2019 22:10:18 -0000

On 2/5/2019 11:46 AM, Lee Howard wrote:

>
> And yet when somebody says "I built my network for reasons that were
> compelling to me at the time" you tell them they did it wrong. It's
> tiresome. 


+1. I am always amazed at how long threads can become on the IPv6
mailing list. It seems that the problem is rather simple:

1) For some reason, the router gets reconnected, and the new connection
comes with a different IPv6 prefix.

2) At that point, all IPv6 addresses allocated to hosts on the network
become stale, and may remain so for some potentially long time.

3) We want to transition rapidly to a new state in which hosts acquire
addresses based on the new prefix and can communicate again.

Lots of the discussion centers on denial. "Don't worry about that, the
router's prefix should not change." Really? There are tons of scenarios
in which stuff happens, such as for example a router dialing up a back
up cellular connection if the land line connection broke. Or the various
events in which the back-haul network configuration changes. These
events are obviously painful, as all existing TCP connections are going
to break. The providers probably strive to make them rare, because
inflicting pain on customers is not a great business plan. But rare does
not mean "never". Denying that is going to cause tons of frustration.

-- Christian Huitema