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

Mark Smith <> Mon, 11 November 2019 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 231C21208C2 for <>; Mon, 11 Nov 2019 11:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U5t-GXorXuXb for <>; Mon, 11 Nov 2019 11:47:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA82B120105 for <>; Mon, 11 Nov 2019 11:47:33 -0800 (PST)
Received: by with SMTP id d5so12275441otp.4 for <>; Mon, 11 Nov 2019 11:47:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cKPdATfLqFxNKQceaHzy4L9j3FR8JdAEZvgVmWJpISQ=; b=g9FQ4scaR6a0OXqZJ6tSBA4sOsMtvaJ++KKmzMAN8CY71xI6hTZd2vAggGykh4A5/Q SQEpNyqNqD/4jvPBMKMfti7CoVuSxeetHjsPi50mZ3103Zp+PdLUQ8l10Et8AVmohM+r /4cmhLFa901Bp/e9uYZoOTyUkI/ETC4Je3he9E5O9Q6UQjBUoGczE+EzZxxpoiCym1iH hMPXswrXv9eefADIewHnufDdcmjXb8gH57h9+2CeO/Plea2RfQsHPXsP+sijQbax5Yv4 AX5ruSU3TRYTZpkHgZO7SOkP1YJRBVcQYtJBGFLbX4faFvm6+/9aJQq/sWMCUeqD+qdb 0b0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cKPdATfLqFxNKQceaHzy4L9j3FR8JdAEZvgVmWJpISQ=; b=TA4rAuguOpG2mHIdQAYzH49ePdjVcVdYdJtYcbI/Ba9D6/cRQY/qZkD0bYvjFyJ7Gf T8ag5FqSxes98dGjquQmucKwKdi8rljj3/HnxYeahGrtgLBD8ciFIf7xulN9C3LIDkhy C7ezPf5HJmdz7KHQPVcfrXplOzrVkX+bVXNKjk0BqNA8qaunus/gg4gWwMFANVGOseHU XrtKYD7HIRt8exziezxu2eDnS8X8e1mqGFZhcdzdR4OU95EZhcRMUtXixhHlhc3t4UsI frb8UzUguR9eDt2kU40ZmYZRSAl29p+BGU5xhYlamE4WUioD4Vg0hPsm4WT9pmSb/iTW i9mQ==
X-Gm-Message-State: APjAAAVn/iY0R0AunkzFBWsvGlqwJWl32MbAk0HiBD+KFvpQbdfqQF8T IRHaHFDG9bMf7wKgBAhter00j1tfp69uGOLzpgZ3Gw==
X-Google-Smtp-Source: APXvYqyh8ZQNaV+fvIJxycgwQsC0jwibARh0kzOEk2AbSrjbhpYnSVGl+yuBBMTMDG4WGIkcZv5XYXqULPUsF06Hrgc=
X-Received: by 2002:a05:6830:c2:: with SMTP id x2mr191110oto.257.1573501652984; Mon, 11 Nov 2019 11:47:32 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 12 Nov 2019 06:47:22 +1100
Message-ID: <>
To: Ted Lemon <>
Cc: Richard Patterson <>, v6ops list <>
Content-Type: multipart/alternative; boundary="0000000000001466e7059717676b"
Archived-At: <>
Subject: Re: [v6ops] 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: Mon, 11 Nov 2019 19:47:36 -0000

On Tue, 12 Nov 2019, 04:11 Ted Lemon, <> wrote:

> Nobody is expecting you to never renumber.   Well, at least I am not.

I'm not either.

IPv6's Preferred and Valid lifetime mechanisms are for planned renumbering.

What I am talking about here is deliberate, opportunistic renumbering. If
> your topology changes and you have to renumber, so be it.

Unplanned "flash" renumbering due to a topology change implies an unplanned
"flash" topology change. That's going to be a rare event, and ideally
shouldn't ever occur, because I think it is a sign that some other planning
hasn't been occurring.

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

Stable PD prefixes are similar to IPv4 RADIUS Framed-Routes.

IETF RADIUS attributes exist to provide IPv6 PD prefixes to BNGs that use
them with their local DHCPV6-PD server - see RFC 6911.

This is the method used on the IPv6 residential broadband project I worked
on in 2010, and I'm pretty confident it is still being used today, as I've
been a customer of it for the past 8 years.

If you can avoid that it’s better, and if you can give notice it’s also
> better. If you can do it gracefully with temporary routes, even better. But
> you shouldn’t be renumbering just ‘cuz.

> On Nov 11, 2019, at 11:21, Richard Patterson <> wrote:
> On Mon, 11 Nov 2019 at 11:02, Ted Lemon <> wrote:
>> The ISP has to install a DHCPv6 server in order to do an IPv6
>> deployment.  We’ve already heard from one of the main vendors of DHCPv6
>> servers that their server behaves correctly and does not do flash
>> renumbering.   The two DHCPv6 servers that I have worked on don’t either.
>> So why is the ISP going to have to delay?  The one time I was asked to help
>> an ISP to set up DHCPv6 in a way that would allow frequent renumbering, it
>> was a major engineering effort (which we wound up not doing).   The ISP
>> would have to go *out of their way* to not support stable prefixes.
> This is an oversimplification, ignoring the complexities introduced by
> various topology, architectural and indeed vendor decisions.
> i.e.
> - Centralised vs distributed DHCP server.
> Distributed helps scale but centralised is easier to manage.
> Centralised would require some topology-awareness to know where a
> subscriber is to be numbered from, unless you're OK with deaggregation and
> the scaling impact it has.
> - Via a relay or direct?
> Direct could mean large broadcast domains and may not scale, but helps
> minimise the need for the server to be topology-aware.
> Relays would help scale but will need to keep state, and to completely
> avoid flash renumbering during planned or unplanned outages, they would
> need to write leases to persistent storage also.    (see draft-fkhp-dhc-dhcpv6-pd-relay-requirements
> )
> - DHCPv6 server colocated on the BNG/CMTS, or an off-box solution?
> Off-box solution is yet-another-thing to manage and scale.  Presumably
> there'll also need to be an IPAM, if we're to do 100% fixed statics, just
> for subscriber assignments.
> BNG/CMTS Vendor server may have it's on constraints and limitations.
> As a network operator, we can make sure we do as much as we can to keep
> PDs stable and honour leases up to the lease-time advertised, but there
> will always be the risk that sometimes we have to revoke the validity of a
> lease, either intentionally or unintentionally.  And sadly in the worse
> case scenarios, we may not be able to offer the same PD or NA as previously
> leased.
> If we can offer some recommendations to CPE & DHCP client/relay/server
> developers, as well as Operators, to help minimise this impact, I think
> it's worthwhile to do.
> If we can slightly tweak protocols to help minimise this impact, I
> understand that it may be a contentious idea, but would like to think it's
> also worthwhile looking in to?
> _______________________________________________
> v6ops mailing list