Re: rfc4941bis: Invalid addresses used by ongoing sessions

[Gyan Mishra <[e-mail]>]

On Tue, Feb 11, 2020 at 12:16 AM Fernando Gont <[e-mail]>
wrote:

> On 10/2/20 23:25, Mark Smith wrote:
> >
> >
> > On Tue, 11 Feb 2020, 13:13 Gyan Mishra, <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >
> >
> >
> >     On Mon, Feb 10, 2020 at 11:12 AM Fernando Gont
> >     <[e-mail] <mailto:[e-mail]>> 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.
>
> In that case, would you go for #2 above? And, what's your position
> regarding reducing the preferred and valid lifetimes?
>

   Gyan>. Yes to #2 and I am in favor of reducing the valid lifetime from 7
to 2 days.  That reduces the number of temporary addresses from 7 to 2.
It’s a win for operators with the reduction in addresses.

As far as the text I would modify or maybe clarify that by tracking the
address used by upper layer protocols the implications of doing so that you
increase the number of deprecated addresses.  By doing so tracking the
addresses, the valid lifetime expire timer is in essence not used and so
long lived connections using deprecated address in theory would never
become invalid and can live indefinitely.

We should some text as to severe consequences of long lived connections
with tracking usage.

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.


> Thanks!
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]