Subject: [rtcweb] Transports: RFC 4941 support?

From: Justin Uberti <[email-masked]>
Date: Tue, 18 Mar 2014 18:00:02 -0700

https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6
addresses. For, example, as enumerated on my local system:

inet 172.31.x.y netmask 0xfffffe00 broadcast 172.31.x.255
inet6 2620::1008:100b:e2f8:47ff:wwww:xxxx prefixlen 64 autoconf
inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf *temporary *

As indicated in the RFC, the temporary addresses expire after hours or
days, and therefore could be used to prevent long-term linkability of
sessions. Expiration shouldn't be an issue for WebRTC, since we can simply
do ICE restart if this occurs during a session.

Is this something we want to recommend in the transports doc?

---

From: Dan Wing <[email-masked]>
Date: Tue, 18 Mar 2014 22:14:00 -0700

On Mar 18, 2014, at 6:00 PM, Justin Uberti <[email-masked]> wrote:

> https://tools.ietf.org/html/rfc4941 defines the concept of temporary IPv6 addresses. For, example, as enumerated on my local system:
> 
> inet6 2620::1008:100b:819e:1d3f:yyyy:zzzz prefixlen 64 autoconf temporary 
> 
> As indicated in the RFC, the temporary addresses expire after hours or days, and therefore could be used to prevent long-term linkability of sessions. Expiration shouldn't be an issue for WebRTC, since we can simply do ICE restart if this occurs during a session.
> 

Yes.

And it should be as frequent as every new 'call', if IPv6 privacy addresses are to provide the same privacy as a NAPT44, as a NAPT44 should be assigning random ports per reasons described in RFC6056.

The transport document should also recommend doing port randomization (RFC6056), as that was found pretty useful for DNS, but randomizing ports is still not popular with many OS's TCP stacks for whatever reason.

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Mar 2014 08:02:31 +0100

I'd like to be silent on the issue, since which IPv6 addresses to prefer is
likely to be a matter of system policy. Trying to override system policy in
an application specific profile usually leads to sadness.

On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <[email-masked]> wrote:

> And it should be as frequent as every new 'call', if IPv6 privacy
> addresses are to provide the same privacy as a NAPT44, as a NAPT44 should
> be assigning random ports per reasons described in RFC6056.
>
> The transport document should also recommend doing port randomization
> (RFC6056), as that was found pretty useful for DNS, but randomizing ports
> is still not popular with many OS's TCP stacks for whatever reason.
>
> -d
>
>
>

---

From: Dan Wing <[email-masked]>
Date: Wed, 19 Mar 2014 08:08:09 -0700

On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <[email-masked]> wrote:

> I'd like to be silent on the issue, since which IPv6 addresses to prefer is likely to be a matter of system policy. Trying to override system policy in an application specific profile usually leads to sadness.

The application needs to indicate if it wants a temporary address. If the host's policy (or configuration or network) does not support temporary addresses, the application won't get a temporary address.  I don't see why being silent helps?

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Mar 2014 16:21:59 +0100

On 03/19/2014 04:08 PM, Dan Wing wrote:
>
> On Mar 19, 2014, at 12:02 AM, Harald Alvestrand <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I'd like to be silent on the issue, since which IPv6 addresses to 
>> prefer is likely to be a matter of system policy. Trying to override 
>> system policy in an application specific profile usually leads to 
>> sadness.
>
> The application needs to indicate if it wants a temporary address. If 
> the host's policy (or configuration or network) does not support 
> temporary addresses, the application won't get a temporary address.  I 
> don't see why being silent helps?

What API is it using?

With a little Googling, the system policy I was thinking of was the 
policy in RFC 6724 ("Default Address Selection for IPv6"), in particular 
section 5 rule 7: "Prefer  temporary addresses".

I'm happy to say "it is a good idea for systems to implement the 
recommendations of RFC 6724" (or some more 2119-like language). I 
wouldn't want to claim that if a system has chosen to prefer 
non-temporary addresses, it would have to change its non-conformance to 
RFC 6724 in order to be conformant with RTCWEB specifications.

