Re: rfc4941bis: Invalid addresses used by ongoing sessions

Hello, Pascal,

Thanks for the input!

Now, back to the original question: Which of the options #1-#3 do you
think we should pursue?

Thanks!

Cheers,
Fernando

On 10/2/20 13:20, Pascal Thubert (pthubert) wrote:
> Hello Fernando
> 
> The existence of the address impacts the application and the network. If the stack decides unilaterally to remove an address, it is impacting both the application and the network. The future work could include an API so that the application and the stack tell each other when an address is no more used or usable. It could also indicate a protocol for the stack to tell the network that an address is released so the network can make room in the NCE (in advance) and reduce the chances of overload.
> 
> All the best
> 
> Pascal
> 
>> -----Original Message-----
>> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Fernando Gont
>> Sent: lundi 10 février 2020 10:14
>> To: 6man@ietf.org
>> Subject: rfc4941bis: Invalid addresses used by ongoing sessions
>>
>> 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
>> --------------------------------------------------------------------
> 

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