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

[Dave Thaler <[e-mail]>]

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]> || [e-mail]<mailto:[e-mail]>
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------