Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Wed, 20 May 2020 16:10 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 C52323A0B26 for <v6ops@ietfa.amsl.com>; Wed, 20 May 2020 09:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 BHW-S7I5FU_o for <v6ops@ietfa.amsl.com>; Wed, 20 May 2020 09:10:03 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6253A0B2C for <v6ops@ietf.org>; Wed, 20 May 2020 09:10:02 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1jbRI7-0000LCC; Wed, 20 May 2020 18:09:59 +0200
Message-Id: <m1jbRI7-0000LCC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <m1jb1gz-0000MZC@stereo.hq.phicoh.net> <8aa3102e-22b1-60ed-2d99-838f3fdf1736@si6networks.com> <m1jbKVd-0000L7C@stereo.hq.phicoh.net> <CAHL_VyDWYz=hUTZ+RDZ0JuF-KCsh5HBsM1pFFy3FqtL6pC_hCw@mail.gmail.com>
In-reply-to: Your message of "Wed, 20 May 2020 11:28:08 +0100 ." <CAHL_VyDWYz=hUTZ+RDZ0JuF-KCsh5HBsM1pFFy3FqtL6pC_hCw@mail.gmail.com>
Date: Wed, 20 May 2020 18:09:55 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/XVgT1Mo2Ht1WX77cBzZcPFofKF8>
Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum
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, 20 May 2020 16:10:05 -0000

In your letter dated Wed, 20 May 2020 11:28:08 +0100 you wrote:
>So this is indeed a concern for an Operator running IPoE services, but is a
>problem to be tackled on the BNG rather than the CPE router.
>One mitigation is as you suggest, the Operator uses short DHCP lease times
>so that the session times out gracefully within a reasonable time, but this
>is even more reason for L-15 to exist as a MUST, so the CPE doesn't
>overpromise the prefix duration on the LAN.

I have a hard time following this reasoning. We know that customers with
static prefixes are impacted by this and end up with short leases on their
prefixes. There is no point in limiting RA values for static prefixes. 

Of the other hand, for dynamic prefixes, which this draft tries to deal
with, there is no problem with relatively long lease times.

So this draft makes the situation worse for static prefixes to better
deal with the unwanted situation of dynamic prefixes. To me that strikes me
as completely the wrong way around.