Re: rfc4941bis: Invalid addresses used by ongoing sessions

Fernando Gont <fgont@si6networks.com> Thu, 13 February 2020 17:46 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596E41200C3 for <ipv6@ietfa.amsl.com>; Thu, 13 Feb 2020 09:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ONW7zcwFHQI9 for <ipv6@ietfa.amsl.com>; Thu, 13 Feb 2020 09:46:15 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADB6120058 for <6man@ietf.org>; Thu, 13 Feb 2020 09:46:15 -0800 (PST)
Received: from [10.7.50.55] (unknown [201.220.154.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1F9AC834A8; Thu, 13 Feb 2020 18:46:07 +0100 (CET)
Subject: Re: rfc4941bis: Invalid addresses used by ongoing sessions
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6man@ietf.org" <6man@ietf.org>
References: <c6ba9a00-cb44-2022-5009-34211966518c@si6networks.com> <MN2PR11MB3565437F70601F5CE815DFC5D8190@MN2PR11MB3565.namprd11.prod.outlook.com> <9da7f50a-ef8b-9d4d-2e5d-134aa815659d@si6networks.com> <MN2PR11MB3565EBF17C8A0FB579A4519CD8180@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <4b8e5130-624f-7009-6d6d-6518703571d0@si6networks.com>
Date: Thu, 13 Feb 2020 14:02:52 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <MN2PR11MB3565EBF17C8A0FB579A4519CD8180@MN2PR11MB3565.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/G7FhPGvwvGMzxJsAx5yvcRD6rII>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2020 17:46:18 -0000

On 11/2/20 04:53, Pascal Thubert (pthubert) wrote:
> Hello Fernando;
> 
> There is a basic problem in the network probing if an address is still used by a host. Starting day 2, the host using default setting should start using a new address and conserve the older addresses in case there's an active connection. If the network probes the address to figure if it's still there, it actually revives it, meaning that in terms of LRU the old address becomes fresher for all participants, including the stack.

I see the situation as follows:

Case 1: The address becomes invalid, and is removed by the host

The connection is "torn down" (?) on the local host. A remote host that 
had an ongoing session still tries to use it, until eventually the 
connection times out.

Result: the connection fails, and while the address is probed, the LRU 
timestamps are refreshed.

Case 2: The address becomes invalid, but since there is an ongoing 
session, the address is not removed.

The ongoing session survives, and obviously the LRU timestamps are 
refreshed.


With the current status quo, Case 2 has the benefit the the connections 
is not torn down... and I'm not sure it has many downsides when compared 
to #1.

Of course, I agree that if the host could inform the network that the 
address is gone, then it could prevent the LRU timestamps updates. I 
guess this is what you were referring to?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492