Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Trevor Warwick <twarwick@gmail.com> Thu, 24 October 2019 09:59 UTC

Return-Path: <twarwick@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8718712086B for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 02:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 vNrHhXyBPpmP for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 02:59:30 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 234A1120862 for <v6ops@ietf.org>; Thu, 24 Oct 2019 02:59:30 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id u16so18618713lfq.3 for <v6ops@ietf.org>; Thu, 24 Oct 2019 02:59:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=l/QVgQBdalqKllZPne8fXdv2uDcf4B9GRVmGkV9Tw8Q=; b=Q0wLzwzVvGxtrO0UAQ4YHXDoG14IjPJvu3rp7IOhWnyQJ831a7izA7jGWR68THjzm1 LRVjdnFo4WJ+u3C7VBNRTfzMOoWNiiRtQeWx9jTAnIttXX2wHgtRElRJyGU22wac+hAL G0SXOPn3o17p4TEHNkdp4JFLdewgBYPZaZtUwykJuUAeYVrX7obs+14yFhTJCAUfpZBf x9GD/ygJZCCGky/5np93ASKwejVMJS5b+cpzK7xD4uJHMQf/nqsoU0Wzcjvbl//OrIrD 9gioOX/deg1mwxk1QYCrYDbOFS4/HRaTPofK+2tFaTy/k5LiFQKbgFNUEtspZ4YtKpvf 2AVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=l/QVgQBdalqKllZPne8fXdv2uDcf4B9GRVmGkV9Tw8Q=; b=PzVZb8K670MsSRU7oGFgce456LB9fv1xES52sexp5M6V9zZSAtLDmt42nkaRnw+Bcj Az/9H0ReLM5e2PCuphSKoEwd8y9Z9HQBR2ytQtlhJ0R9VcbAA4+HwRkS1eL8iCGxJdTw xwo9rbntuSZrP4UIWZN+AjFpsAua2YNKBZm8CtdKHSpBGJxfTAxe4HbP+IjhPkRQ8OgB i6CrJb0ZJWKwbCksDvyTmsQEj/E/GsqVbxJMyAj87+p9pKcXiqalTSrBUNmlxE2KbULQ oEXSsOuzUueRO1LkxxtMn6gBHSR1Euom7i2l0UO7wtauSyw42P9kYg0L0v2kpoYSu706 w0bg==
X-Gm-Message-State: APjAAAVig7MAnamsiRDk+ToZUSHEXT08kKBLtjUDyHtE9LB50/+USR8A Rcdz0gx1tnWGXdEI9RQrxq/M6AdlmZK3p2uxry6oCQ==
X-Google-Smtp-Source: APXvYqzRczuPK5hHRPNSnH7BcBLHfrQC414Erz4k9DSQsrtCXyir8E8cT3EUWWVv0f8UqZKj7IlvnaN6QLIxn4XE+E8=
X-Received: by 2002:a19:ee15:: with SMTP id g21mr17657556lfb.27.1571911168009; Thu, 24 Oct 2019 02:59:28 -0700 (PDT)
MIME-Version: 1.0
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com> <CAO42Z2x7vudujw5t++obry56g=VNjQXXTHFK8pBPk0jmk78Bcg@mail.gmail.com>
In-Reply-To: <CAO42Z2x7vudujw5t++obry56g=VNjQXXTHFK8pBPk0jmk78Bcg@mail.gmail.com>
From: Trevor Warwick <twarwick@gmail.com>
Date: Thu, 24 Oct 2019 10:57:26 +0100
Message-ID: <CAJoHkZ8pTjszP0vw4BjX0HUhmPa6wJONzdy2JEm5iqAfBUvjRg@mail.gmail.com>
To: v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c9b3790595a51632"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/fM1PyRH0nG_G7caNlxR3WMvgKMU>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2019 09:59:32 -0000

On Thu, 24 Oct 2019 at 09:18, Mark Smith <markzzzsmith@gmail.com> wrote:

>
>
> I thought about this in the exact context of the scenario of this draft.
> Although the design of the broadband deployment I worked on always planned
> to give out stable prefixes, I worked through this scenario and realised
> that so many complex issues disappear if you provide stable prefixes.
>
> Fundamentally, if an ISP is selling an always on link to the same
> location, then the addressing should be as permanent as the link delivery
> location is.
>
>
If you're an ISP today, and using DHCPv6-PD to hand out IPv6 prefixes, what
are the possible scenarios if you don't try hard to keep the prefixes
stable?

- You could be running a closed environment where all customers are forced
to use your CPE, in which case you can make sure that your CPE has various
 hacks added to try to cope with prefix instability and avoid customer
hosts experiencing connectivity issues when prefixes change. Maybe you can
make this work well enough, and advanced customers who don't want to use
your CPE are just out of luck.

- If you're in an environment where customers can chose their own CPE, then
it seems almost guaranteed that there will be connectivity problems when
the prefix changes, because many CPE implementations don't handle this
situation at all. So you're then relying on hosts falling back seamlessly
to IPv4, in order to continue to have connectivity. In which case, I'd
wonder why you're bothering to provide an IPv6 service in the first place.

I do think this is an important problem that needs to be solved, for this
context and the others mentioned in the draft.