Subject: RFC4941, temp-addr only, etc. (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-00.txt)

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 11:13:43 -0400

Folks,

We've drafted this:
<https://www.ietf.org/internet-drafts/draft-gont-6man-non-stable-iids-00.txt>

For the most part, the idea is to illustrate how I think Lorenzo's
concern should be addressed.

This document essentially removes the requirement for stable addresses
(such that folks willing to do temp-addr-only can do so), specifies
requirements for such addresses, and updates RFC4941 such that a node
can use temp-addr-only.

This is orthogonal to default-iids, which provides recommendations for
stable addresses iff you decide to configure them. This way default-iids
just does what it has always meant to do (improve stable addresses), and
this document opens the door to temp-addr only.

Thoughts?

Thanks,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-non-stable-iids-00.txt
Date: Mon, 23 May 2016 08:07:36 -0700
From: [email-masked]
To: Will Liu <[email-masked]>, Fernando Gont
<[email-masked]>, Shucheng LIU (Will) <[email-masked]>

A new version of I-D, draft-gont-6man-non-stable-iids-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-non-stable-iids
Revision:	00
Title:		Recommendation on Non-Stable IPv6 Interface Identifiers
Document date:	2016-05-23
Group:		Individual Submission
Pages:		6
URL:
https://www.ietf.org/internet-drafts/draft-gont-6man-non-stable-iids-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-6man-non-stable-iids/
Htmlized:
https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-00

Abstract:
   This document clarifies the stability requirements for IP6 addresses,
   and provides recommendations regarding the generation of non-stable
   addresses.  Finally, it formally updates RFC4941 such that nodes are
   allowed to configure only temporary addresses.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 May 2016 00:39:53 +0900

> this document opens the door to temp-addr only.

SGTM, except for the "must not embed MAC addresses". I think it's a
perfectly good engineering tradeoff to embed a random MAC address in an
IPv6 IID as long as it's truly random.

For mobile devices that only support IP and no other L3 protocols, and on
networks with only one prefix (i.e., the vast majority), it's pretty much
as good as 4941-only.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 11:49:12 -0400

On 05/23/2016 11:39 AM, Lorenzo Colitti wrote:
> On Tue, May 24, 2016 at 12:13 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