>
> -d
>
>
>>
>>
>>
>> On Wed, Mar 19, 2014 at 6:14 AM, Dan Wing <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>     On Mar 18, 2014, at 6:00 PM, Justin Uberti <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>>     https://tools.ietf.org/html/rfc4941 defines the concept of
>>>     temporary IPv6 addresses. For, example, as enumerated on my
>>>     local system:
>>>
>>>     As indicated in the RFC, the temporary addresses expire after
>>>     hours or days, and therefore could be used to prevent long-term
>>>     linkability of sessions. Expiration shouldn't be an issue for
>>>     WebRTC, since we can simply do ICE restart if this occurs during
>>>     a session.
>>>
>>     addresses are to provide the same privacy as a NAPT44, as a
>>     NAPT44 should be assigning random ports per reasons described in
>>     RFC6056.
>>
>>     The transport document should also recommend doing port
>>     randomization (RFC6056), as that was found pretty useful for DNS,
>>     but randomizing ports is still not popular with many OS's TCP
>>     stacks for whatever reason.
>>
>>     -d
>>
>>
>>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Mar 2014 11:39:03 -0400

Le 2014-03-19 03:02, Harald Alvestrand a écrit :
> I'd like to be silent on the issue, since which IPv6 addresses to prefer
> is likely to be a matter of system policy. Trying to override system
> policy in an application specific profile usually leads to sadness.

What would be useful to mention IMHO is that ICE restart should be used
to gracefully handle the issue of IP address expiry, of which temporary
IPv6 addresses are a frequently-encountered example.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Mar 2014 11:41:46 -0400

> RFC 6724 in order to be conformant with RTCWEB specifications.

IMHO it would be perfectly sensible to recommend the use of
IPV6_PREFER_SRC_TMP [RFC5014].

Simon

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Mar 2014 09:08:49 -0700

ICE by default is going to gather host candidates from all interfaces,
which means that the non-temporary addresses are going to be used,
regardless of priority, for connectivity checks at least.

As a result, if we don't do anything, it means 2x the v6 interfaces, and 4x
the v6-v6 ICE checks, in addition to any linkability concerns.

We could say that if a system has chosen to prefer non-temporary-addresses,
or privacy is not a concern, then non-temporary-addresses can be used.

On Wed, Mar 19, 2014 at 8:21 AM, Harald Alvestrand <[email-masked]>wrote:

> is likely to be a matter of system policy. Trying to override system policy
> in an application specific profile usually leads to sadness.
>
>
> the host's policy (or configuration or network) does not support temporary
> addresses, the application won't get a temporary address.  I don't see why
> being silent helps?
>
>
> What API is it using?
>
> With a little Googling, the system policy I was thinking of was the policy
> in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5
> rule 7: "Prefer  temporary addresses".
>
> recommendations of RFC 6724" (or some more 2119-like language). I wouldn't
> want to claim that if a system has chosen to prefer non-temporary
> addresses, it would have to change its non-conformance to RFC 6724 in order
> to be conformant with RTCWEB specifications.
>
>
>  -d
>
>
>
>
>
>>  https://tools.ietf.org/html/rfc4941 defines the concept of temporary
>> IPv6 addresses. For, example, as enumerated on my local system:
>>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Mar 2014 13:43:47 -0700

(and, to be clear, that by default, non-temporary addresses SHOULD NOT be
used by clients)

On Wed, Mar 19, 2014 at 9:08 AM, Justin Uberti <[email-masked]> wrote:

> As a result, if we don't do anything, it means 2x the v6 interfaces, and
> 4x the v6-v6 ICE checks, in addition to any linkability concerns.
>
> We could say that if a system has chosen to prefer
> non-temporary-addresses, or privacy is not a concern, then
> non-temporary-addresses can be used.
>
>
>> prefer is likely to be a matter of system policy. Trying to override system

---

From: Dan Wing <[email-masked]>
Date: Thu, 20 Mar 2014 07:52:58 -0700

On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <[email-masked]> wrote:

