IETF Logo Mail Archive

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 <markzzzsmith@gmail.com> Fri, 08 November 2019 21:50 UTC

Return-Path: <markzzzsmith@gmail.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 9B96812013F for <v6ops@ietfa.amsl.com>; Fri, 8 Nov 2019 13:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 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=0.999, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jBzrD8Q2nRka for <v6ops@ietfa.amsl.com>; Fri, 8 Nov 2019 13:50:19 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 0DAE0120058 for <v6ops@ietf.org>; Fri, 8 Nov 2019 13:50:18 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id r24so6442963otk.12 for <v6ops@ietf.org>; Fri, 08 Nov 2019 13:50:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gUOPRKGV6sc8PGMj1+VsXSUJQh7YWbtf1InPphvpU/A=; b=CwjHbJOx1QhY4A3KcH+pzND6WRGgD+2UTFwCdrrXHFjShTiNo+0aEyZ9bajn2eJs9s AcXJveLHdp/WZ2SJdHjfLPwhiE05KjU75TEBdIqv8qHE3n/GY4w7b+v3EJYVP6YsiJEL iuPr9+ZxDGl5qVDqVyqVlGaoyHVsGqvYB5dokRfGn16L151bXij7pzZZ56fz6oBcyDc6 0+oVpCEKtREEO8zWm6sZC5OncQUJWnfspIbAubJO3G0+qxB27A9iqIrl1mkYj2VUPPv6 eEDyNL7nnsIIOjoj8mQ+DS7rEi/eKYxcRCfzbvEEgGDI5RWo8OV7+bdqlqcNHT+WAoH/ LmDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gUOPRKGV6sc8PGMj1+VsXSUJQh7YWbtf1InPphvpU/A=; b=uilCNprqKLyMjGt6/tlS7mBrTvS0aEh51pZ6a4SowguLbmbDth7wOi+RyfP++gQBFS Cow33WPRUQ3yPKFKeKK29Fe+v0mLeB+E/p2yc7xZvfn/m4JHYLAsPva7LXHmegTeZ+/6 4h9Fb8Wi2uDo9QrKUzgZALipagyGi/JML+F1wNi/801N8kp7WaQfIvcLttz/efpfMPJr QxNlC8QopGmM1sojVxsDMk3nIKLUkvHk9xqHKYdnpv9pD81DWb7X+Yrkdm0QMqoL2/ma zoqT+IzefpttoJ3DCE0Q4ErmE+is1EUSPVF5fM0mm5N5VMW8PvJ68d+COVSmSBCRJNHQ 3zTQ==
X-Gm-Message-State: APjAAAUnvHLxW5DPU/VygAQ3A9LFTuAyxP5neo+BYK6bM4Ativd53RbD TSQovKR86KRtGw5VC0CRTgg9ER22sOPIsiAqlHgdPQ==
X-Google-Smtp-Source: APXvYqwliW4Rx3rqLgTMHAIpUDMp9BWX4d435aJYbA9tV7p4LcMAn/IYkIF3HXga9vQNGmtnq85LezLkrDY7cs6lBvk=
X-Received: by 2002:a05:6830:17c2:: with SMTP id p2mr10941132ota.74.1573249817384; Fri, 08 Nov 2019 13:50:17 -0800 (PST)
MIME-Version: 1.0
References: <m1iPlMZ-0000J5C@stereo.hq.phicoh.net> <FACE45EC-27FC-437A-A5BF-D800DF089B50@fugue.com> <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <CAO42Z2wz1H-x1O+k-ra09V=xON7GOYM+0uHkG0d3ExnsGNuDeA@mail.gmail.com> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <B958A56E-1B79-40AF-93C6-80F0831259CC@employees.org> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com> <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com> <m1iT57S-0000IGC@stereo.hq.phicoh.net>
In-Reply-To: <m1iT57S-0000IGC@stereo.hq.phicoh.net>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 09 Nov 2019 08:50:07 +1100
Message-ID: <CAO42Z2xdU+EyrB5FjLY-XVyOvVxnws3VAfBynUs0LAa_zov5yA@mail.gmail.com>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Cc: v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000821ab90596dcc4dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/QGIV4tFGOG0-wH3NdAQRz-1JB0M>
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, 08 Nov 2019 21:50:21 -0000

One of the best questions to often ask is "why?"

On Sat, 9 Nov 2019, 01:20 Philip Homburg, <pch-v6ops-9@u-1.phicoh.com>
wrote:

> > Probably there is no formal requirement for prefixes to be stable
> > across crashes and reboots[*], but there is a behaviour of the
> > client to send CONFIRM after reboot or wake-up from sleep, as
> > described in the RFC DHCPv6.
>
> Sending a CONFIRM after a reboot requires that the client writes the
> lease to presistant storage.
>
> As far as I know, there is no requirement for clients to have suitable
> persistent storage.
>
> Of course, the big issue is: do we want to delay IPv6 by making IPv6
> deliberately incompatible with common IPv4 deploy strategies?


Why do you think that this "strategy" exists in IPv4 deployments?

Why is it relevant and preferable today for IPv6?

Why is it best for IPv6 when people get something different in IPv6 than in
IPv4 - public address space to use on their LAN.



If the answer
> is that we don't care about IPv6 roll-out, then indeed there is no need
> to fix this scenario.
>
> There are other scenarios, but I believe they should be fixed in the host.
> Or not at all, if we also declare those operational errors.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

v2.23.0 | Report a Bug | By Email