[v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds))

Mark Smith <markzzzsmith@gmail.com> Tue, 12 November 2019 00:34 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 289D21200B6 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 16:34:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Status: No, score=-0.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xk2xFfyTnmW1 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 16:34:16 -0800 (PST)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 26E3912003F for <v6ops@ietf.org>; Mon, 11 Nov 2019 16:34:16 -0800 (PST)
Received: by mail-ot1-x32b.google.com with SMTP id u13so12863101ote.0 for <v6ops@ietf.org>; Mon, 11 Nov 2019 16:34:16 -0800 (PST)
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 :cc; bh=45qP3lJNlCsjNyx7CzRzZWDe/LIb1xI6nhHbVwlwSgo=; b=mFnqq55IKTQXI9Pd/HCzfxdvqUThNSTifbUzhpbyEwbBEuNSdg3xWLgURIrQeweg+3 Y1wYE8wEEKOLKX/JwkIZfIVQygQ1f8QW1wELpqBn8u3NG6EuYbGr3CLHlfsmXBKpAw7Q W2Zp/a7YI4BOA1L2+PDuZfOSJsZ1f0UY1WeHyeQr0xpaJIKyvHA6w1TrF6m6RiTmAKE0 5JGUrnyCjk+2BkiMoSNcL6CW1uLbkaOqmigxD8l35+RASS1NQ6XGNtf09J74JfIQweT5 PnIYetamPUzWfdoaNKYiEkhKqRYSmIjLImtqyWBxcIP7pOJ6QToh9qB+xV7gaPDN5yiO P3YA==
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:cc; bh=45qP3lJNlCsjNyx7CzRzZWDe/LIb1xI6nhHbVwlwSgo=; b=aRWg92wvUIj4XY928WaCjyGAw+D7GRsgAqbjbmS4CLd50za5JGlN3prBynF7FqKdHH NdLN5fMPkAaKXsdJL09Wcf+JNv5q6BUFYBnX1a8R12k0E0D20u1/j1+dgSHsLFrFJwf4 3y1kDHVJf3p9KUXCewLprfK/kbBP0dtq54dx1KnobjaH+V5TL1mBmf7CLE3bPJyFseNW CV2wA8Ne8dO+Cgi7MSldQXmBiRgw9p779N1BtLa/cjdmabkb5Lji8uo8OBtX5x+4MoFO BiisDcMC3l3OTVZ58CbzYbBpU+Xw96sxdjxkfQ8Z5qu66xWl2ncs7tUoIIkzAjz/2Z1c 7yGg==
X-Gm-Message-State: APjAAAVsKyaFB2lXeAVA4XKBTEY3XCcdycFibl9IXOldY/v3ZyDEU4cb O3ePaQJrDpgnSiXbu4DgqOZNmV1+Drsxfi7hf2o0XUhm
X-Google-Smtp-Source: APXvYqwyBohPSWwUib6739QmsNt0JKwwlHtjTUBfeU5tKK6dSqlZzIfaiHoeguMG2H8TnZFBn6MDL2LHSBTTViHYWoc=
X-Received: by 2002:a9d:611c:: with SMTP id i28mr21883890otj.348.1573518855284; Mon, 11 Nov 2019 16:34:15 -0800 (PST)
MIME-Version: 1.0
References: <CAHL_VyBC3NbT4b-mnacU+ZmzyXus4HXcKx9ykdWJ3_a2uJCi4g@mail.gmail.com> <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <CAO42Z2zWTediRkaF_pfot_QT9Hsf5Wdu9_77BQZjEEG5wY1jdQ@mail.gmail.com> <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com>
In-Reply-To: <5a479b19-bf77-4c06-123f-87ed67fb5e09@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 12 Nov 2019 11:33:48 +1100
Message-ID: <CAO42Z2zTBXCA7HVBYfXsZFC91-Ac5h6m4fAvgBFPHz8xTfNZTA@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Ted Lemon <mellon@fugue.com>, v6ops list <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/yFhse8auoahKnTcmgXk_Iwis6Kw>
Subject: [v6ops] What problem are we trying to solve? (Re: A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: 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: Tue, 12 Nov 2019 00:34:18 -0000

On Tue, 12 Nov 2019 at 10:38, Fernando Gont <fgont@si6networks.com> wrote:


> > I don't really understand what is so hard about all this.
> >
> > You either provide prefix stability using a client's DUID, or you can
> > use RADIUS.
> As noted elsewhere, we have an RFC for DUID radnomization ("dhcp
> anynimity profile", iirc). Besides, it's also understandable the
> possible expectation of a user to get a new prefix upon CPE reboot (due
> to privacy considerations).

The trouble with this discussion is that it still hasn't defined the
problem properly. Different people have different scenarios in mind,
and then scenarios are sometimes changed to suit an argument.

What are the specific design requirements?

Is the fundamental goal a stable prefix or not?

To suit commonly deployed transport layer protocols' requirements,
address stability is needed so that connections can survive transient
connectivity faults - which is what a CPE reboot is, or what a BRAS
reboot is.

On the other hand, the privacy argument says that an unstable prefix
is optimal, with as unstable as possible the most optimal. Addresses
used by transport layer protocols should only last as long as the
transport layer protocol connection using the address and no longer -
basically "Transient Addressing for Related Processes: Improved
Firewalling by Using IPV6 and Multiple Addresses per Host" -

Are we trying to address a fault situation, or an intentional,
non-fault action to achieve some other goal (CPE reboot to acquire new
prefix for privacy)?

Is the "flash" renumber event a very rare event that an ISP does as a
last resort during troubleshooting, despite them having infrastructure
to support providing stable prefixes (i.e. RADIUS/DUID above)? Say
occurring no more than once every 2 years, ideally no more than once
every 5, and ideally never.

Is the "flash" renumber event a reasonably rare event that coincides
with an occasional BRAS/BNG reboot that causes customers to land on a
different BRAS/BNG with a different PD pool, and the ISP hasn't gone
to the effort of putting in stable prefix infrastructure? Say
occurring no more than once every six months (that was my minimum up
time expectation for a production BRAS/BNG).

Is the "flash" renumber event a reasonably rare event triggered by a
customer who wants a stable prefix for as long as they're comfortable
with the privacy they have, and will actively trigger a prefix change
when they consider they need to "reinitialise" their privacy with a
different prefix? Say once every month or two.

Is the "flash" renumber event a fairly common event because ISPs don't
want to provide stable prefix infrastructure, because they've divided
the their customers into two classes - "clients only" and a higher
paying, typically SOHO/SME premium "full service" (client, and
server/service if desired - i.e. peer) class. Say, once every week or
two for "client only" residential customers.

Until requirements are locked down, we can never know if you've
achieved them or not, and the discussion goes in never ending circles
- as it is.

All of the above are impossible to achieve at once because there are
unresolveable conflicts.

For example, for an ISP that provides a stable prefix, how can they
know that a CPE reboot is intentional to get a different prefix for
privacy? It could also be because of a mains power failure, or a CPE
reboot due to a bug.