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

worley@ariadne.com Fri, 04 September 2020 02:40 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EF03A1545 for <gen-art@ietfa.amsl.com>; Thu, 3 Sep 2020 19:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.984
X-Spam-Level:
X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 7_P3n-xsoVOh for <gen-art@ietfa.amsl.com>; Thu, 3 Sep 2020 19:40:55 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4453A153A for <gen-art@ietf.org>; Thu, 3 Sep 2020 19:40:55 -0700 (PDT)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id E1ONkqbQaVPljE1eokvxP8; Fri, 04 Sep 2020 02:40:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1599187254; bh=2Amd4LMcHZdRpU5UR0i33QgCjeTUR/HkUn/j9q6Ouc4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=Pp0QkWU+UIWD8jsvprUM4X8b9ul+CXN6RxaGMyIfE2r6EmjSIO2tjIv7sRpbHWFpL Ra7nK24aqq1OS2kOpw2yOsd0FhG0qCG5pzHKn6hSNf4Ua7jV2/dv/pnCC9+6rxRzC7 5+wcFw6+2pxupoj0pXDlgVdWWYnwiMCJ2B9zykR6ychhdrj1ye6hvXal6VuynBwtsg 0Y0efPcCpZ9f1Js1uqx3URJhKMmzn6iARCsvHyvEDWFmUXABJbadqLDXXuHN3AMaNd 0vMoi2wQeJyymnxfIIBmnFTrkojLnt4Ofer2TdOBMWTVDbjQZTbAHacGJJMbCpqJTT 3qdpZS3EvrZ6g==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-10v.sys.comcast.net with ESMTPA id E1ePkmMG5zwutE1enkK03N; Fri, 04 Sep 2020 02:40:53 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0842eTNe024169; Thu, 3 Sep 2020 22:40:29 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0842eSHB024158; Thu, 3 Sep 2020 22:40:28 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Owen DeLong <owen@delong.com>
Cc: gen-art@ietf.org, last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org
In-Reply-To: <3EB77F8F-C229-47CC-833D-C4B127701B10@delong.com> (owen@delong.com)
Sender: worley@ariadne.com
Date: Thu, 03 Sep 2020 22:40:26 -0400
Message-ID: <87a6y6clid.fsf@hobgoblin.ariadne.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/As6G8U7rAYFnoS2zIl2nCi_C16E>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-v6ops-slaac-renum-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2020 02:40:57 -0000

Owen DeLong <owen@delong.com> writes:
> This depends. Certainly a host which still has active flows using the
> old address will not automatically terminate those flows. Further,
> longest lifetime is not even listed as a source address selection
> criteria in RFC6724. Even if it were added, it would likely be
> subordinate to rule 8 (use longest matching prefix) in which case, a
> source address that was not deprecated and which had more left hand
> bits in common with the destination address would be preferred over
> one that does not.
>
> While it may initially seem logical to prefer the longest remaining
> lifetime, there are a number of flaws with this approach and indeed,
> one of them is that the longer lifetime may belong to the older
> prefix.
>
> Consider the scenario where as part of renumbering a group of
> customers, an ISP decides to also shorten the preferred and valid
> lifetimes on the new prefix to simplify their future maintenance
> procedures. Where the previous prefix may remain valid for up to 7
> days with a preferred lifetime of 24 hours, they issue new prefixes
> with a preferred lifetime of only 3 hours and a valid lifetime of only
> 24 hours. In such a case, using your proposed longest lifetime would
> actually cause hosts to essentially ignore the new prefix, possibly as
> long as the better part of a week.
>
> There is also the possibility to instead of longest lifetime, consider
> the most recently refreshed prefix, but if there are more than one
> router on the segment, this could create a sort of flapping behavior
> between source addresses which would also be undesirable.

And it might well be worth putting a precis of this in the document, as
explaining why a lot of approaches will not be satisfactory.

> As such, it seems that your comment is more based on a
> misunderstanding of the relationship between SLAAC and HAs than it is
> based on a need for clarification within the document.

I'd say "a lack of understanding of the relationship between SLAAC and
HAs".  Being a Gen-ART reviewer, my position is that of someone who is
not read in to the protocols in question, and thus able to identify
points where people who are not read in to the protocols are going to
get lost.  But another thread contains what I consider to be a good
solution to this point.

> 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 don’t 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.

It seems like this is one of those annoying facts about the universe
that is really relevant to the discussion in the document.  But I don't
recall it being stated anywhere.  Indeed, I would promote it as "Can we
define a better solution so we can convince implementors to stop doing
this?"

>> 2.4.  Lack of Explicit Signaling about Stale Information
>> 
>>   [...] such signaling would be mostly ignored.
>> 
>> This needs clarification why it is "mostly" rather than "always".
>
> Because the original standards are ambiguous and so the result is somewhat
> implementation dependent. Some implementations also behave “differently”
> depending on circumstance and/or configuration.

Probably worth stating explicitly.

> In this case, timely is most about user perception. If the now dysfunctional
> address remains in use long enough for the user to become annoyed (or arguably
> even notice), then recovery is not timely. Since the definition of timely in
> this case is actually subjective, I’m not sure that such clarification is
> practical or useful.

I agree.  But if timliness has no really solid definition, why does the
text firmly assert that certain particular values, without qualificaton,
are not timely?

Dale