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

Ted Lemon <mellon@fugue.com> Fri, 01 November 2019 12:57 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF8E1200FE for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 05:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lSkwbvcn5GT for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 05:57:35 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 4FF8A12002E for <v6ops@ietf.org>; Fri, 1 Nov 2019 05:57:35 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id y10so6008248qto.3 for <v6ops@ietf.org>; Fri, 01 Nov 2019 05:57:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xuhs/UaZwKyCW+VjTUYISsFSUALF7+CIr9FZgI69aQ0=; b=ucRPAkhiV1ZWaQdw+HM/zVkJeV6QrlIfrU3XrpelTVQSQU5sszGq071UFhEMOOZ26u smn3pTPImihMUZm4JzSg9n7nkJtfV0mCOFncy1v/OlYJh/s182f+s68v3tXN+6cwP0iQ N5hdVdtM2jn7Qya5PrysqgiXs3aspg0t1Q2+k0kkWarda7T1vxoQ3uqj0swe+fkY3xj6 BsMakg3k24O66S6/w7PBasx0BKyxhw7J5GF03ewjgumPUmAOMfYn0Ozg/yQ52Nrmy+lm y7DNiObo3x97MIb6G4649rlwVxtMyLNNTw14XThs2RjovzoXbJcMg9+JQuPMw6/6TucQ Rh5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xuhs/UaZwKyCW+VjTUYISsFSUALF7+CIr9FZgI69aQ0=; b=fKQB8+sA6tKm6uurTG5TiyHM6QayC34g9gd+A6TgF7dduVJfgGcHl6BnZgDBLsMXig wKw8iUezTOz6xFDAolmUW3nxkqwX/ZZz9PRfKKjpIbWPyG8D/t/e+punFnDFFJNEBHrF SeS+XlBFmgUcFB4COq1e8N5CIkgyix+pDuqQavHK9oQesFRjXhVaFJAP2IlNzXVvHc5G OUulIfhcmUq3J2xkTjKvi+pvxEisIdifklizY2BNfekmzDKUrtRO5+2QVGknT01R4vG5 pJMh8pDMSNRwNilM8R+xHGE5TvdIXkF7NL+cSx8CU+ew9DKCXzpwRQ0TR4LhMQ3qCJZp 5moQ==
X-Gm-Message-State: APjAAAUEocdrq6FP9r7aaJN2W6ny8z1nvmmuTXaYq0/62YnqN68SFNTK Ag2iNfQe/tf7XObYciBRM0NdIHv4WhHXVA==
X-Google-Smtp-Source: APXvYqxsBLRwizBxTTZQvF4wYVliEH4HRA6Bg6qdDOopC5S+AJu1FJKIzQ88YYLFN2DTXVjsEpbjtg==
X-Received: by 2002:a05:6214:90f:: with SMTP id dj15mr8049648qvb.224.1572613053989; Fri, 01 Nov 2019 05:57:33 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:186c:1ff3:ea8d:a057? ([2601:18b:300:36ee:186c:1ff3:ea8d:a057]) by smtp.gmail.com with ESMTPSA id y186sm3365089qkd.71.2019.11.01.05.57.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 05:57:33 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <B586DB4C-7E4B-49CC-BC7F-7FAB98F47812@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_21870CED-FAD5-4958-91BB-4D2EE88BF974"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 1 Nov 2019 08:57:31 -0400
In-Reply-To: <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org>
Cc: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops@ietf.org
To: Ole Troan <otroan@employees.org>
References: <m1iQUNM-0000KTC@stereo.hq.phicoh.net> <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <D3B1E770-F199-4605-BF78-A3637D6CDB42@fugue.com> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org> <42A7AD85-6FD3-4EDF-AE2F-4FD1FCA9A2D3@fugue.com> <13C39FBE-2AA7-4D92-A5D8-F2681A4E7115@employees.org> <5F4B1C8C-6932-4831-86D6-D735CBDD52A9@fugue.com> <6601CEF1-1BF6-461A-A656-0DF0955986A5@employees.org>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LdfrsdAr6ZrTnvjIZN5nt-MyRvM>
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-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: Fri, 01 Nov 2019 12:57:38 -0000

On Nov 1, 2019, at 8:36 AM, Ole Troan <otroan@employees.org> wrote:
> (4) is the definition of graceful renumbering. What makes you conclude "then we just assume that people will do whatever they want"?
> (especially since your options 1-3 are exactly that, people do whatever they want…)

Okay, I missed a step (or five).  We have specified what a renumbering process should ideally look like, without taking into account several likely operational circumstances.  We have not specified in sufficient detail how renumbering works using DHCPv6 PD, e.g. in a home environment.  Consequently, providers do not have a viable way to follow our recommendations for how to renumber, and hence just do whatever they can think of, possibly without realizing that there might be a better way to do it.   Also, DHCP server vendors in particular do not implement what we intended that they implement, because we never said explicitly that they should do so, not specified what a CPE should expect in this situation.

Does that help?

FWIW, I was asked to consult with an operator who shall remain nameless about how to solve this problem, and the solution I came up with relied on the recommendations from RFC 4192. and further relied on DHCPv6 prefix delegation offering two prefixes, one valid and one preferred.  Unfortunately I don’t think this was ever implemented, but I still think it’s the right thing to do; what I’m realizing from this conversation is that not everybody saw this solution as obvious.   Which I think is a problem.