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

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Thu, 03 September 2020 11:16 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
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 827F73A0EFB; Thu, 3 Sep 2020 04:16:43 -0700 (PDT)
X-Quarantine-ID: <3TDwYwmefF66>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 3TDwYwmefF66; Thu, 3 Sep 2020 04:16:38 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00183A0EB8; Thu, 3 Sep 2020 04:16:36 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kDnE7-0000MEC; Thu, 3 Sep 2020 13:16:23 +0200
Message-Id: <m1kDnE7-0000MEC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
Cc: Owen DeLong <owen@delong.com>
Cc: last-call@ietf.org, gen-art@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <159883647280.7294.15168668243468397592@ietfa.amsl.com> <3EB77F8F-C229-47CC-833D-C4B127701B10@delong.com>
In-reply-to: Your message of "Thu, 3 Sep 2020 01:59:48 -0700 ." <3EB77F8F-C229-47CC-833D-C4B127701B10@delong.com>
Date: Thu, 03 Sep 2020 13:16:22 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/FHYTybt6XW2_XhY979ORbHE6vas>
Subject: Re: [Gen-art] [v6ops] 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: Thu, 03 Sep 2020 11:16:48 -0000

> > Naively, it seems like the new prefix will almost always have longer
> > lifetime values than the old prefix, and given that this seems to be
> > how orderly renumbering causes hosts to transition from using the old
> > prefix to the new prefix, it's not clear how hosts "will normally
> > ... actively employ the addresses configured for the
> > previously-advertised prefix".  Naively, hosts only seem to be
> > permitted to employ the old prefix, but the preferred behavior would
> > be to use the new prefix whenever possible.
> 
> 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.

The obvious thing to do is to make sure that the old prefix is deprecated.
Existing flows can continue to use the old address because explictly select
that address as source address, new flows that let the system select an
address will get the new prefix.

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