Re: rfc4941bis: Invalid addresses used by ongoing sessions

On Mon, Feb 10, 2020, 4:12 PM 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.
>

Gyan,

Connected UDP sockets should work like TCP.

For unconnected sockets, the applications respond to whatever address
packets are received from. If the address for a UDP flow changes the
application needs to adjust to the new address. Note this characteristic
already exists, for instance the apparent endpoint of a UDP flow can change
due to NAT state eviction, and application protocols like QUIC handle this
case.

Tom

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