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

Owen DeLong <> Thu, 31 October 2019 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0630A12010D for <>; Thu, 31 Oct 2019 16:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mcbwSFlIOJs4 for <>; Thu, 31 Oct 2019 16:17:57 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 4E518120105 for <>; Thu, 31 Oct 2019 16:17:57 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x9VJo4nA028291 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 12:50:06 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 x9VJo4nA028291
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1572551407; bh=Pvvev2jHgQRlxVqG+jSHiSgXZDmKc+Qdfg9nC3exkn0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=IfsNxhocVtq5mJP9+8xydL0rIz1fbCnWFjl8VvorKGpKQMliq3U8nzSg82rVa4Alk sPCpH1Vjxsqv0laZ5uD2XdyjlO44eYx7fktFeg6KXt9DcG5A5KZ99YtGcFSXnzByoi nM0pmHCJW9+bX5+Z0Ns+8UQN4EDDO/pibCgY8/w0=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Thu, 31 Oct 2019 12:50:03 -0700
Cc: Ted Lemon <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Fernando Gont <>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Thu, 31 Oct 2019 12:50:07 -0700 (PDT)
Archived-At: <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2019 23:18:01 -0000

> On Oct 31, 2019, at 12:43 PM, Fernando Gont <> wrote:
> On 27/10/19 16:35, Owen DeLong wrote:
>>> On Oct 27, 2019, at 10:14 , Ted Lemon <
>>> <>> wrote:
>>> On Oct 27, 2019, at 11:05 AM, Philip Homburg
>>> < <>> wrote:
>>>> If you think that this is an important thing to fix, feel free to 
>>>> talk about it. But why in this discussion? SEND doesn't do anything for
>>>> flash renumbering. From an operational point of view, RA-guard is much
>>>> more attractive then SEND. So it is not clear to me that there is any
>>>> need for SEND. But I could be wrong. In any case, if there is a need
>>>> to discuss SEND we could do that separately.
>>> I think you missed my point.  You can’t do flash renumbering by
>>> advertising a prefix with a valid lifetime of zero, because that will
>>> be ignored by hosts.   If it were not ignored by hosts, it would be a
>>> very effective DoS vector.    And so if you want to be able to flash
>>> deprecate a route, you need some way to validate that the deprecation
>>> is coming from the same source as the route.   Hence my suggested
>>> “limited SEND”.
>>> Limited SEND would not be hard to implement.   Yes, it would be
>>> marginally harder than just saying that hosts should accept flash
>>> deprecation of prefixes.   But nobody with any sense is going to
>>> implement that in their IP stack, so in practice if you want this to
>>> work, you need some way to do flash deprecations that doesn’t create a
>>> massive attack vector.
>> It’s only a DOS vector if the attacker is already on-LAN.
>> I recognize that there are environments where that is expected behavior
>> (e.g. Coffee Shop Wifi, University networks, etc.),but
>> it’s not the case for the average residential CPE and residential LAN
>> segments.
>> In the vast majority of situations where I would expect hostile hosts to
>> be likely to be on LAN, I don’t think I’d be using
>> SLAAC for address assignment in the first place. Most likely, I’d want
>> stateful DHCP in such instances.
> You can do SLAAC as long as you do FHS. At which point the issue raised
> by Ted is a non-issue.

I’ve looked at what it takes to deploy SEND and I’ve met some of the people
that support the networks in places like McDonald’s and Starbucks…

I’m thinking that successful, reliable FHS in those environments is a rather
humorous concept.