> With a little Googling, the system policy I was thinking of was the policy in RFC 6724 ("Default Address Selection for IPv6"), in particular section 5 rule 7: "Prefer  temporary addresses".
> 
> I'm happy to say "it is a good idea for systems to implement the recommendations of RFC 6724" (or some more 2119-like language). I wouldn't want to claim that if a system has chosen to prefer non-temporary addresses, it would have to change its non-conformance to RFC 6724 in order to be conformant with RTCWEB specifications.

So perhaps:
   "An RTCWEB implementation SHOULD prefer to use temporary addresses [RFC4941] where host and network policy permit [RFC6724]."
?

-d

---

From: Dan Wing <[email-masked]>
Date: Thu, 20 Mar 2014 07:54:08 -0700

> IPv6 addresses are a frequently-encountered example.

When a temporary address expires, existing sockets bound that address should continue working with that expired address -- have you found otherwise on any OS, such that we would need ICE Mobility for temporary address expiration?

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Mar 2014 11:51:43 -0400

> When a temporary address expires, existing sockets bound that address should continue working with that expired address -- have you found otherwise on any OS, such that we would need ICE Mobility f…

When the address is removed from the interface, it doesn't matter if the
socket is still "good" or not. The address is no longer on the interface
so you will not receive packets sent to that address.

I'm looking at the Linux and OpenBSD IPv6 stacks right now and neither
seems to care about existing sockets before expiring an address. Haven't
tried it though.

Simon

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Mar 2014 09:30:08 -0700

On Thu, Mar 20, 2014 at 8:51 AM, Simon Perreault <
[email-masked]> wrote:

> prefer
> > When a temporary address expires, existing sockets bound that address
> should continue working with that expired address -- have you found
> otherwise on any OS, such that we would need ICE Mobility for temporary
> address expiration?
>
On Mac, the temporary addresses seem to change every day, but any existing
addresses seem to remain valid for a week.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Mar 2014 09:34:35 -0700

On Thu, Mar 20, 2014 at 7:52 AM, Dan Wing <[email-masked]> wrote:

> The application needs to indicate if it wants a temporary address. If the
> host's policy (or configuration or network) does not support temporary
>    "An RTCWEB implementation SHOULD prefer to use temporary addresses
> [RFC4941] where host and network policy permit [RFC6724]."
> ?
>

I think it needs to be stronger than that - something like
"where host and network policy permit, RTCWEB implementations SHOULD gather
IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses".

Preferring to use temporary addresses is probably not sufficient to prevent
linkage, since you will have connectivity checks from the non-temporary
addresses. (i.e. an eavesdropper listening over an extended period of time
could determine calls are from the same endpoint)

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Mar 2014 12:58:19 -0400

Le 2014-03-20 12:30, Justin Uberti a écrit :
> On Mac, the temporary addresses seem to change every day, but any
> existing addresses seem to remain valid for a week. 

Correct. Addresses go from "preferred and valid" (one day) to "valid"
(one week) to "invalid". The address is removed from the interface when
it becomes invalid. So in theory you would need to use WebRTC for a
whole week before an temporary address is yanked from under your feet.

Simon

---

From: Dan Wing <[email-masked]>
Date: Thu, 20 Mar 2014 10:07:58 -0700

On Mar 20, 2014, at 9:34 AM, Justin Uberti <[email-masked]> wrote:

> "where host and network policy permit, RTCWEB implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses".
> 
> Preferring to use temporary addresses is probably not sufficient to prevent linkage, since you will have connectivity checks from the non-temporary addresses. (i.e. an eavesdropper listening over an extended period of time could determine calls are from the same endpoint)

Agreed.  I like your suggested wording.

-d

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Mar 2014 13:56:04 -0700

On Thu, Mar 20, 2014 at 10:07 AM, Dan Wing <[email-masked]> wrote:

