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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 February 2019 02:54 UTC

Return-Path: <mcr@sandelman.ca>
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 99504131006 for <ipv6@ietfa.amsl.com>; Wed, 6 Feb 2019 18:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 QOYbr3MEo3aD for <ipv6@ietfa.amsl.com>; Wed, 6 Feb 2019 18:54:44 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83112128BCC for <ipv6@ietf.org>; Wed, 6 Feb 2019 18:54:44 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [209.226.201.248]) by relay.sandelman.ca (Postfix) with ESMTPS id 43D331F8D5 for <ipv6@ietf.org>; Thu, 7 Feb 2019 02:54:43 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 4759F1BDB; Thu, 7 Feb 2019 03:53:52 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ipv6@ietf.org
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
In-reply-to: <81ab4307-efb8-c04e-7acb-a6f7f0ec839f@gmail.com>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <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> <f4eaaf13-aff3-439f-4426-d32d3722abfe@huitema.net> <d714d577-74f8-6f1a-76a7-94811b615078@foobar.org> <81ab4307-e fb8-c04e-7acb-a6f7f0ec839f@gmail.com>
Comments: In-reply-to Brian E Carpenter <brian.e.carpenter@gmail.com> message dated "Thu, 07 Feb 2019 08:31:05 +1300."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 07 Feb 2019 03:53:52 +0100
Message-ID: <9711.1549508032@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6x0UNDgsZ712J7lgT4ehxA8PmME>
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: Thu, 07 Feb 2019 02:54:47 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >> The choices seem to be:
    >> 
    >> 1) ensuring that if a device is disconnected and then reconnects to
    >> the same network, the device will be given the same lease,

    > In the general case we can't "ensure" that. Firstly it may be against
    > business policy or privacy policy for some ISPs. Secondly even if it
    > was the intended policy, there can always be failure
    > scenarios.

Yes, but we know how to planned renumbering.

And, if we can get the prefix written to stable storage (as has been pointed
out, it only needs to be written when it actually changes), then we can deal
with the problem.

The only other thing that I can think of is to create a new option which is
something like "previous prefix"... or maybe "obsolete prefixes"

ISPs that
     a) control the CPE devices,
     b) want to use devices with no stable storage,
     c) also want to do flash renumbering
     d) and don't want to use really short lifeimes
can implement such a thing.

    > Thirdly, a host might be disconnected from one LAN and
    > reconnected to another one without knowing it. So even if this is the
    > recommended practice, no host can rely on it.

Yeah, but users mostly understand that this breaks things already.
Maybe this happens in WIFI more frequently than desired without user
intention, but in that case, both networks involved are probably pretty
fragile already.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [