Hacker News new | ask | show | jobs
by devit 3912 days ago
With the default IPv6 addressing scheme the last 64-bit are the MAC address of your Ethernet card, which makes tracking trivial.

Also, there is usually no NAT, meaning IP addresses are more likely to uniquely identify the user even without the MAC-based addressing.

But of course setting a cookie allows better tracking, and Tor defeats tracking anyway for those wishing to intentionally defeat it, so in practice it probably doesn't make much of a difference.

4 comments

For the billionth time, NAT does not provide any security as it only does address conversion. The other fields in the IP and TCP headers (such as the connect(2) side's port number, the TCP timestamp[1], badly implemented initial sequence numbers[2], and anything else that is useful for OS fingerprinting) can be used to distinguish between users[3] that share a single NATed IP address.

As you say, HTTP cookies and other higher-level protocol techniques are usually more than enough to enable tracking. Worrying about your MAC or IP address is like worrying about your street address. If you are going to be on the net and ask people to send you data, they need to know where to send it. It will always be possible for the person sending the data to log the return addresses. Use Tor (or similar) for privacy, as your IP is by definition public.

The most powerful feature of the internet was how it allowed anybody to publish on their own, unrestricted by any central authority, so please stop trying to create the digital imprimatur[4] with NAT.

[1] http://phrack.org/issues/63/3.html#article (section 0x03-2, "TCP Timestamp To count Hosts behind NAT")

[2] http://lcamtuf.coredump.cx/oldtcp/tcpseq.html

[3] http://memeover.arkem.org/2012/02/identifying-computers-behi...

[4] https://www.fourmilab.ch/documents/digital-imprimatur/

> For the billionth time, NAT does not provide any security as it only does address conversion. The other fields in the IP and TCP headers (such as the connect(2) side's port number, the TCP timestamp[1], badly implemented initial sequence numbers[2], and anything else that is useful for OS fingerprinting) can be used to distinguish between users[3] that share a single NATed IP address.

The above are all good points. However, using IPv6 for tracking is trivial. Getting behind the NAT is not. It should not be trivial to track. From a behavioral economics framework, the more steps a bad actor has to take to be "bad", the less less he's to do so. Conversely, the easier it easier for people to behave good, the more likely they will do so.

You don't have to "get behind the NAT" to track these things. Also browser plugin versions are worth a bunch of entropy.
Privacy extensions, which use random, changing, local address instead of MAC, are enabled by default in most recent OSes. It means that individual devices can't be identified and can't be tracked across networks.mThe network prefix is assigned by ISP and has the same exposure as the public IPv4 address with NAT. The result is that privacy is the effectively the same as IPv4.
The "default" stateless auto-configuration uses the MAC for the "public" address, yes, but also has provisions for assigning the interface a temporary random address that can be used for outgoing connections. See RFC 3041
I was under the impression that the MAC address-based IPv6 addresses were only link-local.

Your public IP would be assigned randomly from your ISP's pool, would it not? It would just be per-end-device now, not per-router.

A few things:

- several years ago your MAC address was used in the latter 64 bits of your network to create your public address (not just your link local).

- that naïveté/mistake has been addressed by OS makers since.

- your ISP gives you the first half of your 128-bit IP address, the second half is up to your device(s). This is baked in pretty deeply at this point, so the smallest allocation any user/router/LAN will get is 2^64 addresses. This is 4 billion times 4 billion. With that much address space we have a lot of room for competing schemes for address selection, up to and including generating random numbers. The early use of static addresses based on MAC addresses was largely convenience and holdover from v4 thinking.

Is the MAC addr behavior in Linux, at least, modifiable? Either through a kernel rebuild or a runtime variable?