Subject: default-iids and stable addresses

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 14:15:08 -0400

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 May 2016 10:03:09 +0900

Fernando,

your points are technically correct: from a standards perspective,
draft-default-iids makes things no worse than they are. In fact it's a mild
improvement.

However, we operate in a very different world than we did in 1996. We know
know that pervasive monitoring is a real threat, and other parts of the
IETF are explicitly working on randomizing link-layer addresses.

In such an environment, I believe this WG cannot credibly mount a major
overhaul of IPv6 IID generation rules, and simply say that privacy is "no
worse than it already was". If we mount a major overhaul (and it *is* a
major overhaul, both in terms of number of RFCs that are changed and in
terms of devices affected), we have to do better than that in addressing
the privacy concerns inherent in the existing specs.

In its current state, draft-default-iids still says that:

   - For every prefix, every host SHOULD configure addresses that never
   change - permanently, until the end of time.
   - Every link layer, past present and future, MUST define mechanisms that
   allow calculation of such per-link-permanent addresses.
   - Even though MAC address randomization is embraced by other parts of
   the IETF and explicitly dealt with in standards track RFCs, nodes SHOULD
   NOT use said random MAC addresses to form IPv6 IIDs - for no reason that I
   can see.

I don't think it's reasonable for us to make such a recommendation today.
We can and should do better than that.

Cheers,
Lorenzo

---

From: [email-masked]
Date: Wed, 18 May 2016 13:13:27 +0200

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 <[email-masked]> wrote:
> 
> Lorenzo (and wg),
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 May 2016 22:42:14 +0900

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, <[email-masked]> wrote:

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

---

From: Tim Chown <[email-masked]>
Date: Wed, 18 May 2016 13:56:39 +0000

Hi,

> On 18 May 2016, at 12:13, [email-masked] wrote:
> 

The intro to RFC 4941 section 3 says that RFC 4941 would not affect normal SLAAC operation, so you would expect a public address to be created by SLAAC. Further, section 3.3 says quite explicitly that a public address MUST be generated as per RFC 4862, and that a temporary address SHOULD also be generated.

So if we want to support having ONLY temporary addresses, I think the document will need updating. At the very best, it would be confusing to leave it as is if we want interfaces with only temporary addresses.

Personally, I would support such a change. When I last looked at the activity log for my desktop over a one month period, it showed global IPv4, LL IPv6, and many temporary IPv6 addresses in use, but there was no activity to/from the desktop’s public IPv6 address.  That’s probably not uncommon in an enterprise environment where RFC 4941 is enabled. So why require that such an address be generated?

Tim

---

From: Johanna Ullrich <[email-masked]>
Date: Wed, 18 May 2016 14:03:31 +0000

In case of an RFC 4941 update, I would further reconsider the algorithm for temporary address generation.

Concatenation of successive MD5 hashes as specified at the moment makes the privacy extension vulnerable:
An adversary could synchronize to the history value, and predict all future interface identifiers.

Best Regards,
Johanna

DI Johanna Ullrich
Researcher
http://www.sba-research.org/

Identifizierung gemäß § 14 UGB
 Firmenname: SBA Research gGmbH
 Firmensitz: Favoritenstraße 16, 1040 Wien
 Firmenbuchnummer: 345659y
 Firmenbuchgericht: Handelsgericht Wien
 DVR-Nummer: 4012257

________________________________________
Von: ipv6 <[email-masked]> im Auftrag von Tim Chown <[email-masked]>
Gesendet: Mittwoch, 18. Mai 2016 15:56
An: Ole Trøan
Cc: [email-masked]; Fernando Gont; [email-masked]
Betreff: Re: RFC4941 text on requirement for public addresses (was: Re: default-iids and stable addresses)

Hi,

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 May 2016 16:15:52 +0200

