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

Nick Hilliard <nick@foobar.org> Sun, 27 October 2019 12:34 UTC

Return-Path: <nick@foobar.org>
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 3D5F912009C for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 05:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GKN_eWlWthjC for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 05:34:00 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B97012002F for <v6ops@ietf.org>; Sun, 27 Oct 2019 05:33:59 -0700 (PDT)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet.foobar.org (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x9RCXsZq020271 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Oct 2019 12:33:55 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.foobar.org
To: Ted Lemon <mellon@fugue.com>
Cc: v6ops list <v6ops@ietf.org>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <e67f597d-93a7-3882-3a12-69519178893d@foobar.org>
Date: Sun, 27 Oct 2019 12:33:53 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.7
MIME-Version: 1.0
In-Reply-To: <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/fDy2HOzEuZjTM_CIlxv88FNQieI>
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: Sun, 27 Oct 2019 12:34:02 -0000

Ted Lemon wrote on 27/10/2019 12:02:
> If you Really Really want to be able to have the routers send out RAs
> that deprecate the default route, and, as Mark is saying here, to
> upgrade millions or perhaps billions of hosts, why not ask for
> something that’s a real improvement?
> 
> First of all, fix CPEs so that they definitely support clean
> deprecation of prefixes using PD.  Second, fix RA so that it’s
> non-repudiable by a device that doesn’t have the secret key.
you mean, turn it into stateful address autoconfiguration? :-)

This isn't a criticism of what you're suggesting btw. It's an 
observation that the design philosophy behind SLAAC has intrinsic 
problems that cannot be resolved without dealing with state and state 
transfer, and that maybe we need to take a critical look at SLAAC and 
make potentially difficult decisions about whether or not it's fit for 
purpose for common deployment situations.

Nick