Re: rfc4941bis: Invalid addresses used by ongoing sessions

Mark Smith <markzzzsmith@gmail.com> Mon, 10 February 2020 20:25 UTC

Return-Path: <markzzzsmith@gmail.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 277E9120844 for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 12:25:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 uKIQPRkhWkAT for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 12:25:43 -0800 (PST)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8E6120842 for <6man@ietf.org>; Mon, 10 Feb 2020 12:25:43 -0800 (PST)
Received: by mail-ot1-x32d.google.com with SMTP id 66so7724054otd.9 for <6man@ietf.org>; Mon, 10 Feb 2020 12:25:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DDQ1eVWmH9S1oGAQcMdEF0eSWeFND7XbP/6bJqI1Z9k=; b=X3MUj4O9YClq2VRWIgV0dLziPXzmV2JuHAKQfkNn9iJhNjEOLNxkw2n8+6v/ttHDLQ JY9HL16x79cEtWRrNMN0FyE/s7K4bCTEErd3Ay9D0YJPQaWTnhkU9pF/EOsBXJb4MQFy BXSuCiTG/0rg8VnCrKijgSD0qGYwXWT0td/WE1XG5DJ1Xq6ikonByJ8auNyxWBCQFjW4 wO2kN85fcrCDl2/e8lgtJVvKcwUb43QMoVPeTecqYoYjDjNErSobjLBzxhfL1nlZnv69 Or/TzoPRVEL7KpFYhO0EA1h1E69Gnu0ev1EQv2tW7Y6oeiUcycYxF4imUUNiyTIS8Dtf cQoA==
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=DDQ1eVWmH9S1oGAQcMdEF0eSWeFND7XbP/6bJqI1Z9k=; b=Wppaan3Ygf3ivsu1ynqkMsDPi2g4PRzdqNJIAIsUN96svdhowZGixmyh4Bavshnf01 Yv/TAtbaIL59iJbgQb0HcYovAvUFD59EKn4FlwvLtFsJYgOsZjCzfLqClWBaXyS4vvsT 1itee+zdJrn7Nk7cbAHG4kTZxG+1XkdR6SAWKgqBLk2CyTukNhdoD0xMfrVZK3oDJAWu 6sVc1FGTtPk+IUS5LB8Yf+2pjNaZDbDv2oPICBPGPsZfor6fvaBVnstuRNGGqaJ6eZ6P Th9KfVOxs8TPwovEt+XJjn0lA4ItYt1OXQkFjQLA6+ofAKeKNSBuSlyzII9rj1tn9g+k bvig==
X-Gm-Message-State: APjAAAVNVGqXpkiPvlb952VVkJ/9jLN/P3ZfixrP4Kunr4W371fvEbHG J3DruHq15T45UNCyut+CICeJdBFYHnhsUaHB6lJR6Q==
X-Google-Smtp-Source: APXvYqwOCUeTw67wPZQn+3Iw9IiCzAQyaaVHFHwpP3c6pc51os/92uNuHzf/350jXf3nPrqRk6gPERQl3DcsDyTrN5I=
X-Received: by 2002:a9d:6653:: with SMTP id q19mr2508504otm.94.1581366342612; Mon, 10 Feb 2020 12:25:42 -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: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 11 Feb 2020 07:25:30 +1100
Message-ID: <CAO42Z2wq0YA_5twXJ2yqVqBWM4_sZ9eBGqAJQgJH2PV1uKaANg@mail.gmail.com>
Subject: Re: rfc4941bis: Invalid addresses used by ongoing sessions
To: Fernando Gont <fgont@si6networks.com>
Cc: 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c792f059e3e8b79"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1PjEcgWxXBGAl8CcUJ1nSd6GByE>
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 20:25:46 -0000

On Tue, 11 Feb 2020, 03:12 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
>

I generally like the idea, however I think it should be removed at this
stage because of the ambiguity problem.

Just because an address has been used by TCP doesn't mean it isn't
currently or can't in the near future also be used by UDP (or DCCP or
SCTP). Current source address selection doesn't take into account the
transport layer protocol.

If the temporary address mechanism eventually evolved to the point where
there were "TCP only" and "UDP only" (and DCCP, SCTP) pools of temporary
addresses, then this would be possible to reliably implement.

Regards,
Mark.



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