So... let me ask an obvious question (which I just didn't ask before):

Say you like generating addresses with traditional SLAAC iff MAC
addresses are randomized.

Say two autoconfiguration prefixes are advertised on the link.

Is it okay for you that addresses for each prefix will employ the same
IID? -- because that would allow for correlation between traffic
corresponding to those two prefixes.

This is yet another example of why embedding a link-layer address in the
IID is a bad idea. If you do, you will not comply with the requirement
that "addresses for different prefixes should employ different IIDs"

> For mobile devices that only support IP and no other L3 protocols, and
> on networks with only one prefix (i.e., the vast majority), it's pretty
> much as good as 4941-only.

That's bad engineering: so you argue in favor of a flawed scheme, which,
when you evaluate it for the general case (multiple layer-3 protocols
and/or multiple prefixes) becomes clear that is flawed.

I want something that is still as good when multiple addresses are
employed and/or when multiple prefixes are used. Embedding a link-layer
address does not allow for that.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 May 2016 13:41:05 +1000

On 24 May 2016 at 01:39, Lorenzo Colitti <[email-masked]> wrote:
> perfectly good engineering tradeoff to embed a random MAC address in an IPv6
> IID as long as it's truly random.
>
> networks with only one prefix (i.e., the vast majority)

Most IPv6 networks have two prefixes - link-local and something else.

Link-locals must not be dismissed when it comes to privacy, because
you can be attached to a link where there may be others who have an
interest in violating your privacy.

For example, it wouldn't be hard to have a device attached a public
cafe wifi network that collected LL addresses from e.g. DAD packets
(the device could be the Wifi AP itself or the default router, so
they'll always see LLs and don't need to snoop them), that then
uploads those addresses to an Internet database. If that same type of
LL address collection device was present at another public cafe wifi
network, and your LL IID didn't change when you moved between them,
the database now has a record of your movements.

>, it's pretty much as
> good as 4941-only.

So when do you randomise the MAC address?

I think there are at least 4 options:

(a) at boot
(b) attachment to a new link
(c) reattachment to the same link (i.e., interface down/up event)
(d) periodically while the interface continues to be connected to the same link

Having automated (a) on my desktops and laptops more than a year ago,
and having also thought about the other options, all of them have a
number of privacy limitations and operational trade-offs such that I
don't think there is a clear winner.

For example, a flapping interface with a (c) implementation, or many
(d) implementations attached to the same link could fill up switch
FDBs, causing traffic to be unnecessarily layer 2 flooded, degrading
performance and reducing the privacy inherent in switched rather than
flooded unicast traffic.

At boot MAC addresses actually persist for quite a long time on my
devices because I suspend/hibernate them rather than reboot them every
time I use them. I know that is a risk, however I've got far more
private MAC addresses that most people who've still got unchanging MAC
addresses from the NIC vendor (and I'll assume my 5 Google produced
devices).

The privacy limitations are some of the reasons why I still want
RFC7217 to be the default, because sharing a random MAC derived IID
across different prefixes on the same link still allows correlation.
Completely decoupling layer 3 addresses from layer 2 addresses means
that different privacy factors can be prioritised at the different
layers.

I don't think it is enough to say random MAC addresses in IIDs provide
adequate or equivalent security to RFC7217s when it is known what
factors influence and therefore when RFC7217 IIDs will change, where
as the same factors haven't been described for random MAC addresses. I
haven't seen in this discussion a fully articulated basis for
comparison between random MAC IIDs and RFC7217 IIDs, and there needs
to be one.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 May 2016 13:35:05 +0900

> Say two autoconfiguration prefixes are advertised on the link.

As I said in the part of my email that you did not quote, most networks
only have one prefix that is used for off-network traffic. That is why I
said it's a good engineering tradeoff, not a perfect solution.

You're right that it has flaws. Every scheme has correlation flaws unless
it uses a different source address for every packet. The question is where
do we make the tradeoff.

For example, your proposal to using different IIDs for different prefixes
still has correlation opportunities if the host network stack uses both
addresses to go to the same destination. OTOH, if the host stack only uses
one of the addresses (like, say, Linux does), then using a different IID
for each prefix has the same properties as using the same IID on every
prefix since only one of the addresses will be used.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 May 2016 13:37:30 +0900

> don't think there is a clear winner.

What's wrong with (c) coupled with a flap dampening mechanism, such that if
you disconnect and reconnect after less than some minimum period of time
you keep the same MAC?

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 May 2016 16:15:37 +1000

On 26 May 2016 at 14:37, Lorenzo Colitti <[email-masked]> wrote:
> you disconnect and reconnect after less than some minimum period of time you
> keep the same MAC?

Nothing in itself, except there is nothing specifying it, and millions
of devices that are currently vulnerable to this sort of fault.

There are these sorts issues with all of the above, and I'm not even
completely sure that the above is the complete list of times that it
would be useful or valid to change MAC address.

Here is another example.

(b) and (c) are fundamentally the same mechanism - change MAC address
upon link up.

In the case of (c), the host would send an unsolicited NA to update
other on-link devices' neighbor caches with the interfaces' new
link-layer address (note, I've been assuming the IPv6 address would
stay the same across this event to ensure TCP etc. connections
survive.)

In the case of (b), when attached to the new link, it is very
important not to send this unsolicited NA, because the NA may contain
global or ULA prefixe addresses, which would disclose to any device
capturing them on the new network what past network the device was
just attached to (ULAs less so, although they're still supposed to be
globally unique).

So the problem is how to distinguish between attaching to a new link
and re-attaching to the same link?

I understand this sort of detection may be addressed by RFC6059,
"Simple Procedures for Detecting Network Attachment in IPv6". I
haven't looked at it in detail, however it seems to be assuming that a
router's link-layer address will stay constant to create a Router
Identifier. So if router link-layer addresses change periodically
(when?) and their IIDs change too because the MAC is embedded in the
IID, I think DNA would think there was attachment to a new network
more often than is actually the case.

If unsolicited NDs aren't sent when reattaching to the same network
(because DNA thinks it is a new network),  then existing TCP
connections would either fail, or at least be disrupted, usually
visibly to the application user, until NUD detected the failure and
then issued new NSes to discover the new MAC address for the
destination IPv6 address.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 May 2016 18:33:32 -0400

On 05/26/2016 12:35 AM, Lorenzo Colitti wrote:
> On Tue, May 24, 2016 at 12:49 AM, Fernando Gont <[email-masked]

FWIW, most networks don't configure global IPv6 addresses in the first
place. And regarding those networks where nodes do configure global
addresses, since you don't really know how many global prefixes there
will be there, you have to fail on the safe side.

It's not crazy to expect redundant connections in the future (IIRC, even
homenet expected that), even if that's not happening right now. And
whatever recommendations we provide have to accommodate such case
gracefully.