> "where
> host and network policy permit, RTCWEB implementations SHOULD gather IPv6
> temporary addresses and SHOULD NOT gather non-temporary addresses".
>
> Preferring to use temporary addresses is probably not sufficient to
> prevent linkage, since you will have connectivity checks from the
> non-temporary addresses. (i.e. an eavesdropper listening over an extended
> period of time could determine calls are from the same endpoint)
>
>
So, I note that in this case where a non-temporary IPv6 address is present
and  no temporary IPv6 address is present, this appears to push IPv6 out of
the gathered list completely.  If I have that right, then my view as an
individual is that this is the wrong result.  It will either force the use
of IPv4 addresses which are just as linkable as IPv6 non-temporary
addresses or rely on NATs to get the non-linkability (and provide us all
the other subtle joys of NAT).

As a friendly amendment, may I suggest "Where both non-temporary and
temporary addresses are present and host and network policy permit, RTCWEB
implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT
gather non-temporary addresses"?

I also confess to a suspicion that Harald's view is the most
sensible--having a separate policy for this application either won't happen
or doesn't make much sense.  But if we have one, I'd prefer one that
doesn't shove IPv6 out the door completely if the host doesn't use
temporary addresses.

regards,

Ted

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Mar 2014 16:03:52 -0700

Your take is what I had in mind. Basically a ruleset like this:

 gather_ipv4_addresses();
 if (has_ipv6) {
  if (has_temporary_addresses && temporaries_not_forbidden_by_policy) {
    gather_temporary_ipv6_addresses();
  } else {
    gather_non_temporary_ipv6_addresses();
 }
}

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Mar 2014 19:17:50 -0400

>     gather_non_temporary_ipv6_addresses();
What should be done when temporary enabled only on some of the network
interfaces of the device, i.e. if, for instance, WiFI interface has only
non temp ipv6 address and LTE has both temp and permanent address present?
_____________
Roman Shpount

---

From: Dan Wing <[email-masked]>
Date: Thu, 20 Mar 2014 17:08:08 -0700

On Mar 20, 2014, at 1:56 PM, Ted Hardie <[email-masked]> wrote:

> So, I note that in this case where a non-temporary IPv6 address is present and  no temporary IPv6 address is present, this appears to push IPv6 out of the gathered list completely.  If I have that right, then my view as an individual is that this is the wrong result.  It will either force the use of IPv4 addresses which are just as linkable as IPv6 non-temporary addresses or rely on NATs to get the non-linkability (and provide us all the other subtle joys of NAT). 
> 
> As a friendly amendment, may I suggest "Where both non-temporary and temporary addresses are present and host and network policy permit, RTCWEB implementations SHOULD gather IPv6 temporary addresses and SHOULD NOT gather non-temporary addresses"?
> 
> I also confess to a suspicion that Harald's view is the most sensible--having a separate policy for this application either won't happen or doesn't make much sense. 

Ok, so preface your suggested sentence with,

  “WebRTC applications are encouraged to follow IPv6 Socket API for Source Address Selection [RFC5014] with regards to IPv6 temporary addresses, specifically <insert your sentence>.”

It’s not that WebRTC is trying to do something unique here — we just want this done, and not just hope an implementor stumbles into the right IETF document explaining temporary IPv6 addresses.

-d

> But if we have one, I'd prefer one that doesn't shove IPv6 out the door completely if the host doesn't use temporary addresses.
> 
> regards,
> 
> Ted

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Mar 2014 17:28:16 -0700

> non temp ipv6 address and LTE has both temp and permanent address present?
Is this a real-world problem? As I understand it, temporary addresses are
assigned by the host, so you either support them or you don't.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Mar 2014 22:39:38 -0400

On Thu, Mar 20, 2014 at 8:28 PM, Justin Uberti <[email-masked]> wrote:

>> On Thu, Mar 20, 2014 at 7:03 PM, Justin Uberti <[email-masked]>wrote:
>>

On Linux you can enable temporary addresses per interface, so it is
possible.

The whole problem (with using temp or permanent addresses) is a bit
imaginary since under most common client setups you only see temporary
addresses. Permanent IPv6 addresses show up only on servers or if
specifically configured on the host.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Mar 2014 21:12:59 -0700

