Re: RFC4941 text on requirement for public addresses

[Alexandre Petrescu <[e-mail]>]

Le 18/05/2016 à 18:07, Tim Chown a écrit :
[...]

>> So the perspective in this RFC4941 (there is no value in a static
>> address) is contradictory to some operator's interests.
>
> All we’re discussing here (I think!) is whether 4941 should be
> changed to no longer say that SLAAC is a MUST, so that we open the
> possibility for a node to use temporary addresses only.

In practice the SLAAC is not a MUST.  There are many IPv6 computers 
which dont SLAAC - they DHCPv6, or manually configure, or use only LLs.

[...]

> But let’s focus on the topic Ole opened - should 4941 change the
> requirement for a public address from a MUST to something less, i.e.
> SHOULD, so we can very clearly support a mode where nodes can have
> just temporary addresses and no public address.

Is the Ole's SHOULD/MUST topic on public address use?  Or on SLAAC use?

Alex
(also, nit: may update RFC4941 to no longer say 'privacy addresses'
  on its pp. 12).

>
> Tim
>
>>
>> Alex
>>
>>
>>>
>>> Tim
>>>
>>>> Alex
>>>>
>>>>>
>>>>> Tim
>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>>> 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
>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>>>>>>>>>
>>>>>>>>>
>>
>>>>>>>>>
--------------------------------------------------------------------
>>>>>>>> IETF IPv6 working group mailing list [e-mail]
>>>>>>>> Administrative Requests:
>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>> --------------------------------------------------------------------
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>>>>>>
>>>>>>>>
>>
>>>>>>>>
--------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list [e-mail]
>>>>>>> Administrative Requests:
>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>>>>>>
--------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list [e-mail]
>>>>>> Administrative Requests:
>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>
>>>>>>
>