Re: rfc4941bis: Invalid addresses used by ongoing sessions

Gyan Mishra <> Tue, 11 February 2020 01:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3319A1200B2 for <>; Mon, 10 Feb 2020 17:48:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5cHyPjm9Za0M for <>; Mon, 10 Feb 2020 17:48:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00A3D12009C for <>; Mon, 10 Feb 2020 17:48:07 -0800 (PST)
Received: by with SMTP id s6so9912794iol.9 for <>; Mon, 10 Feb 2020 17:48:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sdv/iK77CA+Vum0DOzq78NxXW38tf9rxot6s2PWLINI=; b=eXqYZitzvNhFYrBVqa+m/V3qdqcz7S8fpfblsLgZhXDGtu+VIpCNfdkul4fpli8jX2 wn/+cFb5UzZuaLetjcV0NlWli5ViigD2dtwzfz1z3er9ll0Ky2A5cqWa4LXJXziU+tb1 8dKZr3FCC4BVh2UAYzj1Db0GZhABjr11cV1W7Qja+itLmbCMIJ6GGFDfLmx911NE/Dkm ktdCZTZUQAkF8zzwnkmwNHmMcH8MlU+2vVrKQZrWEA0xOpiG9KcwnXmo6ab7DIfg4NMX nMQMeT5JhyJFEWkKH6qN0HNv9xRTqYr7tbGvLt/K5a39xfnrjL9seYKk8LBaZyhHh0Tw 80bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sdv/iK77CA+Vum0DOzq78NxXW38tf9rxot6s2PWLINI=; b=M5+Nv/HFAZgt3+0DcwCYrvogouh3gjNgmzZX7aX6yRypyhn/jTQbkc3gyExdtfnZBJ yNEmGhox1r8+mmTguxMR+PGaHPWR4UcsHokj4g+vjd0g9UKkxg2WpTZcmcD17MGtIyj6 LEH/R4SZkP3n+cPL7MIFdfn/+F3CcQwyUM116LMX74i33p1neXlQ8jzfIDBqkB9xqu9D PKhujubKmLh2b/KWpaOpAvAH9i1YlZbP3s9VggZ9fhEtQtQH+0vM1LAV0SHbQjLF+1B3 /wZMXs56z2FqU0/mfyasgGwuSsIR/qe/Q4P9F/Y9VuFowRtRMRl0bSuDQysrF37ilgNU XC+A==
X-Gm-Message-State: APjAAAXTR0o8ZI3Hw9Pc+ygT/YOqbiKYGSO+e76N7WuuQo2RA7e5LCXv 80Z9VrU+1G78b0yTV8ioKdOA0Wp5kkTvwP4ButE=
X-Google-Smtp-Source: APXvYqy4bRqY8/Jm+DdXbsGTu4xIWfV70m8oEWzVs9fWcq8Tcj/+jy+EZzv7mSRyTnrFaQr9NsRFZXo9dFIMFqunh9c=
X-Received: by 2002:a5e:8505:: with SMTP id i5mr11155955ioj.158.1581385687120; Mon, 10 Feb 2020 17:48:07 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Mon, 10 Feb 2020 20:47:56 -0500
Message-ID: <>
Subject: Re: rfc4941bis: Invalid addresses used by ongoing sessions
To: Mark Smith <>
Cc: 6MAN <>, Fernando Gont <>
Content-Type: multipart/alternative; boundary="000000000000223ef4059e430c11"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2020 01:48:10 -0000

I prefer #1 as to place into the body of the document.

This is a very important subject as far trade off.

As from an operational impact from an enterprise perspective as the goal is
to have as minimal as possible addresses on the device without impact to
end user experience. So #1 does achieve this objective.

However, the flip side of the double edged sword in achieving the objective
is that long lived connections using temporary address being torn down.

My thoughts on that is for enterprise devices that are not mobile and fixed
connected to the corporate intranet are the ones in secure environments in
many cases are the ones with long lived connections.  For those cases the
operators can disable the temporary address as a solution.

For all mobile user use case enterprise or other personal mobile device use
option #1.

I think in all cases having API’s for the operators to pick which address
to use for source address selection for any arbitrary use case would be the
end goal.

On Mon, Feb 10, 2020 at 3:25 PM Mark Smith <> wrote:

> On Tue, 11 Feb 2020, 03:12 Fernando Gont, <> 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
>> ( 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:
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> Administrative Requests:
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

Gyan  Mishra

Network Engineering & Technology


Silver Spring, MD 20904

Phone: 301 502-1347