OK. Perhaps the guidance should be that if an interface has a temporary and
a non-temporary address, only the temporary one should be gathered. This
avoids any problems if local policy chooses not to use temporary addresses.

FWIW, I have seen this setup where a client has both non-temporary and
temporary addresses in the wild, so this is a real-world problem.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 21 Mar 2014 07:59:25 +0100

On 21 Mar 2014, at 01:28, Justin Uberti <[email-masked]> wrote:

> What should be done when temporary enabled only on some of the network interfaces of the device, i.e. if, for instance, WiFI interface has only non temp ipv6 address and LTE has both temp and permanent address present?
> 
>  
> Is this a real-world problem? As I understand it, temporary addresses are assigned by the host, so you either support them or you don't.

There is a way to get them from a DHCP server.
http://tools.ietf.org/html/rfc3315#section-12

/O

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 21 Mar 2014 09:15:50 +0100

On 03/20/2014 03:52 PM, Dan Wing wrote:
>
> On Mar 19, 2014, at 8:21 AM, Harald Alvestrand <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>>> prefer is likely to be a matter of system policy. Trying to
>>>> override system policy in an application specific profile usually
>>>> leads to sadness.
>>>
>>> The application needs to indicate if it wants a temporary address.
>>> If the host's policy (or configuration or network) does not support
>>> temporary addresses, the application won't get a temporary address.
>>>  I don't see why being silent helps?
>>
>> What API is it using?
>>
>> policy in RFC 6724 ("Default Address Selection for IPv6"), in
>> particular section 5 rule 7: "Prefer  temporary addresses".
>>
>> non-temporary addresses, it would have to change its non-conformance
>> to RFC 6724 in order to be conformant with RTCWEB specifications.
>
> So perhaps:
Or even be more explicit on what's being proposed:

"When a client gathers all IPv6 addresses on a host, and both temporary
addresses [RFC4941] and permanent addresses of the same scope are
present, the client SHOULD discard the permanent addresses before
forming pairs. This is consistent with the default policy described in
[RFC6724]."

Pulling back a little, I am starting to wonder if this is an ICE concern
rather than an RTCWEB concern. The explosion in candidate pairs as more
transport / network options come on line is a real operational problem,
and needs to be solved for all ICE usages.

I'll stick something in -transport, but RTCWEB is not the only thing
that will have this problem.

>>>>>     hours or days, and therefore could be used to prevent
>>>>>     long-term linkability of sessions. Expiration shouldn't be an
>>>>>     issue for WebRTC, since we can simply do ICE restart if this
>>>>>     occurs during a session.
>>>>>
>>>>     And it should be as frequent as every new 'call', if IPv6
>>>>     privacy addresses are to provide the same privacy as a NAPT44,
>>>>     as a NAPT44 should be assigning random ports per reasons
>>>>     described in RFC6056.
>>>>
>>>>     randomization (RFC6056), as that was found pretty useful for
>>>>     DNS, but randomizing ports is still not popular with many OS's
>>>>     TCP stacks for whatever reason.
>>>>
>>>>     -d
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> [email-masked] <mailto:[email-masked]>

-- 
Surveillance is pervasive. Go Dark.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 21 Mar 2014 12:14:20 +0100

> IPV6_PREFER_SRC_TMP [RFC5014].
Interesting: This rule was reversed from 3484 to 6724 - 3484 preferred 
public, 6724 prefers temporary. 5014 claims that the default is 
PREFER_SRC_PUBLIC, which is not 6724 conformant. And RFC 5245 (ICE) 
contains a pointer to RFC 3484, recommending its use in address selection.

With this amount of misleading stuff in RFCs, I think it's best to say 
something after all.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 21 Mar 2014 08:27:12 -0700

On Fri, Mar 21, 2014 at 1:15 AM, Harald Alvestrand <[email-masked]>wrote:

> addresses [RFC4941] and permanent addresses of the same scope are present,
> the client SHOULD discard the permanent addresses before forming pairs.
> This is consistent with the default policy described in [RFC6724]."
>

