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

Owen DeLong <> Sun, 27 October 2019 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7683120024 for <>; Sun, 27 Oct 2019 12:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 GqWTjk_w50Iz for <>; Sun, 27 Oct 2019 12:36:57 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 5DD7D120052 for <>; Sun, 27 Oct 2019 12:36:56 -0700 (PDT)
Received: from ( [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x9RJZsDi032645 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 27 Oct 2019 12:35:55 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 x9RJZsDi032645
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1572204955; bh=eVZ9RBwwImxPlLGaCflhJrjRnGW4SBT17IZKBUePvA4=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=W38hnBqaXvlBAf9YwCl+u0jQiYkFnr4yE1PmNGIDrnnVM5c3e4dGmbA2Zwleq5F1M QXlK3PybiqlpPmUy7rDifvieiUZKOgRvpgs4yCT7fA8snRf2ikKpK5vheA1d+ZAWMs zA2XwL5bRwBVf2EKKXKav1HX1WFDDB9fAkDw6yKs=
From: Owen DeLong <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5B4460ED-68D4-4A40-BAAE-975C08F6AC8A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 27 Oct 2019 12:35:54 -0700
In-Reply-To: <>
Cc: Philip Homburg <>,
To: Ted Lemon <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( [IPv6:2620:0:930:0:0:0:200:2]); Sun, 27 Oct 2019 12:35:55 -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: Sun, 27 Oct 2019 19:37:03 -0000

> 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.