Re: [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))

Tassos Chatzithomaoglou <> Tue, 12 November 2019 07:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0492120170 for <>; Mon, 11 Nov 2019 23:11:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7UfDeBFIT4Pe for <>; Mon, 11 Nov 2019 23:11:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D00B51200A4 for <>; Mon, 11 Nov 2019 23:11:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B8743121BB6 for <>; Tue, 12 Nov 2019 09:11:44 +0200 (EET)
Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by (Postfix) with ESMTP id AC1B212188B; Tue, 12 Nov 2019 09:11:44 +0200 (EET)
X-DSPAM-Result: Innocent
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id fPpIlbbNGuw0; Tue, 12 Nov 2019 09:11:43 +0200 (EET)
Received: from localhost (localhost6.localdomain6 [IPv6:::1]) by (Postfix) with ESMTP id B300012188F; Tue, 12 Nov 2019 09:11:43 +0200 (EET)
DKIM-Filter: OpenDKIM Filter v2.9.2 B300012188F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=zm; t=1573542703; bh=16Y6fSaogdwNH142fsdvP4OQ4ShmhhEZgOYWbx/AKXQ=; h=Subject:From:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=65sdUYTwLFH6wPZEseUgImL3T03OqIyvqE+QNQe9si7VDOwo82Pv/g9938qZK+4Gc 8S7NJX7+zZCNUtdd+sBveEOJe1pOPJSkY7iyd8EQ7uQaOPQoV3tcvB8+wq/EsTOhrg BjBd8MVBE0PFL6uWPZTr4mErMx2uOPqbkCAw4xN4=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id k3mULUhFklGQ; Tue, 12 Nov 2019 09:11:43 +0200 (EET)
Received: from [IPv6:2a02:2149:8769:2d00:f9d1:946c:c61:6b44] (unknown [IPv6:2a02:2149:8769:2d00:f9d1:946c:c61:6b44]) by (Postfix) with ESMTPA id 875B612188C; Tue, 12 Nov 2019 09:11:43 +0200 (EET)
Cc: v6ops list <>
References: <> <> <> <> <>
From: Tassos Chatzithomaoglou <>
Openpgp: preference=signencrypt
Autocrypt:; keydata= mQENBFPWrY4BCADa9txOlMMGA1PvelU2qfkJ3cIoF+M9wXhSvZTI63FfgZAMWVM/NryJQ74q kiaWFyprgqo2BBk6vWkCw0N8pVwx0Z0sbPisB1fo/zB29cyM0HeB8lnu+Z5AvkfjwekMtGJd 3+tsRwOqdAJpCpJNhS0cVAkk1lIe3i8pdBbbKYJ5VNpBTyi0zL18WRvz9qf8nnP50rQOF8Oc LNCyKrT5S02SonWH5fQDTMVaSDVRvzRLU34pL0WEsIfTQciwg9LhjRpGj6mHxX1OdRHBpHmH WAI05lg7xRwYZq2/X/9Xizd0j9hbr6Ph7oiW7u6e4zAndvPSxXaBVCzpVI0hhaJl11yVABEB AAG0G1Rhc3NvcyA8Y2hhdGFzb3NAeWFob28uY29tPokBPwQTAQIAKQUCU9atjgIbIwUJCWYB gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG9JgN4loaV7D0kIAKfyVLWFzOfYM0uT m78iJsh9nAaxYiM0t40oF+HY7Cri35FDAzrRjbB0os/KehCz6uuBqDe+3swkVX9bwE9/GsHc Tb5C1IOdvgb2Rp3MfSF1+Ju/3uGtiktQIqZ5YrIZhIjGiwUCVC6ewpC3VRiFVo/HvE23p16y 6Ws9y4xoRNuxs0952twZjT9jwVub8TWm/uES6RERZ68FGA1jVFXtAgMXljP29KcL8zRw9xiY VNI1MgUIRhOKENzpChS+7jZSDWKKD9fwPUNDNPG9kNuXoinRX1g2wlgWKmaBNVBOZMunR20P eVewZ2v35uaiHyzzHw92vjjfxOtpXoW0QFlT5cg=
Message-ID: <>
Date: Tue, 12 Nov 2019 09:11:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.5
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [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-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Nov 2019 07:11:50 -0000

Mark Smith wrote on 12/11/19 02:33:
> On Tue, 12 Nov 2019 at 10:38, Fernando Gont <> wrote:
> <snip>
>>> 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.
> _______________________________________________
> v6ops mailing list

The subscriber should have the choice to decide and the technology should give the means to support his/her choices.
We're building a page inside our subscriber portal, where the subscriber chooses how frequently the LAN IPv6 assigned prefix should change.
Default is to change at every PPP reconnect, but the subscriber can choose specific periods (x weeks/months) or action (once at next reconnect).
SOHO/SME accounts do not have these options and have stable prefixes forever. Non-SOHO/SME accounts are not guaranteed to follow subscriber's choice due to network conditions.