Re: RFC4941 text on requirement for public addresses (was: Re: default-iids and stable addresses)

[Lorenzo Colitti <[e-mail]>]

Dave, so how are implementers to interpret this text in the presence of no
public address?

       If a received
       option will extend the lifetime of a public address, the
       lifetimes of temporary addresses should be extended, subject to
       the overall constraint that no temporary addresses should ever
       remain "valid" or "preferred" for a time longer than
       (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -
       DESYNC_FACTOR), respectively.

Should the implementer conclude that the lifetimes of the temporary
addresses should also be extended, even though the text does not require
it? If so, what of the TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME -
DESYNC_FACTOR constraints? The text does not require those constraints to
be observed if there is no public address.

On Thu, May 19, 2016 at 1:45 AM, Dave Thaler <[e-mail]> wrote:

> I agree with Ole that RFC 4941 does not require public addresses.
>
> For example, neither of the two snippets quoted by Lorenzo requires public
> addresses.
>
> They just state what the behavior is IF you have public addresses.
>
>
>
> *From:* Lorenzo Colitti [mailto:[e-mail]]
> *Sent:* Wednesday, May 18, 2016 9:42 AM
> *To:* Ole Troan <[e-mail]>
> *Cc:* [e-mail]; Fernando Gont <[e-mail]>;
> [e-mail]
> *Subject:* Re: RFC4941 text on requirement for public addresses (was: Re:
> default-iids and stable addresses)
>
>
>
> As written, RFC 4941 seems to require public addresses. For example:
>
>
>
>        If a received
>
>        option will extend the lifetime of a public address, the
>
>        lifetimes of temporary addresses should be extended
>
> ...
>
>    3.  When a new public address is created as described in [ADDRCONF],
>
>        the node SHOULD also create a new temporary address.
>
> ...
>
>        *  Its Preferred Lifetime is the lower of the Preferred Lifetime
>
>           of the public address or TEMP_PREFERRED_LIFETIME -
>
>           DESYNC_FACTOR.
>
>
>
> On Wed, May 18, 2016 at 8:13 PM, <[e-mail]> wrote:
>
> This email from Fernando provides a good introduction to an outstanding
> question from Buenos Aires.
>
> The current plan is to take RFC4941 to Internet Standard unchanged.
> A question was raised if 4941 requires public addresses or not, and if we
> have to update 4941 text, or if we can live with the current text, and
> still allow for interfaces with only temporary addresses.
>
> Opinions?
>
> Best regards,
> Ole
>
> > On 17 May 2016, at 20:15, Fernando Gont <[e-mail]> wrote:
> >
> > Lorenzo (and wg),
> >
> > The two issues raised by Lorenzo regarding default-iids boil down to:
> >
> > 1) The ability to embed MAC addresses in the IID
> >
> > 2) The requirement to have stable addresses
> >
> >
> > This document does ban "1)" as the default algorithm for generating
> > IIDs, for the reasons discussed in RFC7721 and
> > draft-gont-predictable-numeric-ids. We have a very long history of
> > improper numeric IDs, and I guess that, regarding this one, we simply
> > disagree with Lorenzo.
> >
> >
> > Regarding "2)", this document does not specify any new requirements on
> > the topic. Essentially, nodes are implied to configure a stable
> > addresses as a result of SLAAC&traditional link-layer address
> > properties, and more explicitly by this text in RFC4941:
> >
> > * Section 3, bullet #1:
> >   2.  Create additional addresses based on a random interface
> >       identifier for the purpose of initiating outgoing sessions.
> >
> > * Section 3.3, bullet #1:
> >   1.  Process the Prefix Information Option as defined in [ADDRCONF],
> >       either creating a new public address or adjusting the lifetimes
> >       of existing addresses, both public and temporary.
> >
> > * Section 3.3, bullet #3:
> >   3.  When a new public address is created as described in [ADDRCONF],
> >       the node SHOULD also create a new temporary address.
> >
> > * Section 3.6, for instance, says (even recommending that temp addrs
> > default to "off"):
> >   The use of temporary addresses may cause unexpected difficulties with
> >   some applications.  As described below, some servers refuse to accept
> >   communications from clients for which they cannot map the IP address
> >   into a DNS name.  In addition, some applications may not behave
> >   robustly if temporary addresses are used and an address expires
> >   before the application has terminated, or if it opens multiple
> >   sessions, but expects them to all use the same addresses.
> >   Consequently, the use of temporary addresses SHOULD be disabled by
> >   default in order to minimize potential disruptions.
> >
> >
> >
> > Our document simply requires implementations that their
> > stable addresses are RFC7721-friendly. But if anything, the requirement
> > of whether to have a stable address or not is not something introduced
> > by our document.
> >
> > As a co-author of draft-ietf-6man-default-iids, I just wanted to check
> > that we're on the same page, because I have the feeling that the above
> > keeps getting misinterpreted.
> >
> > I believe all of the co-authors of default-iids agree and understand
> > that there can be scenarios where you may want to do
> > temporary-addresses-only. However, that is orthogonal to this particular
> > document (default-iids), and would probably require an update to
> > RFC4941, such that temporary addresses can be employed as a replacement
> > of stable addresses, rather than as something that you do "in addition
> > to" them.
> >
> > This document is about how to do stable addresses in a more
> > RFC7721-friendly way than we currently do.
> >
> > Thanks!
> >
> > Best regards,
> > --
> > Fernando Gont
> > e-mail: [e-mail] || [e-mail]
> > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
>