Le 18/05/2016 à 15:56, Tim Chown a écrit :
>> 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?
>
> The intro to RFC 4941 section 3 says that RFC 4941 would not affect
> normal SLAAC operation, so you would expect a public address to be
> created by SLAAC. Further, section 3.3 says quite explicitly that a
> public address MUST be generated as per RFC 4862, and that a
> temporary address SHOULD also be generated.
>
> So if we want to support having ONLY temporary addresses, I think the
> document will need updating. At the very best, it would be confusing
> to leave it as is if we want interfaces with only temporary
> addresses.
>
> Personally, I would support such a change. When I last looked at the
> activity log for my desktop over a one month period, it showed global
> IPv4, LL IPv6, and many temporary IPv6 addresses in use, but there
> was no activity to/from the desktop’s public IPv6 address.  That’s
> probably not uncommon in an enterprise environment where RFC 4941 is
> enabled. So why require that such an address be generated?

If there's no fixed address then there's no DNS name for that machine.

Updating DNS for each temporary IP address may not be that easy.

Alex

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

---

From: Tim Chown <[email-masked]>
Date: Wed, 18 May 2016 14:23:02 +0000

> On 18 May 2016, at 15:15, Alexandre Petrescu <[email-masked]> wrote:
> 

But that’s not necessarily needed. Was certainly fine without it in the campus environment I was in, where all comms initiated outbound were from privacy addresses with no associated DNS info.

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 May 2016 16:38:36 +0200

Le 18/05/2016 à 16:23, Tim Chown a écrit :
>>>> 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?
>>>
>>> The intro to RFC 4941 section 3 says that RFC 4941 would not
>>> affect normal SLAAC operation, so you would expect a public
>>> address to be created by SLAAC. Further, section 3.3 says quite
>>> explicitly that a public address MUST be generated as per RFC
>>> 4862, and that a temporary address SHOULD also be generated.
>>>
>>> So if we want to support having ONLY temporary addresses, I
>>> think the document will need updating. At the very best, it would
>>> be confusing to leave it as is if we want interfaces with only
>>> temporary addresses.
>>>
>>> Personally, I would support such a change. When I last looked at
>>> the activity log for my desktop over a one month period, it
>>> showed global IPv4, LL IPv6, and many temporary IPv6 addresses
>>> in use, but there was no activity to/from the desktop’s public
>>> IPv6 address.  That’s probably not uncommon in an enterprise
>>> environment where RFC 4941 is enabled. So why require that such
>>> an address be generated?
>>
> But that’s not necessarily needed. Was certainly fine without it in
> the campus environment I was in, where all comms initiated outbound
> were from privacy addresses with no associated DNS info.

Hmm... I guess the machine was doing the important things on IPv4 (not
IPv6)(?)

A machine w/o a DNS name is segregated, half-connected to the Internet.

It's a machine that can live with NATs.

It's a machine that can't do video-over-IP live streaming for too long.

It's a machine that can't be an ADSL box which has same IP address since
many years now.

Alex

>>>>> 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.
>>>>>
>>>>>
>>>>>  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.
>>>>>
>>>>>  Option as defined in [ADDRCONF], either creating a new
>>>>> public address or adjusting the lifetimes of existing
>>>>> addresses, both public and temporary.
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Best regards, -- Fernando Gont e-mail: [email-masked]
>>>>> || [email-masked] PGP Fingerprint: 7809 84F5 322E
>>>>> 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>>>
>>>>>
>>>>>
>>>> IETF IPv6 working group mailing list [email-masked]
>>>> Administrative Requests:

---

From: Tim Chown <[email-masked]>
Date: Wed, 18 May 2016 14:47:51 +0000

> On 18 May 2016, at 15:38, Alexandre Petrescu <[email-masked]> wrote:
> 

It’s a desktop that I used in various forms for many years, with privacy addresses on, as my day to day desktop, accessing anything offering an AAAA record by IPv6, and of course the rest by IPv4. I didn’t see any evidence of anything broken as a result.  But then I had no services on the desktop which needed to be accessed externally.

