IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Wed, 30 October 2019 13:51 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 9DE2F12011F for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 06:51:14 -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 l8XA67MjyYBO for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 06:51:12 -0700 (PDT)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 C44CD1200DE for <v6ops@ietf.org>; Wed, 30 Oct 2019 06:51:11 -0700 (PDT)
Received: by mail-qk1-x733.google.com with SMTP id 205so1459967qkk.1 for <v6ops@ietf.org>; Wed, 30 Oct 2019 06:51:11 -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=YYaTe7isG2h0k6Zp/k+/ShRd5vSRErbm+o7BDjd91M0=; b=eoSDnkFHpfM6RpI1n4k13tGTmxTLstdRkVGEpUMiJnFGfVq48lPVintc/9sFQ24VnI HFz/4mo34EP0y1fwWqRNMHMeZk1TJAIb/YnzOQZvAfU3sHI5yBxfwYs6ct8c3bD3DvfL ZkLkpIOqHgQxVrv4PBc242NlYKSAyABCYYzIx9/rTnVar8Kz5YinDYcH794j13Wu2rh9 a1smvxp+xDqM7bvQ47fJfSxo32Wim2IOZakF7nwpOMXWJbVhW7IVassTclmcA1H6nf+h GLvq/mxc4xdZVZPsJBn0Rd3i7uN3FmNv10DkAD9T64QlwOyleshD/z8PIK5zpTo8uZNW Xx5A==
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=YYaTe7isG2h0k6Zp/k+/ShRd5vSRErbm+o7BDjd91M0=; b=O2Rw0arb8TFmkkDIeV+6G6eJNhzv2dHiMfFCoKOqYgKEUTl1KkDumPh1u6XYRiM6BF 7XESRWoDZQQYScff3RJjvlrYJ8HHsY2CxuBsx5gTEMxicmxMGCMF/vAg2CtAdfFmSmJO SjZMYPlAaiwf0aaij2i7YvbqSCYoNxYnV/TS9y4MZrHz5Dsl7Km7YJWIpAqXLgWmoiAQ VdUZRWMajFHeTgUFK//iohmuIYEujMOkufIzH7nkftzjyosQ0a9xvoAAGQIqh3bIoy0t rIx6ZhPYAJh+Oqu4xi/KEFvW4avxSfFAeiUkxQI7BsdTTSInByvCFtr2SmZCL7gNym2T MAyw==
X-Gm-Message-State: APjAAAVqZsJgoAG9H8T4e09Vw3n+4hM15ZBY0T6XV41kR8OLkRJxIhsh kEjI/i1DWBsEK/kImHSkO7SoJg==
X-Google-Smtp-Source: APXvYqwvjjtAP8QeHF/vSg4eHLr58xdFdKftNY7kmsFFwta4xuMBfggb86+0BJk1bmsgD/EXtuI/Tg==
X-Received: by 2002:ae9:f80d:: with SMTP id x13mr6776004qkh.63.1572443470595; Wed, 30 Oct 2019 06:51:10 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:c5ad:3e58:9e29:c076? ([2601:18b:300:36ee:c5ad:3e58:9e29:c076]) by smtp.gmail.com with ESMTPSA id 76sm45018qke.111.2019.10.30.06.51.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 06:51:10 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <591F3207-735E-4182-82AD-A88F4A01C678@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_07240815-F81F-44F1-BDA6-20FB75AED0F1"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 30 Oct 2019 09:51:06 -0400
In-Reply-To: <F7F614D9-EC79-474C-B81C-CEF0B9EF6908@cisco.com>
Cc: Timothy Winters <twinters@iol.unh.edu>, IPv6 Operations <v6ops@ietf.org>
To: "Bernie Volz (volz)" <volz@cisco.com>
References: <CAOSSMjVhK_V4HpMzprOyo9pj=ysFef+uZUs=twd_zfPaBdPu3Q@mail.gmail.com> <0F0B6068-CA62-449B-B56E-78E9EF8D998E@fugue.com> <CAOSSMjVLP4dx0Z1OKgXBgmuUCmR_C35J87fgkX7V=e7E3iQY3w@mail.gmail.com> <96344740-2F4B-4BCE-A881-EB1A5933AFA2@fugue.com> <F7F614D9-EC79-474C-B81C-CEF0B9EF6908@cisco.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/JIvKU_FdpLBnT19ATH9lofAayGU>
Subject: Re: [v6ops] 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: Wed, 30 Oct 2019 13:51:15 -0000

On Oct 30, 2019, at 9:24 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
> When a CPE boots and does a Solicit / Request, it could include a new option that tells the DHCP server that it has no storage and therefore no knowledge of any “past” leases. The DHCP server in this case could include any “old” leases it still has a record of (i.e., that have not expired but are no longer “valid” in terms of the configuration because of renumbering or other conditions) with 0 lifetimes. That would allow a rebooting CPE to learn old delegated prefixes that it might have advertised to its clients and initiate deprecation of these prefixes (and any addresses generated from them).

I don’t see any reason why this should not just be the default behavior.

v2.23.0 | Report a Bug | By Email