Re: rfc4941bis: Invalid addresses used by ongoing sessions

David Farmer <farmer@umn.edu> Mon, 10 February 2020 17:43 UTC

Return-Path: <farmer@umn.edu>
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 CB52112080D for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 09:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 K-K06c6_iM6I for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 09:43:51 -0800 (PST)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144B712002E for <6man@ietf.org>; Mon, 10 Feb 2020 09:43:51 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 48GYDQ4nWnz9vcJV for <6man@ietf.org>; Mon, 10 Feb 2020 17:43:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBRFqZdYfpfu for <6man@ietf.org>; Mon, 10 Feb 2020 11:43:50 -0600 (CST)
Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 48GYDQ32xCz9vcJT for <6man@ietf.org>; Mon, 10 Feb 2020 11:43:49 -0600 (CST)
Received: by mail-qv1-f69.google.com with SMTP id p3so5451245qvt.9 for <6man@ietf.org>; Mon, 10 Feb 2020 09:43:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vIUhHtku+xNoT41C0n8XFgkT5wMw829xKSPsmctjz9o=; b=mjw9ii8Io1DP4YuCrSKAZw6muEYUPBt1XdTDBi1yW+IEI7NK0tpN5iK5/sxlrw9gcu Eba2qUXtrUFnf4r6bSG7NNuXcXYlOv2xhmTjKlRP1yS+gfr6fQymdinb0QCdPqnGkg6m OjRjSujFBLwopnZq9H4lgvSJ6sTV1aSoSfBcimxXx+keDrzPK0E4CaYe7hQafqErlAKb ywvq04lVQt3QJB3D7UWbVwdRgAkMb+/nx4yoAd5AXW3XX8J3TNInft5PfJ5A2+FXUQiv gMiTgzv+SYP9FnlWXzOfWrpnD6+zzQizQB8tVpE7qrEwp+gPhu1kZ9//tKi1lDwH33zY Iv4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vIUhHtku+xNoT41C0n8XFgkT5wMw829xKSPsmctjz9o=; b=kNoU59N3OIxOVVixMV0V+MTojczvgcF1xqtD2t57A+BCULLEzVRGmxIvKbYkM5x8wl 3ynh/fPs4yUFiYOb6fvuZkIY/14g27JbiZC0XjPaVyVpU2fyDKAhluZy6HFBaLnv81h/ 8DVVd2Prq/s+fQxdQzf2skchQFL58pbS+dmwc0fw+cWtjOwxB4GLlUD3PRNWP04hEcIJ 3tgoXrEtoyBi5JlbnV+N2ANPIphJ97eEIYv7eBfZ+tbjZonISUIJJXz/q7obLKBECAtc MfkZaz9QfigGnxDQlhUkcM7LohMC8KLNYb7gVc1Y3MaHB4ctHoRZkTYGeFevfh+RdeQw CIJg==
X-Gm-Message-State: APjAAAVGK+9+VPz0Lh8q5UCqqrnrb1Oyzqrr25U2r3dcpg5XAV2c/bgR eSQD1Vp75s3rr3n1BPt4lyfeyZ01Ra3MJJpkmZQbRXTEJZFJqfD4mGH28JPJTloL2VDEEbrWBDp t8yYgHXiOimkmjcB4S2WN0Z6Q
X-Received: by 2002:a37:9e12:: with SMTP id h18mr2362245qke.420.1581356628997; Mon, 10 Feb 2020 09:43:48 -0800 (PST)
X-Google-Smtp-Source: APXvYqxd4PbGsmOUawp8ixBcgw05mikvnBvVa0/zqZVrTXr7BT9ghclWbTsdWSrE3MYKlcKW9i/ixSvm/Y07FRVlOrA=
X-Received: by 2002:a37:9e12:: with SMTP id h18mr2362214qke.420.1581356628445; Mon, 10 Feb 2020 09:43:48 -0800 (PST)
MIME-Version: 1.0
References: <c6ba9a00-cb44-2022-5009-34211966518c@si6networks.com>
In-Reply-To: <c6ba9a00-cb44-2022-5009-34211966518c@si6networks.com>
From: David Farmer <farmer@umn.edu>
Date: Mon, 10 Feb 2020 11:43:32 -0600
Message-ID: <CAN-Dau1y-0FdV9hQ2kphJnOW7u_J=uGDb_Ca=P3QSbDfzzO45g@mail.gmail.com>
Subject: Re: rfc4941bis: Invalid addresses used by ongoing sessions
To: Fernando Gont <fgont@si6networks.com>
Cc: "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001a2855059e3c4802"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kELXgqAIzSqhZz030BrMt5vrrCk>
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: Mon, 10 Feb 2020 17:43:54 -0000

I think I prefer #1, #2 is acceptable, and #3 is a bad idea, I think this
issue needs discussion in the document.

Thanks.

On Mon, Feb 10, 2020 at 10:12 AM Fernando Gont <fgont@si6networks.com>
wrote:

> Folks,
>
> As currently specified, temporary addresses are removed when they become
> invalid (i.e., the Valid Lifetime expires).
>
> Section 6 ("6.  Future Work") of the draft
> (https://tools.ietf.org/id/draft-ietf-6man-rfc4941bis-06.txt) still
> keeps the following text from RFC4941.
>
> 6.  Future Work
>
>    An implementation might want to keep track of which addresses are
>    being used by upper layers so as to be able to remove a deprecated
>    temporary address from internal data structures once no upper layer
>    protocols are using it (but not before).  This is in contrast to
>    current approaches where addresses are removed from an interface when
>    they become invalid [RFC4862], independent of whether or not upper
>    layer protocols are still using them.  For TCP connections, such
>    information is available in control blocks.  For UDP-based
>    applications, it may be the case that only the applications have
>    knowledge about what addresses are actually in use.  Consequently, an
>    implementation generally will need to use heuristics in deciding when
>    an address is no longer in use.
>
>
> I wonder if this text should be:
>
> 1) moved more into the body of the document and made a "MAY" (which for
> TCP is very straightforward),
>
> 2) Be left "as is", or,
>
> 3) Removed from the document
>
>
> The implications of #1 above is that it can't prevent long-lived
> connections that employ temporary addresses from being torn down, at the
> expense of possibly increasing the number of concurrent IPv6 addresses.
>
> Thoughts?
>
> Thanks!
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================