I’m not saying hosts MUST have a public address to be able to have a temporary address, but there’s no reason in many scenarios why they can’t just run with temporary addresses. I think the discussion here is about relaxing the MUST in 4941 about public addresses to a SHOULD (or MAY).

As an aside are you aware of applications that will try to use a public address in the presence of a temporary one?  

RFC 6724 is quite explicit about this now:

Rule 7: Prefer temporary addresses.
   If SA is a temporary address and SB is a public address, then prefer
   SA.  Similarly, if SB is a temporary address and SA is a public
   address, then prefer SB.

Tim

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 May 2016 17:53:38 +0200

Le 18/05/2016 à 16:47, Tim Chown a écrit :
>>>>>> 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?
>>>>>
>>>>>  address to be created by SLAAC. Further, section 3.3 says
>>>>> quite explicitly that a public address MUST be generated as
>>>>> per RFC 4862, and that a temporary address SHOULD also be
>>>>> generated.
>>>>>
>>>>> think the document will need updating. At the very best, it
>>>>> would be confusing to leave it as is if we want interfaces
>>>>> Personally, I would support such a change. When I last
>>>>> looked at the activity log for my desktop over a one month
>>>>> period, it showed global IPv4, LL IPv6, and many temporary
>>>>> IPv6 addresses in use, but there was no activity to/from the
>>>>> desktop’s public IPv6 address.  That’s probably not uncommon
>>>>> in an enterprise environment where RFC 4941 is enabled. So
>>>>> why require that such an address be generated?
>>>>
>>> But that’s not necessarily needed. Was certainly fine without it
>>> in the campus environment I was in, where all comms initiated
>>> outbound were from privacy addresses with no associated DNS
>>> info.
>>
>> Hmm... I guess the machine was doing the important things on IPv4
>> (not IPv6)(?)
>>
>> It's a machine that can't be an ADSL box which has same IP address
>> since many years now.
>
> It’s a desktop that I used in various forms for many years, with
> privacy addresses on, as my day to day desktop, accessing anything
> offering an AAAA record by IPv6, and of course the rest by IPv4. I
> didn’t see any evidence of anything broken as a result.  But then I
> had no services on the desktop which needed to be accessed
> externally.
>
> I’m not saying hosts MUST have a public address to be able to have a
> temporary address, but there’s no reason in many scenarios why they
> can’t just run with temporary addresses.

It very much depends on what the application is about.

An html browsing application will only need bursts of data exchange,
maybe each issued from distinct IP address, that may change every second.

But an ftp transferring an Ultra-HD Bluray on a cellular link may need
an address to last for many hours; please dont change that!

> I think the discussion here is about relaxing the MUST in 4941 about
> public addresses to a SHOULD (or MAY).

I am tempted to say "SHOULD" rather than "MAY".

But I also worry that the perspective may be wrong altogether.

Until now applications assumed the IP address is fixed stable.  Efforts 
like Mobile IP tried to accommodate network-induced variation in that IP 
address.

Now we say privacy is important, and so we want the address to change. 
This looks strange.

> As an aside are you aware of applications that will try to use a
> public address in the presence of a temporary one?

No, I am not aware.  I guess you are?

I think applications should not request some kind of IP address - that 
may be layer violation.  Applications should use application-layer 
identifiers.

Let me diverge on an argument - over in DMM WG, there is a developping 
perspective in which the application _does_ require the kind of IP 
address to use (stable, transient, etc.)  In this perspective the 
cellular network operator provides a Static IP address if the UE 
application requests one (e.g. "Static" in 
https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-addressing.jsp) 

If the network offers a Static ("stable", "fixed") IP address to the 
node, will the node refuse it?  I doubt so, because the operator thinks 
(see that web page) that the end user is even ready to pay money for 
that Static address - i.e. there is value in a Static address.

So the perspective in this RFC4941 (there is no value in a static 
address) is contradictory to some operator's interests.