> You're right that it has flaws. Every scheme has correlation flaws
> unless it uses a different source address for every packet. The question
> is where do we make the tradeoff.
> 
> For example, your proposal to using different IIDs for different
> prefixes still has correlation opportunities if the host network stack
> uses both addresses to go to the same destination.

It doesn't. You cannot correlate the traffic by looking at the addresses
themselves. If you correlate traffic by looking elsewhere (say,
app-layer data), that's obviously out of the scope of this document, and
has to be fixed elsewhere.

>  OTOH, if the host
> stack only uses one of the addresses (like, say, Linux does), then using
> a different IID for each prefix has the same properties as using the
> same IID on every prefix since only one of the addresses will be used.

Which addresses will be used depend on a number of factors.

For example, in a stable-only scenario for server-like operations, the
addresses that get employed may depend on which addresses are posted on
the DNS. For client-side operations, it may depend on src addr selection.

OTOH, for a (client-like) stable-only scenario, if we have an IPv6
server that, say, has two different addresses in different prefixes, and
DNS round-robin is employed, it may be the case that one address (from
one prefix) is employed to connect to one of the server addresses, while
another is employed to connect to the other server address.

Again: fail on the safe side. We don't want to e.g. find that two-prefix
scenarios become quite common, and then have to update the specs again,
*late*, because we failed to be proactive.

We have to learn to be more OpenBSD-like in this respect.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 May 2016 11:17:15 +0900

> and re-attaching to the same link?

A simple algorithm would seem to be:

   1. If you don't support, or don't want to use, DNA, then every link is a
   new link and you start off with no IP addresses. So you form a link-local
   address, send an RS, etc. etc. starting from scratch.
   2. If you support and want to use DNA, then you use DNA with the same
   MAC address as you had before.

That requires that you decide in advance whether you think that the network
you are connecting to might be the same as a previously-visited network. In
many cases (e.g., you connect to an SSID that you have connected to
before), that is a decision that is possible to make.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 May 2016 11:28:10 +0900

> will be there, you have to fail on the safe side.

Saying that most networks don't have IPv6 is irrelevant because on those
networks it doesn't matter what the IPv6 stack does. What is relevant is
what happens on networks when IPv6 is present, and in the vast majority of
cases those networks have only one prefix.

> has to be fixed elsewhere.

Declaring a problem out of scope doesn't mean that the problem goes away.

> *late*, because we failed to be proactive.

Like I said, it's a tradeoff. Updating standards documents is one thing,
and writing an implementation is another. Given that our process involves
rough consensus AND running code, we should take into account
implementation complexity, and the people who write the implementations are
the ones that are best positioned to make statements on that. That goes
back to Ole's point about replacing all the implementations that currently
do SLAAC and his suggestion that perhaps it is better not to declare those
implementations noncompliant overnight.

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 May 2016 13:00:27 +1000

On 27 May 2016 at 12:17, Lorenzo Colitti <[email-masked]> wrote:

>    1. If you don't support, or don't want to use, DNA, then every link is
>    a new link and you start off with no IP addresses. So you form a link-local
That is significantly reducing the robustness of e.g. TCP connections, as
they won't survive that event because their address will change.

Hosts are supposed to be tolerant of transient network events. In my
experience, that has included disconnection and reconnection of the host's
interface to the same link, which has included moving the host's patch
cable from one switch to another attached to the same LAN. I didn't rush
the patch cable move because at the time I didn't have any expectations
that my existing telnet sessions would survive.

>    1. If you support and want to use DNA, then you use DNA with the same
The issue with DNA is that it seems to be relying on the MAC address and
therefore the Link-Local address of the on-link routers being stable for as
the link remains operating. If routers were changing their MAC addresses
periodically too, then DNA will fail. It seems you've been arguing for no
stable L2 and/or L3 addresses on any device, so that would have to mean
that routers don't have them either.

> That requires that you decide in advance whether you think that the
> network you are connecting to might be the same as a previously-visited
> network. In many cases (e.g., you connect to an SSID that you have
> connected to before), that is a decision that is possible to make.
>

I can probably come up with more examples.

The point is that I don't think this whole problem/solution space has been
fully explored, and with the limited thinking I've done about it, I don't
think it is quite as simple as saying "use randomised MAC addresses" to
attain layer 2 and layer 3 privacy.

I can't seem to find the reference right now, however I think the DHCPv6
work you've pointed to only considered it in the context of the DHCPv6
protocol (RFC7824 now?), rather than implications to things like ND, upper
layer connections surviving, routers changing their LL addresses
periodically etc.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 May 2016 12:20:53 +0900

On Fri, May 27, 2016 at 12:00 PM, Mark Smith <[email-masked]> wrote:

>>    1. If you don't support, or don't want to use, DNA, then every link
>>    is a new link and you start off with no IP addresses. So you form a
>>    link-local address, send an RS, etc. etc. starting from scratch.
>>
>>

Most mobile devices close all TCP connections every time a network
disconnects, anyway. The reason for this is that if the device switches to
a different network, the TCP connections are dead anyway (because the IP
address changes) and apps just get stuck. Keeping the connection alive is
only useful if you think that there's a very high chance of reconnecting to
the same network soon, and you either have no other network in the
meantime, or you think you're going to reconnect so soon that it doesn't
make sense to re-establish a connection on another network.

> that routers don't have them either.

Actually, I don't expect that routers will need random MAC addresses.

---

From: "Dale W. Carder" <[email-masked]>
Date: Fri, 27 May 2016 10:16:00 -0500

> that routers don't have them either.

I can't imagine that routers would be periodically randomizing their MAC 
addresses in any practical deployment.  Though, I do have a few routers that 
changed mac addresses exactly once, when I turned off DECnet. :-)  Even
that one change was quite problematic due to high timeouts on some host 
stacks.

Dale

---

From: joel jaeggli <[email-masked]>
Date: Fri, 27 May 2016 18:09:04 +0200

> that one change was quite problematic due to high timeouts on some host 

Randomizing interfaces macs would really be a pain in the ass when
dealing with Link aggregation group members. swapping linecards or
routers is bad enough, but people actually do use these link-layer clues
as part of port inventry /port security / configuration systems and so on...

> Dale
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 28 May 2016 12:15:10 +1000

> as part of port inventry /port security / configuration systems and so on...

Router interfaces is the situation where I would leave the MAC address
as burnt in by the factory to assist with troubleshooting etc., and
then have RFC7217 generate stable per-prefix IIDs, including for the
router's interface LLs, using slot/module/interface number or
slot/module/interface stable ifIndex as the Net_Interface parameter.

In that situation, I think the physical security protecting link
access, or the limited geographical scope of Wifi would provide enough
privacy for the factory MAC addresses, and as they're not being used
directly in the layer 3 IIDs, knowing them wouldn't allow somebody to
then target the router over the Internet at layer 3 (assuming it is
reachable over the Internet).

