IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Wed, 30 October 2019 11:19 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 BA6B9120099 for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 04:19:27 -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, MIME_QP_LONG_LINE=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 VNlDQk0DlYuI for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 04:19:26 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 D8173120046 for <v6ops@ietf.org>; Wed, 30 Oct 2019 04:19:25 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id l3so2677728qtp.2 for <v6ops@ietf.org>; Wed, 30 Oct 2019 04:19:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:date:subject:message-id :cc:to; bh=knJn+MAkI2KbeDfsBhS4WhHdESN9CL58tGqLQMXqDeQ=; b=obdWhoT+IeOJecplBA9xZvDvhuDZWRslGdTRRjL8mTflLFq6t/oadxD9MI2NH88ocs cICtW7IS4aDg2e8c4Nd66idkwZPP6CSUqpSORVEQLKbZwwijNhH4VZktAER1ySSKsBEL kV2eMr5xzmh3YWfM2ARQNx/ELoWpQ9GJjI4o3ov8H7P32qQvK161UOrLp506QzsFUi3M 6XPUCNkKUuojOPAOCljnZwepUyKERRo9R1ejvQcBo0NpfY8+wB8VJ5y952LWRY3DNw/t AIsVCgZQ7pg3qnSTlR0Q2g7q1q5+ItkcaHZP1pXRlyBkVV5JB0BnLwyD0q3CYurCWhy0 JmNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:cc:to; bh=knJn+MAkI2KbeDfsBhS4WhHdESN9CL58tGqLQMXqDeQ=; b=DLH7mRq19kh2AAtvOeG6CQol4Q/7EPDX58JIX4/4PVs+p48t5oaDSIciqHpSHQyK0A 449gWmpjYhRsx1SezBgATYBm/DS+l7G0zxSYqgwZGlypdyH2AnfgMPxcxHe9Jvm0PCLu wLoSnmD7n5sPyj6mJU2D5/B7xPHFempKg8zfdcDT3lqLjv/VeVzHO1BxUk6QCgm2H68X TJqq+ZkPmz1UgfuNJF/SAmO2dYwz1qoksTfwte6k1y2uKvTisgzs1VQ/OrvawCOVlaPi bwqrRyll2kNS+DX8DXuKWMtmkEt74OQ4k70IT78a0AStk7zgqfZFHOdl9Uq7IE3xTqvb BMfw==
X-Gm-Message-State: APjAAAUz1GWzuD3JpZ6/VnPShd2DJXg1SJbnyFawg1myinPuLlqWYR/e tU+7FZ5CKI3VUVXcrAHTIC0YeXERuN9C8w==
X-Google-Smtp-Source: APXvYqwuAjk06bkH17IS68Q9K9WKhKejYQqVGeq2VbQ76NB5fNoFdqtQt6nNIVZhJIPzUcpZaf+wxQ==
X-Received: by 2002:ac8:35a4:: with SMTP id k33mr4310816qtb.354.1572434364766; Wed, 30 Oct 2019 04:19:24 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:9be:fcfd:8f35:ceef? ([2601:18b:300:36ee:9be:fcfd:8f35:ceef]) by smtp.gmail.com with ESMTPSA id e17sm1098404qtk.65.2019.10.30.04.19.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 04:19:23 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 30 Oct 2019 07:19:22 -0400
Message-Id: <4BFCBC35-7997-4763-BDA1-443AAF30B487@fugue.com>
Cc: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops@ietf.org
To: Ole Troan <otroan@employees.org>
X-Mailer: iPad Mail (17A878)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/HFl5B4imYv5OnCsqO9Kl0yR_f3o>
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 11:19:28 -0000

On Oct 30, 2019, at 7:01 AM, Ole Troan <otroan@employees.org> wrote:
> 
> What a CPE does do, is to send an ICMP destination unreachable (5 - Source address failed ingress/egress policy) as the source address would violate the unicast RPC check. RFC7084, L-14.

Does this actually happen in practice, though?

It’s not actually clear to me how L-13 would be implemented.   Is a failure to provide a prefix that’s been requested an indication that the prefix is no longer valid, or simply that it isn’t renewed?   Should the CPE in this case stop using it?   What does “replaced by” actually mean?

From the perspective of DHCP PD, it would be valid for the CPE to continue using the prefix until it expires.   That might very well not be the right thing to do, but there is a lack of clarity here in the specification, and I am wondering how router vendors have interpreted this in practice.

v2.23.0 | Report a Bug | By Email