I think this contradiction stems from the ability of an application to 
require some particular kind network-layer identifier (IP address) - 
layer violation.

Privacy is an application matter: "this site uses cookies, do you agree"

Privacy is not an IP matter: unreadable address, return to sender

> Rule 7: Prefer temporary addresses. If SA is a temporary address and
> SB is a public address, then prefer SA.  Similarly, if SB is a
> temporary address and SA is a public address, then prefer SB.

I take this as such out of the RFC.

There are multiple problems with 'public' and 'temporary' address terms 
in IPv6 addressing.

First, 'public' and 'temporary' addresses are not disjoint.  It's not 
like in IPv4, where a public IPv4 address is disjoint from private IPv4 
address (1.1.1.1 vs 192.168.1.1).  An IPv6 'temporary' address can very 
well be a GUA.

Second, there is a pitfall in assuming that a 'temporary' changing IPv6 
address offers more privacy than a 'public' stable IPv6 address.  True, 
it changes more often than a 'public', but the surveillant still sees it 
(even if it is not called 'public') and may adapt to change too - keep a 
list keyed on some other stable identifier; each identifier in 
draft-ietf-intarea-hostname-practice-02, plus the unique prefix 
delivered by cellular operator to user terminal, plus more in link-layer 
messaging.  We couldnt randomize each of these, right?

Alex

>>>>>>>  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.
>>>>>>>
>>>>>>>
>>>>>>> requirements on the topic. Essentially, nodes are
>>>>>>> implied to configure a stable addresses as a result of
>>>>>>> * 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
>>>>>>> * 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> wanted to check that we're on the same page, because I
>>>>>>> have the feeling that the above keeps getting
>>>>>>> misinterpreted.
>>>>>>>
>>>>>>> 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
>>>>>>> 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:
>>>>>>> [email-masked] || [email-masked] PGP
>>>>>>> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF
>>>>>>> D076 FFF1
>>>>>>>
>>>>>>>
>>>>>>>

---

From: Tim Chown <[email-masked]>
Date: Wed, 18 May 2016 16:07:53 +0000

> On 18 May 2016, at 16:53, Alexandre Petrescu <[email-masked]> wrote:
> 

Right. And the default address refresh on most OSes is 24 hours.

> I am tempted to say "SHOULD" rather than "MAY”.

Agreed.

> Until now applications assumed the IP address is fixed stable.  Efforts like Mobile IP tried to accommodate network-induced variation in that IP address.
> 
> Now we say privacy is important, and so we want the address to change. This looks strange.

We should be supporting privacy. Whether by changing MAC addresses or IP addresses over time.  Both concepts are ‘strange’ to those familiar with the practices of the past 20+ years.

> No, I am not aware.  I guess you are?

No, I’m not, in theory RFC 6724 should avoid it.

> I think applications should not request some kind of IP address - that may be layer violation.  Applications should use application-layer identifiers.
> 
> Let me diverge on an argument - over in DMM WG, there is a developping perspective in which the application _does_ require the kind of IP address to use (stable, transient, etc.)  In this perspective the cellular network operator provides a Static IP address if the UE application requests one (e.g. "Static" in https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-addressing.jsp) 
> 
> If the network offers a Static ("stable", "fixed") IP address to the node, will the node refuse it?  I doubt so, because the operator thinks (see that web page) that the end user is even ready to pay money for that Static address - i.e. there is value in a Static address.

And I’d agree that this mode should be supported when required. It’s a trade-off.

> 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. I don’t think we need to widen the discussion - if you want to do that, the default-iids WGLC thread is probably the place to do so...

