Re: [Gen-art] [v6ops] Genart last call review of draft-ietf-v6ops-slaac-renum-03

Owen DeLong <> Thu, 01 October 2020 02:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F5743A0895; Wed, 30 Sep 2020 19:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 S9nRX_WIM2RK; Wed, 30 Sep 2020 19:14:52 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 3370C3A0891; Wed, 30 Sep 2020 19:14:49 -0700 (PDT)
Received: from [IPv6:2001:470:496b:0:f46d:6de9:9ff9:6520] ([IPv6:2001:470:496b:0:f46d:6de9:9ff9:6520]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 0912EiKh4036941 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Sep 2020 19:14:48 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 0912EiKh4036941
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1601518489; bh=r25HPOYuAw5qP4Su48rnKIPR+CEm1rzL84kqDiAD6R8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=cabGFq7NYZXszX6v/3WCgBuOVMG8I2/IeqRjO0L4m+7Naz1eRpSdHhaxnyIaw/yxJ Cpq5uGKoAVJkBmi0mYlDmuBA0tzuN7P5X4V4l6BzTp4EiXtX7RceBbdxBeT5RFDl5M 7vEa/Z64T8ZzJbcgHpGGc9q/+acmGRwYziIiyflU=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Wed, 30 Sep 2020 19:14:44 -0700
Cc: v6ops list <>,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Philip Homburg <>
X-Mailer: Apple Mail (2.3608.
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( [IPv6:2620:0:930:0:0:0:200:2]); Wed, 30 Sep 2020 19:14:49 -0700 (PDT)
Archived-At: <>
Subject: Re: [Gen-art] [v6ops] Genart last call review of draft-ietf-v6ops-slaac-renum-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Oct 2020 02:14:54 -0000

>> Despite the fact that RFCs prohibit hosts from reducing the valid
>> lifetime to less than 2 hours in response to a received RA, some
>> routers do send such RAs and some hosts do (in violation of the
>> standards) deprecate the prefixes accordingly. This is kind of a
>> no-win situation because if you deprecate the prefix, you have
>> weaponized (spoofed) RAs as a mechanism to tell a host to deprecate
>> a prefix. OTOH, if you dont deprecate the prefix, you have a
>> situation where the user may well be suffering for at least two
>> hours with a non-functional stale prefix.
> There are two lifetimes: the preferred lifetime and the valid lifetime.
> The two hour limit only applies to the valid lifetime. (RFC 4862,
> Section 5.5.3)
> So an address can always be deprecated (preferred lifetime is zero),
> but it will remain valid for 2 hours or the current valid lifetime,
> which ever is less.

Yes, I conflated some terms… Sorry…

To be clear:

Some routers send PIOs in RAs with a valid lifetime of 0 and some systems erroneously process that and invalidate said prefix. This violates RFC4862 and is a potential DOS vector. If you invalidate the prefix, you have weaponized RAs as discussed in RFC4862.

A deprecated valid prefix that actually should be invalid will cause less suffering than a non-deprecated prefix in the same circumstance, but the no-win situation I was describing remains.