Re: rfc4941bis: Invalid addresses used by ongoing sessions

Mark Smith <markzzzsmith@gmail.com> Tue, 11 February 2020 02: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 440571201A3 for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 18:25:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 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] 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 2KsoBqoaj2iU for <ipv6@ietfa.amsl.com>; Mon, 10 Feb 2020 18:25:52 -0800 (PST)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 D7699120154 for <6man@ietf.org>; Mon, 10 Feb 2020 18:25:51 -0800 (PST)
Received: by mail-ot1-x331.google.com with SMTP id b18so8640493otp.0 for <6man@ietf.org>; Mon, 10 Feb 2020 18:25:51 -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=kNHKdAOoECnnawhy82ZB1VM0Esg7/onDj3diLBgT1pU=; b=NdXHQgksdyHQN6gkzVc5uLKw20ENqojdX9XPEtqG/8PYGPCxeI4XQGXQidatXpmQMH bStugGqr9VRV6a/TL2Ie1lOQN0yGZymUEGxZmzClTbWzNHDGqfFfSAEn2cROZeUk30TX zh0G4wrwLkad7VFcTFtbueLi0SD75qEWKsXUIjI5yKSRhu44H1Y+Rn+nKnpOCv8ieIem N2FlNpD1DcTIFQPDYMnOzylAPLr2oy/PMKJMZ7kiPDuPbTWNIJF4kFnUAaItBTXGEmET c8zKyDCLsUqAfuA1bX5o3Jh0U9tu+Gk0t+sCvaAIBKX61A9keBiCmCl4EHM6d0nV0hen Me0w==
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=kNHKdAOoECnnawhy82ZB1VM0Esg7/onDj3diLBgT1pU=; b=fLEx99njdZde51CFdFszZc7R2gV5DscvZ4rt2fFQLG7wLA2LtOJc4C5MHSbi6KXjjx YWMTRSBucn49sQ7vBet3otAiYVhWpglS6GqlDF+L1a8VJeXXMTNBjeCqba2l4/pU28z7 2TzvSf8SBrHYi6STFUW/KwzgHXX4eTJGfRzc/Qhd9w8r+rUgQ16Z9COxbfBwp95DqEM0 seSk4rdOjHOFVzTJvz9ThvfvmE6rp4rW93NDXtGNpMQ5uyzY1U88UVnuiS+vE2LY2YbB so+V6YD0I0zVEkwz7w1uvTeQz4OTa+t3iPla6X4TEYsnDoOUfkuEOsTSHVQxcBp3q8Co +U1A==
X-Gm-Message-State: APjAAAWgWwAmGF4dR7WwzuXruUoUoA0OhjAimypIUdsIhKexHIBDbZxP 4zVRfk0TWph3ws3lWJOQ+0yhQA+PyzImOXBLvi4=
X-Google-Smtp-Source: APXvYqxAM4kfNY6WdUwzr2PkGqYRs0D7XhWevdOU/A0KdvoXRRCsYBsTDCl+670wiqMIhyOG51iuP94YUy+/z53/kdg=
X-Received: by 2002:a9d:6653:: with SMTP id q19mr3571973otm.94.1581387951210; Mon, 10 Feb 2020 18:25:51 -0800 (PST)
MIME-Version: 1.0
References: <c6ba9a00-cb44-2022-5009-34211966518c@si6networks.com> <CABNhwV0mb8dL_4Ef5UxAbcRbP18nH9Ztvx8XHJ0Z0GM-NaCwgw@mail.gmail.com>
In-Reply-To: <CABNhwV0mb8dL_4Ef5UxAbcRbP18nH9Ztvx8XHJ0Z0GM-NaCwgw@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Tue, 11 Feb 2020 13:25:39 +1100
Message-ID: <CAO42Z2zB6gpKwZ=DfRVEbURNyKPJWAOqLqrFvW8T_uc59=9tiw@mail.gmail.com>
Subject: Re: rfc4941bis: Invalid addresses used by ongoing sessions
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Fernando Gont <fgont@si6networks.com>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001582ec059e4393e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8y5VLa3tINRLnNs6JZnUozArsQg>
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: Tue, 11 Feb 2020 02:25:53 -0000

On Tue, 11 Feb 2020, 13:13 Gyan Mishra, <hayabusagsm@gmail.com> wrote:

>
>
>
> On Mon, Feb 10, 2020 at 11: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.
>
>
>   Gyan> So for TCP apps it maybe easier to track via active TCB blocks so
> those long lived connections could be tracked.  So those long lived TCP
> connections would not be impacted and torn down.  Other apps using UDP may
> not be as easily tracked and so maybe using the deprecated address, however
> due to difficulty of tracking maybe torn down as a side effect of option
> #1.
>


Long lived connections using temporary addresses should not be a
consideration, because long lived connections should not be using temporary
addresses.

"Temporary" and "long lived" (persistent, stable) are opposites that can
never be resolved.



>>
>> 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
>> --------------------------------------------------------------------
>>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mishra@verizon.com
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>