> I think this contradiction stems from the ability of an application to require some particular kind network-layer identifier (IP address) - layer violation.
> 
> There are multiple problems with 'public' and 'temporary' address terms in IPv6 addressing.
> 
> First, 'public' and 'temporary' addresses are not disjoint.  It's not like in IPv4, where a public IPv4 address is disjoint from private IPv4 address (1.1.1.1 vs 192.168.1.1).  An IPv6 'temporary' address can very well be a GUA.
> 
> Second, there is a pitfall in assuming that a 'temporary' changing IPv6 address offers more privacy than a 'public' stable IPv6 address.  True, it changes more often than a 'public', but the surveillant still sees it (even if it is not called 'public') and may adapt to change too - keep a list keyed on some other stable identifier; each identifier in draft-ietf-intarea-hostname-practice-02, plus the unique prefix delivered by cellular operator to user terminal, plus more in link-layer messaging.  We couldnt randomize each of these, right?

Well, there’s also, as I’m sure Lorenzo would point out, the option to run SLAAC with underlying dynamic MAC addresses.  Which I think is a perfectly valid mode, though default-iids seems to be saying it isn't. Is that then formally a public or temporary address?

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.

Tim

---

From: Dave Thaler <[email-masked]>
Date: Wed, 18 May 2016 16:45:25 +0000

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:[email-masked]]
Sent: Wednesday, May 18, 2016 9:42 AM
To: Ole Troan <[email-masked]>
Cc: [email-masked]; Fernando Gont <[email-masked]>; [email-masked]
Subject: Re: RFC4941 text on requirement for public addresses (was: Re: default-iids and stable addresses)

       If a received

On Wed, May 18, 2016 at 8:13 PM, <[email-masked]<mailto:[email-masked]>> wrote:
This email from Fernando provides a good introduction to an outstanding question from Buenos Aires.

Opinions?

Best regards,
Ole

> On 17 May 2016, at 20:15, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
>
> Lorenzo (and wg),
>
> e-mail: [email-masked]<mailto:[email-masked]> || [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 May 2016 11:09:57 -0700

At Tue, 17 May 2016 14:15:08 -0400,

> 2) The requirement to have stable addresses

[...]

> keeps getting misinterpreted.

