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

Bud Millwood <budm@weird-solutions.com> Wed, 30 October 2019 21:53 UTC

Return-Path: <budmillwood@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 03CD212011A; Wed, 30 Oct 2019 14:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 STVWohTPYCJB; Wed, 30 Oct 2019 14:53:12 -0700 (PDT)
Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (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 11BBA1200D6; Wed, 30 Oct 2019 14:53:12 -0700 (PDT)
Received: by mail-il1-f181.google.com with SMTP id s75so3550198ilc.3; Wed, 30 Oct 2019 14:53:12 -0700 (PDT)
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:content-transfer-encoding; bh=wcLrV9QCkQSoTJYgswp7GX4PMWKuRS4rVkwk3N/SNeA=; b=kSGQ1BYHC3LZWrblEY2ukMD0HPoqCPvdtS5UyVG6r3LQIUZwE5vunNvXkH6HxEdbDv +0aRDX1ElDMyGzar7jk09zzPUd2BNHxOGx4VVWuyEErBJv77ltvZtqiL/sqE+B32mytW kI/bv2ybBb2j5ut2/mKLT8SoYf5DX5bdRqKuKSl1k8kbAQYLJTmNmG7R3gU53MDf6t0g ZdIqy4BcWjLF1Vi/4GH9zwRPz6hm1/cszveL4GTYNZhjGj1ukVW84NT+SFwPTr1YmfhS gMer084pXUDe/9MUyBGxk4JE87cUAYRODJoSiOaS98USqei2Tx/nIOSknD9NMoFyLyAj 40aQ==
X-Gm-Message-State: APjAAAV2YaZCPlYQUPeeQC103ajLvStOH8KOdhr8tt5EdmkBrIOeRs88 3wrahf4qbVpV/VYDDxMbJ4MkL0xBmaVZWHt4GSc=
X-Google-Smtp-Source: APXvYqw4L5DROPJ7NrdDSPKRMtopq58/Pu0O88ZAj/hZ2tt5iEaV71lxGc2muwVD/7X/vTkFJGaFuhxkZBPusQsDzTA=
X-Received: by 2002:a92:7703:: with SMTP id s3mr2367550ilc.274.1572472391203; Wed, 30 Oct 2019 14:53:11 -0700 (PDT)
MIME-Version: 1.0
References: <MWHPR1101MB2288616D545F3DAD1D1734A1CF600@MWHPR1101MB2288.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR1101MB2288616D545F3DAD1D1734A1CF600@MWHPR1101MB2288.namprd11.prod.outlook.com>
From: Bud Millwood <budm@weird-solutions.com>
Date: Wed, 30 Oct 2019 22:52:59 +0100
Message-ID: <CAOpJ=k06SRAHR7S+UmvFu=zvyk8j_uica2gdbBij+5pr+Jykww@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_h8wRzbD0XL1WbMmfJwSvA0Osss>
Subject: Re: [v6ops] [dhcwg] 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 21:53:15 -0000

Hi Bernie:

If suggestion (1) or (2), an older CPE that borks over two delegated
prefixes would stay borked until the old prefix expired. And it seems
like suggestion (3) still runs the risk of catching that older CPE.
Configuring that knob at the client level seems like a lot of
management overhead.

I wonder if introducing suggestions (1) or (2) aren't pushing existing
clients to expose new bugs they may have? Suggestion (4) seems
reasonable to me.

- Bud






On Wed, Oct 30, 2019 at 10:02 PM Bernie Volz (volz) <volz@cisco.com>; wrote:
>
> Hello:
>
>
>
> DHC folks may want to check out the recent discussion on the v6ops mailing list (https://mailarchive.ietf.org/arch/browse/v6ops/) with the “SLAAC renum: Problem Statement & Operational workarounds” subject.
>
>
>
> Basically, one issue that appears to happen in networks where CPEs receive delegated prefixes and are renumbered when a CPE cycles power – why the renumbering occurs is not material. The issue is that some of the devices serviced by the CPE may still have configuration (i.e., from Prefix Information Options received via RAs or perhaps even DHCP) based on the original delegated prefix and if the CPE does not have stable storage (into which it stored the old delegated prefix), nothing initiates deprecating this information. This is because everyone is honoring the lifetimes, but the renumbering caused the SP DHCP server to provide a totally new delegated prefix and there’s no record in the CPE of the old.
>
>
>
> For a CPE that has stable storage, it could initiate steps to deprecate the old delegated prefix.
>
>
>
> Note that this issue is discussed in https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00#section-3.2 and also in section 4.3 (S-1) of that draft.
>
>
>
> One idea that I suggested is that the SP DHCP server can provide this information to the CPE. The DHCP server should still have a record of the previous delegated prefix (as it has not yet expired for the binding) and it could therefore send this, with 0 lifetimes, in the Reply to the Request (as it would do in a Renew). This would avoid the need for the CPE to keep this information in stable storage.
>
>
>
> There isn’t any direct mention of sending IA_PD (or IA_NA) with 0 lifetimes in the processing of Requests, but it isn’t a stretch to consider this. And, without something, it isn’t obvious that servers should (or would) do this?
>
>
>
> Some possibilities are (from least conservative to most):
>
> Always have the server do this (sending 0 lifetimes) for a Reply to a Request for this condition.
> (1) but only for Relayed messages.
> Have a server configuration knob (at whatever granularities desired – global, prefix, client, …).
> Define a new option that a client would include in (Solicit/)Request to request this behavior. Note that (3) could always override.
>
>
>
> Hopefully existing clients would handle this correctly, though they likely would not take the action to deprecate the old delegated prefix. But we don’t know (and at least early in the DHCPv6 days, clients weren’t always happy when they received multiple delegated prefixes). Hence, how conservative should we be?
>
>
>
> Perhaps we can discuss as part of draft-fkhp-dhc-dhcpv6-pd-relay-requirements (which is on the agenda for IETF-106), or I could request a separate slot for it - if we need a higher bandwidth discussion.
>
>
>
> We can also just discuss here on the mailing list as it may be possible to resolve fairly quickly.
>
>
>
> It will require a short draft as it is something that would need to be folded into a RFC8415 bis or continue on it own. Probably adding it to draft-fkhp-dhc-dhcpv6-pd-relay-requirements is not best since these are the delegating relay, not server, requirements.
>
>
>
> Bernie
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg