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

Ted Lemon <> Sun, 27 October 2019 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FBB7120052 for <>; Sun, 27 Oct 2019 12:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s_JmcvWG7hFo for <>; Sun, 27 Oct 2019 12:44:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 661FD120046 for <>; Sun, 27 Oct 2019 12:44:47 -0700 (PDT)
Received: by with SMTP id t26so1492507qtr.5 for <>; Sun, 27 Oct 2019 12:44:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/TeD+KmhyrVQ6BJqGbaB3rV6y4+vqCliSZNIa8nyOus=; b=EYI445FI2DkDyd/EaY4w3srLQcj2IOD6uUjpQxVQr97fpUuewdJ8PIhCqUNJrGpItf 0pRL1T9gIwW/vCFH+H0S6TGb3nxgiPAMGCOjazN7kaaWEnMxXu2J5KqCuVD06mLycIPm l6YsARR68b6BVqbHy/sEESwSGdYejg03ivvqDYg/3pu7P1lJFFGXL/lH5BWm4A73K0Ta 4Fvm/qbomXShuMgh/zxsd5uYj8vhhnQmvDPhX2GtVCJYZ5kMPPU6fvV4FZZCYyr5s60C AOTcskY53GKwoMHTL2bc5ONHgD4nSwDJDvJZWt63tPKdhIK4WA7PjvxAXGKIIVX7obSf RvXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/TeD+KmhyrVQ6BJqGbaB3rV6y4+vqCliSZNIa8nyOus=; b=iH8baJOIEPQIwSyjNf1F9VLscsjULyimeaRkW73WAe5iS5dwoZqHJs0BuLvdWPehJP bl7OMaVGDgv8IjlEVgIssmOMZmVhY8tGR+29SBNxYQGjbRQniRzSIiCWUHRTkQI5/+ZP N/aNC/pZwlqrGDGmd2SXw9aB2gJBNm9XEG9kqCODo2b1S1wa6lpd0FaZYQVcMhjmTOPK smf+WLPfeuD9L7aAVBFxOUIU+Y4IjcOw7QaBzTAA33sao4n0/uAG5z9bhKmx7NzMGXr2 mT2I09FcW7Mtq1QJcMK6sfiwuOIcJx7S7gX5HZRCrALizmHBYpi0egJChN3Mpx2h+z2r PSaA==
X-Gm-Message-State: APjAAAVWO/LXca62gPxoieWMA19wskpLo5VxqHiz6gmJxR6CkGGkG7lk QckpxY62gbd+rDDA+9f5ZoCLMv1NdgE5QQ==
X-Google-Smtp-Source: APXvYqxsLgaotOE1g/WHaRyRNBjvx5gdyMD77MPNfY8ruFFXI4NU/F9e8fpXzbZ59SSkj1n3v8IEuQ==
X-Received: by 2002:ac8:5547:: with SMTP id o7mr13648170qtr.315.1572205486521; Sun, 27 Oct 2019 12:44:46 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:a0de:ef21:f9e9:1e01? ([2601:18b:300:36ee:a0de:ef21:f9e9:1e01]) by with ESMTPSA id x64sm4584890qkd.88.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Oct 2019 12:44:46 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A84FE1D5-1ECB-42E5-A213-F67F85443ED9"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.4\))
Date: Sun, 27 Oct 2019 15:44:43 -0400
In-Reply-To: <>
Cc: Philip Homburg <>,
To: Owen DeLong <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3601.0.4)
Archived-At: <>
Subject: Re: [v6ops] 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: Sun, 27 Oct 2019 19:44:51 -0000

On Oct 27, 2019, at 3:30 PM, Owen DeLong <> wrote:
> So this still requires that the CPE has written the lease to persistent storage. Currently many CPE do not do this.

Strictly speaking, if the CPE asks for a PD, and the server had already given it a prefix, it should get the same prefix, even if renumbering is happening; in the case of renumbering, it should get two prefixes, and should use one as the preferred prefix and the other as a deprecated prefix.   There is actually no need to write the prefix to stable storage if the DHCP server is behaving correctly.

However, in the case of incorrect behavior, end users will see more stable behavior in the case that the CPE remembers the old prefix.

> I don’t know of a single DHCPv6 server which operates that way currently. Can you point to a working example?

Honestly, I have no idea.  But that is what the RFC says you should do.   If existing DHCP servers aren’t doing this, they are not fully implementing the specification.  I think in general, current DHCP servers just don’t allow you to cleanly deprecate a prefix, because nobody asked for this capability.   DHCP servers I know of will not renumber at all.   You can trick them into forcing a flash renumber by hacking the lease database, but that’s not correct behavior.

> While there may be advantages to limited SEND, I don’t see that as a reason not to implement this particular fix across the board since it would benefit both hosts implementing limited SEND as well as hosts not implementing it.

To which fix are you referring?