Misinterpretation (I'd call it confusion in this context, though) of a
document often happens because the document isn't clear enough, rather
than because there's an issue at the readers' side (as the wording
"getting misinterpreted" seems to indicate).  And I think that's
actually what's happening for this document right now.  In fact, it's
not clear at least to me from the current draft how it answers the
above two points.  Its current vagueness may come from attempts of
addressing previous controversy, but, for this fresh reader of the
document, the resulting text is very confusing.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 May 2016 11:31:23 +1200

...
> But that’s not necessarily needed. Was certainly fine without it in the campus environment I was in, where all comms initiated outbound were from privacy addresses with no associated DNS info.

I just experimented at home, with privacy addressing enabled and my SLAAC-assigned address
deleted manually(*). As far as I can see everything works as normal so far. Why wouldn't
it? DNS names are pointless for pure clients, for IPv-anything.

* netsh interface ipv6 del address 12 <address> active
I can't find a way in Windows to simply switch SLAAC off without
defining a static address.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 May 2016 09:28:06 +0900

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 <[email-masked]> wrote:

> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Wednesday, May 18, 2016 9:42 AM
> *To:* Ole Troan <[email-masked]>
> *Cc:* [email-masked]; Fernando Gont <[email-masked]>;
> [email-masked]
> *Subject:* Re: RFC4941 text on requirement for public addresses (was: Re:
> default-iids and stable addresses)
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 May 2016 10:49:28 +0900

On Thu, May 19, 2016 at 3:09 AM, 神明達哉 <[email-masked]> wrote:

> document often happens because the document isn't clear enough

+1

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 May 2016 09:10:01 +0200

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

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

>>>>>>>>> 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
>>>>>>>>> * Section 3, bullet #1: 2.  Create additional
>>>>>>>>> addresses based on a random interface identifier for
>>>>>>>>> the purpose of initiating outgoing sessions.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> This document is about how to do stable addresses in
>>>>>>>>> a more RFC7721-friendly way than we currently do.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>

---

From: Tim Chown <[email-masked]>
Date: Thu, 19 May 2016 10:36:05 +0000

On 19 May 2016, at 02:49, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

+1

I agree that it’s at best ambiguous.

Section 3 says:

"1. Do not result in any changes to the basic behavior of addresses

       generated via stateless address autoconfiguration [ADDRCONF<https://tools.ietf.org/html/rfc4941#ref-ADDRCONF>].

which implies that SLAAC still runs as normal, so you get a public address from that, and

2.  Create additional addresses based on a random interface
       identifier for the purpose of initiating outgoing sessions."

which implies the temporary address is *in addition* to the SLAAC-derived address, unless you hold the “Take some more tea Alice” view of additional.

Then 3.1 says:

"[ADDR_SELECT<https://tools.ietf.org/html/rfc4941#ref-ADDR_SELECT>] mandates implementations to provide a mechanism, which

   allows an application to configure its preference for temporary
   addresses over public addresses.“

which implies both are configured.

And then section 3.3 says the node MUST:

"Process the Prefix Information Option as defined in [ADDRCONF<https://tools.ietf.org/html/rfc4941#ref-ADDRCONF>]
either creating a new public address or adjusting the lifetimes

       of existing addresses, both public and temporary.“

So there’s a lot of text implying temporary addresses are used alongside public ones, and thus that ambiguity should be clarified.

But again I agree we should make it clear that that need not be the case.

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 19 May 2016 10:46:31 +0000

Apologies, this was pasted to the wrong thread :)

Tim

On 19 May 2016, at 11:36, Tim Chown <[email-masked]<mailto:[email-masked]>> wrote:

+1

Section 3 says:

Then 3.1 says:

Tim

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 May 2016 20:32:00 -0400

On 05/17/2016 09:03 PM, Lorenzo Colitti wrote:
> draft-default-iids makes things no worse than they are. In fact it's a
> mild improvement.

It makes things way better. It is a god way to produce stable addresses
for those scenarios in which you need them. It mitigates network
tracking, address scanning, and device speific attacks.

> However, we operate in a very different world than we did in 1996. We
> know know that pervasive monitoring is a real threat, and other parts of
> the IETF are explicitly working on randomizing link-layer addresses.
> 
> overhaul of IPv6 IID generation rules, and simply say that privacy is
> "no worse than it already was".

Huh?

This document just says "if you need stable addresses, use RFC7217".
That's it.

> If we mount a major overhaul (and it
> *is* a major overhaul, both in terms of number of RFCs that are changed
> and in terms of devices affected), we have to do better than that in
> addressing the privacy concerns inherent in the existing specs.
> 
>   * For every prefix, every host SHOULD configure addresses that never

No. The document says t very clearly, up front, that you do this just in
scenarios where you would be generating stable addresses.

>   * Every link layer, past present and future, MUST define mechanisms
>     that allow calculation of such per-link-permanent addresses.

Yes. Because you cannot tell beforehand if an ap or environment using
that link-layer technology will need/require stable address. -- that's
an operational decision.

>   * Even though MAC address randomization is embraced by other parts of
>     the IETF and explicitly dealt with in standards track RFCs, nodes
>     SHOULD NOT use said random MAC addresses to form IPv6 IIDs - for no
>     reason that I can see.

I referenced the same I-D a hundred of times, already:
draft-gont-predictable-numeric-ids

Please also the discussion on identifiers in RFC4941.

After reading those two documents, could you please tell me what's still
not clear?

(FWIW, I've posted a summary of the issues a number of times, already).

And again: I'm all for link-layer address randomization. I'm not for
embedding a link-layer ID in an IPv6 IID. The above two documents
explain why, and Brian Carpenter has provided yet another explanation
and sample scenario.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 May 2016 20:33:19 -0400

>     change - permanently, until the end of time.

We noted a lot of times that that is not the case. Could you please
quote the text in default-iids that requires this?