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

Ted Lemon <> Sun, 27 October 2019 17:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49F8312006D for <>; Sun, 27 Oct 2019 10:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4io2T3XhvpG4 for <>; Sun, 27 Oct 2019 10:15:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D8D7120046 for <>; Sun, 27 Oct 2019 10:15:03 -0700 (PDT)
Received: by with SMTP id m4so6374728qke.9 for <>; Sun, 27 Oct 2019 10:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TUCYEm7acOaJcIWjzdoURAEG5h9aJ4R2aqDwgfEdlzc=; b=EqVw8xNRgYLBQ4bFBstt/f0hcAqUaTd/eE1kn203WWQpyB8LFVU8Znn88tUQQ8b21+ QOCQtAiRX8ZtG/Odmk9UOc//4cRAdoQ14acq19FvPO+2dVp9vDTf61yt6GRGwEDw5NVd eHdPyFfm8rhVgZuqIVyNzUmAMb3Rsqd9/cs5c3/bLiAM13pIC/gbtH3EQhzbNKDW42OY Ys4c0uwCLSpy6WRE/ZJ+iT96RuKv25oJ8f1VX8ebecqQizTMaku+CBXElTmqJ8S4dUy/ u/Ma4/OD9AOrGstim4PQr70kDxtlfCkuiNH6HB46fzgQqz+Rln1AaFgWOgcSQWdU750T FMCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TUCYEm7acOaJcIWjzdoURAEG5h9aJ4R2aqDwgfEdlzc=; b=HQO7u30mTmDaMFO9V35zcdt5DNvvb1NJv2zXTxGhOTcMLsMW0HNg7l2/PkH30IFJQu 4t8VsAtazLQVmTOWwn/MOtzeOmQTbhbC+5DtQV3zRVlnHoeVWicfRdd0XPV23h0BdRMw gzkPkKUHD3YRcWUZWUFsXduW5y4koQ5UTrUKl+9eAACv6/7Yyvq0FvOkCnZgpgTJOPX+ /zaNBvshqxU6lJz1FcvWZv604ifBKJM3aaLJ/Rv2vRm0Gkn4s/dgW2xA6GfHX2wOtkdO fMS1L2dbpTkUzt+pIDNbbyvJ1IlFvT8U9lG5pn2961fd6hjWEnF2glbkbrT0wzaDk8by VuXg==
X-Gm-Message-State: APjAAAUe5hbuhWL1UqWuouyLp3Ae4Gf5sMyreo9K15SUoKf96TXUi025 x/EKo0EcmlPGy2FtyjzLwwdOvFVgqsqfmg==
X-Google-Smtp-Source: APXvYqzIi49hnI0lzzHbkPh4O7czZzUi1Kj9WxNhkyDta6mx2beOMPEvJreL6ILP+2xynhztrmSYog==
X-Received: by 2002:a37:85c1:: with SMTP id h184mr12017038qkd.195.1572196502413; Sun, 27 Oct 2019 10:15:02 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:a0de:ef21:f9e9:1e01? ([2601:18b:300:36ee:a0de:ef21:f9e9:1e01]) by with ESMTPSA id p4sm4668361qkf.112.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Oct 2019 10:15:01 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C6234B18-87C1-44E3-9486-71D73A38866A"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.4\))
Date: Sun, 27 Oct 2019 13:14:59 -0400
In-Reply-To: <>
To: Philip Homburg <>
References: <> <> <>
X-Mailer: Apple Mail (2.3601.0.4)
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 17:15:05 -0000

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.