It might be more useful to randomise residential router MAC addresses
periodically e.g. on boot, although that looks like it would break
DNA. if DNA was changed to only use the router's LL address as the
router ID, on the assumption that it was stable, and RFC7217 was used
to generate stable LLs independent of the MAC address, then
randomising the router's MAC address on boot or gracefully some other
time (e.g., announced via unsolicited NAs) should be possible without
impacting operation.

Regards,
Mark.

---

From: "Dale W. Carder" <[email-masked]>
Date: Fri, 27 May 2016 23:03:13 -0500

> slot/module/interface stable ifIndex as the Net_Interface parameter.

For many enterprise and some ISP deployments it's going to be way more 
common to see a VRRP or HSRP mac address (group specific).  At our site, 
we also then set the router LL addr on every interface on every router 
to fe80::1.  It's the one thing I point to and say, "see, ipv6 makes this 
easier."  :-)

Home deployments are probably another matter.  I'm not sure randomizing
my home router mac addr would make any real difference.  Or I guess with 
people's smart TV's now spying on them, there's bigger fish to fry than
creating a new set of interoperability problems.

Dale

---

From: Mark Smith <[email-masked]>
Date: Sun, 29 May 2016 12:30:47 +1000

On 27 May 2016 12:51 PM, "Lorenzo Colitti" <[email-masked]> wrote:
>>> If you don't support, or don't want to use, DNA, then every link is a
>>
>>
>> That is significantly reducing the robustness of e.g. TCP connections,
as they won't survive that event because their address will change.
> Most mobile devices close all TCP connections every time a network
disconnects, anyway.

My laptop running general purpose Linux doesn't. Servers don't.

I think that is the insight. I don't think you're considering any other
types of device in this discussion, meaning you won't be seeing where
stable addresses that have increased privacy properties (compared to
EUI-64s, but not in comparison with RFC4941s - which don't meet the
stability requirement) are beneficial.

>The reason for this is that if the device switches to a different network,
the TCP connections are dead anyway (because the IP address changes) and
apps just get stuck. Keeping the connection alive is only useful if you
think that there's a very high chance of reconnecting to the same network
soon, and you either have no other network in the meantime, or you think
you're going to reconnect so soon that it doesn't make sense to
re-establish a connection on another network.

>>>
>>> If you support and want to use DNA, then you use DNA with the same MAC
address as you had before.
> Actually, I don't expect that routers will need random MAC addresses.

I think it depends on the type of router. Service provider or
corporate/enterprise router I'd agree.

Residential router, I'd disagree, unless there are any significant
drawbacks.

First thought is new random MACs on boot. The privacy enhancement would be
both periodically changing MAC addresses in WiFi SSID announcements, and no
disclosure of the router NIC manufacturer.

I'll look to find time to do this on my residential router in the next few
weeks.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 29 May 2016 20:30:04 +0900

> My laptop running general purpose Linux doesn't. Servers don't.
Your laptop doesn't do that, but perhaps it should. The fact that it
doesn't means that applications are forced to do it. For example:

   - Chrome has code that listens to netlink events and closes all sockets
   when addresses change.
   - It becomes impossible to use SSH with port forwarding across network
   switches because the forwarded port is still mapped to a TCP connection
   that will never come back because your IP address has changed. So you have
   to configure TCP keepalives.
   - ... and so on.

You could argue that this should in fact be up to the application, but I
think it's reasonable for the system to do it. Many OSes do. For mobile
devices, it's a necessity.

As for servers, numbering them with EUI-64 or RFC7217 (which has the same
stability properties, i.e., the stable for the life of the network card)
seems silly compared to giving them static addresses.> Actually, I don't
expect that routers will need random MAC addresses.

> I'll look to find time to do this on my residential router in the next few
Good luck getting an an IPv4 address after rebooting the router 3 times in
5 minutes. Many ISPs only allow 1 or 2 IPv4 addresses per connection.

---

From: Mark Smith <[email-masked]>
Date: Mon, 30 May 2016 09:18:00 +1000

