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

Richard Patterson <richard@helix.net.nz> Wed, 20 May 2020 10:28 UTC

Return-Path: <richard@helix.net.nz>
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 292C63A07A8 for <v6ops@ietfa.amsl.com>; Wed, 20 May 2020 03:28:24 -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, 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=helix-net-nz.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 ZoPH4kzM86jZ for <v6ops@ietfa.amsl.com>; Wed, 20 May 2020 03:28:22 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 C121F3A0797 for <v6ops@ietf.org>; Wed, 20 May 2020 03:28:21 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id 17so2573543ilj.3 for <v6ops@ietf.org>; Wed, 20 May 2020 03:28:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zG9jXVoWW9uaSMP5+5YJi2WdTH5rdujK/vQSNrN6xJE=; b=GBt/uPng+NyPdiYjp2JrFYCQmGUWa3jdYFpoI5+/g5owADT4vwMYpg96EKkTieN4tO A9cJ2gA3rMIWvpCfr2uoynqPHNB/1x/vZcTSdvnkE1VqFJqOu1aRniXrTTqjCZQsgVfy bdHWLCbbzYi7IZ3h+bBJpFP3ZMvEKFL1jw0vj78xBUl9kxiQb+Q3eknKxC8uTvdYw9mN x8a3BaJ3r/q27c4wW9BT/61Ev1tEMpMFdLCVnPUpKgpSdtdHML2cYrcSMZrZWd793pEu SudVilq8YAA1MotYimNmW51jDDSknRa+Z8xVtyy93AQqTDn9CGt5J5fXo9xcl230O2gr oiag==
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=zG9jXVoWW9uaSMP5+5YJi2WdTH5rdujK/vQSNrN6xJE=; b=rsBpkoiOc5vW1w+19XmmRPXZJGz/vdCZeeIl5cX1F/91SmR2uhEN+G9tPUwSZRMp3T IWcWkGqjjy9Ii2k9isdBpOHYfZuWfmgFsX5XilGpxP88mUijAvcM5CveZyxwIMEcJo+F 1ot3Zx5AvZGyvUaUIXx/OGKcK25c730b6Aj9OPu2XcZ37TVa8mIstyHo76zN8oBN79FP X/cHGmt4kguN+0Esnr8GigeLHjPaE2Q3dUgEhIDLbuRgMgNqdhRyTTpUufHcdRW3EXC2 unwiGbKcF094qO1irdZN5JQJPE/wWZS36zoHKmrni9RZFZjkXgnHFK+DxIAOpu+KxzXm vftw==
X-Gm-Message-State: AOAM532X+u/LNzdPwMdMG77ggunvc7zJ8m5TKuv9G/zciSwHpT2ywyan ecQFVZ+O6025hsJAJOxC6dzPIeM7ous=
X-Google-Smtp-Source: ABdhPJyVvoD+Wc8zwVgaMuWNjxK+q84QfIbrrEMwn9OK5zYdLgtTUDsZ+ghGAThgEoOXds89DnAS8Q==
X-Received: by 2002:a05:6e02:138b:: with SMTP id d11mr2781020ilo.183.1589970500748; Wed, 20 May 2020 03:28:20 -0700 (PDT)
Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id y12sm1165533ilk.16.2020.05.20.03.28.19 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 03:28:20 -0700 (PDT)
Received: by mail-il1-f179.google.com with SMTP id a14so2580070ilk.2 for <v6ops@ietf.org>; Wed, 20 May 2020 03:28:19 -0700 (PDT)
X-Received: by 2002:a92:dc50:: with SMTP id x16mr3342076ilq.83.1589970499826; Wed, 20 May 2020 03:28:19 -0700 (PDT)
MIME-Version: 1.0
References: <m1jb1gz-0000MZC@stereo.hq.phicoh.net> <8aa3102e-22b1-60ed-2d99-838f3fdf1736@si6networks.com> <m1jbKVd-0000L7C@stereo.hq.phicoh.net>
In-Reply-To: <m1jbKVd-0000L7C@stereo.hq.phicoh.net>
From: Richard Patterson <richard@helix.net.nz>
Date: Wed, 20 May 2020 11:28:08 +0100
X-Gmail-Original-Message-ID: <CAHL_VyDWYz=hUTZ+RDZ0JuF-KCsh5HBsM1pFFy3FqtL6pC_hCw@mail.gmail.com>
Message-ID: <CAHL_VyDWYz=hUTZ+RDZ0JuF-KCsh5HBsM1pFFy3FqtL6pC_hCw@mail.gmail.com>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Cc: "v6ops@ietf.org list" <v6ops@ietf.org>, Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="000000000000d87d7e05a611da31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7bAIfYVtMRDi0dXT4617ouSOkHI>
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 10:28:24 -0000

On Wed, 20 May 2020 at 09:56, Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
wrote:

>
> I think the need to relax L-15 comes from the fact that ISPs have an
> incentive to use very short lease times.
>
> I don't know the details, but what seems to happen is that when a
> customer swaps one CPE for anothor, the old CPE doesn't release the
> lease (i.e., people just poweroff or disconnect the old CPE).
>
> Then when the new CPE asks for a lease and the customer has a fixed
> prefix, the radius daemon finds that the lease is already in use by
> the old CPE and doesn't give any lease to the new CPE.
>
> The hacky quick fix for this is to set lifetimes in the lease to only
> a few hours at most and ask people to wait.
>

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.

There are also additional approaches depending on the BNG vendor, that
either reactively clear subscriber sessions when they detect a
duplicate/conflict, or more proactively check the aliveness of the CPE
Router periodically with ARP/ND.