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 <> Fri, 01 November 2019 11:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 681A9120103 for <>; Fri, 1 Nov 2019 04:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Status: No, score=-0.496 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, URIBL_BLOCKED=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 gHCZRfqq3m3b for <>; Fri, 1 Nov 2019 04:12:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF5B31200E0 for <>; Fri, 1 Nov 2019 04:12:59 -0700 (PDT)
Received: by with SMTP id u13so8072946ote.0 for <>; Fri, 01 Nov 2019 04:12:59 -0700 (PDT)
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=sZL/TaeYfq2bgliXG+Y6UeRNB0WpHJ+Evms4JfCbh6k=; b=DRI8rGnGAQs8FKy2UwkZ5ehRRTk/E93aUnK86xPwEdy6WuDScq+7n5VZxqtyyauLUD b6MpvRA/HpJ6Xs5KQHNdX6b5wmxvNlm+7odKk2DiZcDOfJUC17MGjNxuCF1/AikkWUcN RM45JyP+JqKwMMU0txH+NcKuXLLobwfybWTB6Ej3bnTBSYJn7NmqdseE/Nq8/xN8XxrP rznknnfhOp1g/gs1v2EU5BXc1YLfoYxjCuHAvIK0K4RwVFlk72PUJ13UhYWEMZ8cfHtb QSP0xeeB+ms6ki1Oukbo41R34UyRAB/kHQPtRGODQfHWB0osgEHAeOIuI3J9jug5QmAo p2LA==
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=sZL/TaeYfq2bgliXG+Y6UeRNB0WpHJ+Evms4JfCbh6k=; b=V1wi4NwzyGQhjyFAHD5ihZT69qXqRMRmSGP8K9uCDjzcZFZFus+twisBQCWxzKJo+G zn3BDmtgwiUFDdy5DcFwYy0sx5wYBS04ZcK4Npv24qZhgfzBqODWvFq/nQeX0aYAeRgE oqhxaSPwMofnoRmIH5+tpNbq7gdkWrgEx7INMP8188HnvQ5TeCcgQE6OO4GZ2dmck0FM kF4yFsZNUFdL/WBP7Oj+YJGwOwrRZeb2yTZuKJBw2CUtCG8UVTO86mwtze59YjhFfIOB DdaX7uX0mFfnxaXEWirv44MTk3pCEBhiB4oBfRNKfnG9cVNZEyeYoKZ05/9WxcFXdU58 in5A==
X-Gm-Message-State: APjAAAUszoqVZ/E0+9yWS4UOBQZ1+ZPXJMFE7C1aKXKN9iicv/LLD5mk HmtGLjuwZRqGq6Ok0Y4yMNSnoSWz99v8vOhNWWindw==
X-Google-Smtp-Source: APXvYqyZm/VCHOOfKfLIz7tIilerFFJKfEWHvD82e7vnW3/tLQ+PXzFQT6zc/Dygk7z1F5jWHdmxd+YriZiAsD64pR8=
X-Received: by 2002:a9d:611c:: with SMTP id i28mr5814407otj.348.1572606778871; Fri, 01 Nov 2019 04:12:58 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Fri, 1 Nov 2019 22:12:48 +1100
Message-ID: <>
To: Philip Homburg <>
Cc: v6ops list <>
Content-Type: multipart/alternative; boundary="0000000000006d14fc0596470c7d"
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: Fri, 01 Nov 2019 11:13:01 -0000

On Fri, 1 Nov 2019, 21:42 Philip Homburg, <>

> > > "Hope" doesn't make networks run properly.
> >
> > This isn't "Hope", this is breaking promises, and that does break
> > networks. If you can't at least trust that promises are intended
> > to be kept then you have no network at all...
> Maybe somebody can do a text analysis and show which promise is broken.
> The typical case is a CPE rebooting, requesting a prefix using DHCPv6 and
> getting a different prefix from before.

It shouldn't be. That's why clients have DHCP Unique Identifiers (DUIDs)
that should be persistent across client restarts (or CPE reboots).

>From RFC 8415 (the new RFC 3315)

binding                   A binding (or client binding) is a group of
                             server data records containing the
                             information the server has about the
                             addresses or delegated prefixes in an
                             Identity Association (IA) or configuration
                             information explicitly assigned to the
                             client.  Configuration information that has
                             been returned to a client through a policy,
                             such as the information returned to all
                             clients on the same link, does not require
                             a binding.  A binding containing
                             information about an IA is indexed by the
                             tuple <DUID, IA-type, IAID> (where IA-type
                             is the type of lease in the IA -- for
                             example, temporary).  A binding containing
                             configuration information for a client is
                             indexed by <DUID>.  See below for
                             definitions of DUID, IA, and IAID.

"The DUID is
   designed to be unique across all DHCP clients and servers, and stable
   for any specific client or server.  That is, the DUID used by a
   client or server SHOULD NOT change over time if at all possible; for
   example, a device's DUID should not change as a result of a change in
   the device's network hardware or changes to virtual interfaces (e.g.,

Mrugalski, et al.            Standards Track                   [Page 32]


  <>RFC 8415
<>                      DHCP for
IPv6                November 2018

   logical PPP (over Ethernet) interfaces that may come and go in
   Customer Premises Equipment routers).  The client may change its DUID
   as specified in [RFC7844 <>]."

> As far as I know, there is no text that requires a DHCPv6 server to return
> the previous lease if it is still valid.
> The next question would be, if the CPE would try to renew the old prefix
> and
> the DHCPv6 server declines. Is there any text the requires a DHCPv6 server
> to do that.
> Then the question is, if a CPE reboots can it continue to use the old
> lease?
> Typically, link attachment requires obtaining a new lease. But I don't know
> if that is specified anywhere.
> I do know that some routers do not install a forwarding entry if you don't
> get a new lease. I don't think we have any spec for that.
> _______________________________________________
> v6ops mailing list