The permanent addresses need to be discarded before sending them to the
remote side (which happens before pairing). I would simply say that the
permanent addresses should be ignored.

> transport / network options come on line is a real operational problem, and
> needs to be solved for all ICE usages.
>
> I'll stick something in -transport, but RTCWEB is not the only thing that
> will have this problem.
>
>
>
>
>  -d
>
>
>
>
>  -d
>
>
>
>
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Mar 2014 09:07:33 -0700

> specifically configured on the host.

It's actually not imaginary in enterprise contexts, as there are shops
that disable temporary addresses to make tracking or other security
activities easier.  Not my favorite reasoning, personally, but there you go.

Ted

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Mar 2014 13:10:14 -0400

> activities easier.  Not my favorite reasoning, personally, but there you go.

What I meant is situation where you have both temp and permanent addresses
on the same interface is quite unusual. In most cases it is one or the
other. Getting both addresses configured usually requires some very
deliberate administrative action, and unless I am mistaken, is not common.
_____________
Roman Shpount

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 21 Mar 2014 17:28:42 +0000

>>What I meant is situation where you have both temp and permanent addresses on the same interface

This is a default for interfaces of Windows computers, using SLAAC.

________________________________
From: rtcweb <[email-masked]> on behalf of Roman Shpount <[email-masked]>
Sent: Friday, March 21, 2014 10:10 AM
To: Ted Hardie
Cc: [email-masked]
Subject: Re: [rtcweb] Transports: RFC 4941 support?

On Fri, Mar 21, 2014 at 12:07 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
The whole problem (with using temp or permanent addresses) is a bit imaginary since under most common client setups you only see temporary addresses. Permanent IPv6 addresses show up only on servers or if specifically configured on the host.

It's actually not imaginary in enterprise contexts, as there are shops that disable temporary addresses to make tracking or other security activities easier.  Not my favorite reasoning, personally, but there you go.

What I meant is situation where you have both temp and permanent addresses on the same interface is quite unusual. In most cases it is one or the other. Getting both addresses configured usually requires some very deliberate administrative action, and unless I am mistaken, is not common.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Mar 2014 12:21:09 -0700

On 21 March 2014 09:07, Ted Hardie <[email-masked]> wrote:
> It's actually not imaginary in enterprise contexts, as there are shops that
> disable temporary addresses to make tracking or other security activities
> easier.  Not my favorite reasoning, personally, but there you go.

Yeah, that's what super-cookies are for.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 22 Mar 2014 21:23:17 +0100

On 03/21/2014 06:10 PM, Roman Shpount wrote:
>         The whole problem (with using temp or permanent addresses) is
>         a bit imaginary since under most common client setups you only
>         see temporary addresses. Permanent IPv6 addresses show up only
>         on servers or if specifically configured on the host.
>
>
>     It's actually not imaginary in enterprise contexts, as there are
>     shops that disable temporary addresses to make tracking or other
>     security activities easier.  Not my favorite reasoning,
>     personally, but there you go.
>
>
> What I meant is situation where you have both temp and permanent
> addresses on the same interface is quite unusual. In most cases it is
> one or the other. Getting both addresses configured usually requires
> some very deliberate administrative action, and unless I am mistaken,
> is not common.

I think you are mistaken..... at least, your claim does not fit with my
data.

This laptop, on a default-configured IPv6 home network:

    inet6 2001:470:de0a:27:9964:c162:8161:9a2e/64 scope global temporary
dynamic
       valid_lft 86356sec preferred_lft 14356sec
    inet6 2001:470:de0a:27:863a:4bff:fe0b:28b0/64 scope global dynamic
       valid_lft 86356sec preferred_lft 14356sec

Some very deliberate administrative action may have been taken (this is
a Google corporate device), but I suspect that it's a default Ubuntu
configuration.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 22 Mar 2014 22:07:09 +0100