disconnects, anyway.
> Your laptop doesn't do that, but perhaps it should.

Which is contrary to the robustness principle.

It would be smarter to test if the device reconnected to the same network
or not rather than assuming it is always a different network and tearing
down TCP sessions that will recover.

> The fact that it doesn't means that applications are forced to do it. For
example:
> Chrome has code that listens to netlink events and closes all sockets
when addresses change.
> It becomes impossible to use SSH with port forwarding across network
switches because the forwarded port is still mapped to a TCP connection
that will never come back because your IP address has changed.

Port forwarding is very useful sometimes, but it isn't a common thing to do
in the context of all the of users of all of these devices.

My example was moving between switches attached to the same subnet. Not a
common thing to occur either however an example of how hosts are robust
against transient network faults, including of the cable directly attached.

> So you have to configure TCP keepalives.
> ... and so on.

See above about only doing it if the network has changed.

Incorrect. See appendix A. If you think they are, then I don't think you've
not fully understood the problem that RFC7217s solve. They specifically
have decoupled the IID always relying on the NIC MAC address.

> seems silly compared to giving them static addresses.

I'd much rather 100 000 servers generate their own stable addresses that
have to generate 100 000 random numbers and then go and configure each
device with them.

drawbacks.
>>
>> First thought is new random MACs on boot. The privacy enhancement would
be both periodically changing MAC addresses in WiFi SSID announcements, and
no disclosure of the router NIC manufacturer.
>>
>> I'll look to find time to do this on my residential router in the next
few weeks.
>
> Good luck getting an an IPv4 address after rebooting the router 3 times
in 5 minutes. Many ISPs only allow 1 or 2 IPv4 addresses per connection.

So there is another gotcha with randomising MAC addresses. (Years ago I
used MAC address randomisation to over come these sorts of blockages...)

I'm confident it is going to work for me though, as I used to be one of the
people on the other end.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 May 2016 13:53:21 +0900

> down TCP sessions that will recover.
What if the device is already connected to another network? For example,
what if a device switches from cellular data to wifi? Does that count as a
"reconnect"? If it doesn't, then the app might be blocked for minutes in
read(), faithfully waiting for cellular data to come back (with the same IP
address!), even though there's a perfectly valid wifi connection available
that can be used right now.

> > As for servers, numbering them with EUI-64 or RFC7217 (which has the
> same stability properties, i.e., the stable for the life of the network
> card)
>
> Incorrect. See appendix A. If you think they are, then I don't think
> you've not fully understood the problem that RFC7217s solve. They
> specifically have decoupled the IID always relying on the NIC MAC address.
>
But RFC 7217 plainly states that it's associated with the network interface:

       Net_Iface:
          An implementation-dependent stable identifier associated with
          the network interface for which the RID is being generated.

"associated with the network interface" implies that it changes if the
interface changes.

> used MAC address randomisation to over come these sorts of blockages...)
There are definitely gotchas with randomizing MAC addresses in the presence
of other stable identifiers like circuit IDs or physical network port
location. If the MAC address is the only identifier, as it is in wifi, then
that failure mode does not apply.

---

From: Mark Smith <[email-masked]>
Date: Tue, 31 May 2016 16:56:12 +1000

On 31 May 2016 2:23 PM, "Lorenzo Colitti" <[email-masked]> wrote:
>> It would be smarter to test if the device reconnected to the same
network or not rather than assuming it is always a different network and
tearing down TCP sessions that will recover.
"reconnect"?

No. Clearly different networks, of more specifically, different link
(RFc2460)/subnets/default router(s)

If it doesn't, then the app might be blocked for minutes in read(),
faithfully waiting for cellular data to come back (with the same IP
address!), even though there's a perfectly valid wifi connection available
that can be used right now.
interface changes.

Read the whole of RFC7217, or at least Appendix A, as I said before.

>
> There are definitely gotchas with randomizing MAC addresses in the
presence of other stable identifiers like circuit IDs or physical network
port location. If the MAC address is the only identifier, as it is in wifi,
then that failure mode does not apply.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 31 May 2016 17:21:54 +0900

