Re: rfc4941bis: Invalid addresses used by ongoing sessions

Agreed.  Makes sense.  Thanks

On Mon, Feb 10, 2020 at 11:30 PM Tom Herbert <tom@herbertland.com> wrote:

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

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com