On 03/22/2014 09:23 PM, Harald Alvestrand wrote:
>>         a bit imaginary since under most common client setups you
>>         only see temporary addresses. Permanent IPv6 addresses show
>>         up only on servers or if specifically configured on the host.
>>
>>
> I think you are mistaken..... at least, your claim does not fit with 
> my data.
>
>     inet6 2001:470:de0a:27:9964:c162:8161:9a2e/64 scope global 
> temporary dynamic
> Some very deliberate administrative action may have been taken (this 
> is a Google corporate device), but I suspect that it's a default 
> Ubuntu configuration.

And just to get people used to looking at stuff for themselves, here's 
my desktop machine, which is DEFINITELY a default Ubuntu setup:

hta@liset:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 scope host lo
     inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
     link/ether 6c:3b:e5:0b:6a:b4 brd ff:ff:ff:ff:ff:ff
     inet 192.168.1.17/24 brd 192.168.1.255 scope global eth0
     inet6 2001:470:de0a:27:d014:dc1:dd24:4393/64 scope global temporary 
dynamic
        valid_lft 86379sec preferred_lft 14379sec
     inet6 2001:470:de0a:27:31d8:d7fc:4af4:c17a/64 scope global 
temporary deprecated dynamic
        valid_lft 86379sec preferred_lft 0sec
     inet6 2001:470:de0a:27:8c26:e950:a09d:814c/64 scope global 
temporary deprecated dynamic
        valid_lft 86379sec preferred_lft 0sec
     inet6 2001:470:de0a:27:d883:fc90:cdcd:6b8f/64 scope global 
temporary deprecated dynamic
        valid_lft 86379sec preferred_lft 0sec
     inet6 2001:470:de0a:27:40c9:8eca:a92b:d0ac/64 scope global 
temporary deprecated dynamic
        valid_lft 86379sec preferred_lft 0sec
     inet6 2001:470:de0a:27:55e8:a88d:df95:df5d/64 scope global 
temporary deprecated dynamic
        valid_lft 86379sec preferred_lft 0sec
     inet6 2001:470:de0a:27:accc:2652:cc97:5b17/64 scope global 
temporary deprecated dynamic
        valid_lft 76189sec preferred_lft 0sec
     inet6 2001:470:de0a:27:6e3b:e5ff:fe0b:6ab4/64 scope global dynamic
        valid_lft 86379sec preferred_lft 14379sec
     inet6 fe80::6e3b:e5ff:fe0b:6ab4/64 scope link
        valid_lft forever preferred_lft forever

Ignoring the deprecated ones, one temporary and one non-temporary.

---

From: Roman Shpount <[email-masked]>
Date: Sat, 22 Mar 2014 21:46:34 -0400

I was incorrect. It is normal to get both temp and permanent IPv6 addresses
on Windows and Ubuntu.

_____________
Roman Shpount

On Sat, Mar 22, 2014 at 5:07 PM, Harald Alvestrand <[email-masked]>wrote:

>>   On Thu, Mar 20, 2014 at 7:39 PM, Roman Shpount <[email-masked]>wrote:
>>
> addresses on the same interface is quite unusual. In most cases it is one
> or the other. Getting both addresses configured usually requires some very
> Some very deliberate administrative action may have been taken (this is a
> Google corporate device), but I suspect that it's a default Ubuntu
> configuration.
>
>
> And just to get people used to looking at stuff for themselves, here's my
> desktop machine, which is DEFINITELY a default Ubuntu setup:
>
> hta@liset:~$ ip addr
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
>     inet6 2001:470:de0a:27:31d8:d7fc:4af4:c17a/64 scope global temporary
> deprecated dynamic
>     inet6 2001:470:de0a:27:8c26:e950:a09d:814c/64 scope global temporary
> deprecated dynamic
>     inet6 2001:470:de0a:27:d883:fc90:cdcd:6b8f/64 scope global temporary
> deprecated dynamic
>     inet6 2001:470:de0a:27:40c9:8eca:a92b:d0ac/64 scope global temporary
> deprecated dynamic
>     inet6 2001:470:de0a:27:55e8:a88d:df95:df5d/64 scope global temporary
> deprecated dynamic
>     inet6 2001:470:de0a:27:accc:2652:cc97:5b17/64 scope global temporary
> deprecated dynamic