> (RFc2460)/subnets/default router(s)
Then all apps are sitting there waiting for read() calls that will never
complete unless the same network reconnects. That's pretty much always the
wrong thing to do for the majority of apps - most apps are better served by
making a new connection on another network than sitting there waiting for a
network that is gone and might not come back for a long time. Imagine how
irritating it would be if your browser hung every time you walk in and out
of range of a wifi network.

> Read the whole of RFC7217, or at least Appendix A, as I said before.
But I did. The way I read it, all the suggestions in Appendix A have equal
or less stability than the interface link-layer address. On client systems,
interface name and index are at best as persistent as the MAC address. At
worst, they depend unpredictably on device initialization order and
connect/disconnect sequence.

Logical network service identity is the only one that might have higher
stability, but it's hard to tell what properties "a conception of logical
network service identity, distinct from network interface identity or
index" means since it's rather vague. One thing that's for sure is that
logical network interface identity *must* be tightly coupled to the network
card it's used with, because if it isn't and the host connects to the same
network simultaneously with two interfaces, the algorithm will generate
duplicate addresses, and that's explicitly forbidden by the document.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Jun 2016 08:12:29 +1200

Lorenzo,
On 31/05/2016 20:21, Lorenzo Colitti wrote:
> complete unless the same network reconnects. 

That's an important point. read() timeouts in clients are tricky. Quoting
a comment found on stackoverflow.com, "The only safe approach to handle TCP
timeout is to run the connection code in a different thread and interrupt the
thread when it takes too long." Or you can wait in select() instead of read().
But I bet that many applications do neither.

   Brian

> That's pretty much always the

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Jun 2016 09:23:50 +1000

On 31 May 2016 17:52, "Lorenzo Colitti" <[email-masked]> wrote:
>> > What if the device is already connected to another network? For
example, what if a device switches from cellular data to wifi? Does that
count as a "reconnect"?

The answer is MPTCP.

This discussion has got way past whether link-layer address randomisation
is an adequate substitute for RFC7217 addresses.

As someone who is using random MAC addresses in most places I can, they're
not.

interface changes.
> But I did. The way I read it,

You're reading it incorrectly.

>all the suggestions in Appendix A have equal or less stability than the
interface link-layer address. On client systems, interface name and index
are at best as persistent
as the MAC address.

If I recall, Fedora assigns interface names based on PCI slot.

>At worst, they depend unpredictably on device initialization order and

Get some time on a commercial router and you'll find out that none of what
you're saying occurs. Their interface names are persistent, and will
commonly use slot/module/interface to refer to the interface. Swapping an
interface module changes nothing but the MAC address. People object to
router interface LL and other addresses changing because the MAC address
has changed. Another example of why it has been a mistake to use MAC
addresses as L3 IIDs.

(Static addresses should be a choice. Making static addresses mandatory to
decouple an interface address from a MAC address is IPv4 thinking. The
ANIMA people won't like making static addressing on routers mandatory.)

Regarding ifIndex to interface persistence:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/ifindx.html

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Jun 2016 09:58:28 +0900

> The answer is MPTCP.
If you ask me, a protocol that cannot be deployed is never the answer to
anything. But MPTCP is not the only way to do multipath, and it's true that
that's OT for this thread.

> If I recall, Fedora assigns interface names based on PCI slot.
On ubuntu they come from udev rules:

# PCI device 0x8086:0x0085 (iwlwifi)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="84:3a:4b:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="wlan*", NAME="wlan0"
...
# USB device 0x:0x (r8152)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:e0:4c:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth5"

PCI slot (or USB bus location) really isn't going to work well for the USB
ethernet adapter which I use every day.

> you're saying occurs.
Of course it doesn't. What I'm saying applies to hosts, but it does apply
to most hosts, and hosts are the things that have the greater privacy
requirements. You want to make RFC7217 a MUST for commercial routers, sure:
Ole is the one you have to fight on that one, not me :-)

Cheers,
Lorenzo