The proper solution is Stable Privacy addresses, recently standardized in RFC7217 [1]. The interface ID is essentially hash(secret || prefix || mac-address), so it stays the same when you're on the same network, but changes as soon as you go somewhere else.
But that defeats the purpose of a privacy address. The idea is precisely not to use your address as a way to track individual users, like a cookie tattooed on your skin. I fail to see how a hash of the MAC address is better than the MAC address itself.
Because even with traditional privacy addresses, the first 64 bits of your address never change, and you can be tracked that way. If you happen to share those first 64 bits with many other people, then privacy addresses provide value, but that's simply not the case on your home network.
Now keep in mind that a stable privacy interface ID is not a hash of just the MAC address, it's also a hash of the network prefix and a secret that's specific to your system. Including the prefix ensures that the interface ID changes completely when you move to a different network, preventing you from being tracked all over the world. Including a secret ensures that someone can't build a lookup table from MAC address||prefix to stable privacy interface ID. So it's quite superior to using just the MAC address.
Not really, how many networks do you use in a week. Perhaps 3 or 4. And with this, once a link has been established between the IP, it becomes a permanent static link. It is trivial for advertisers through browser cookies to establish this link, and they only need to do it once.
You say that like if I was actively letting myself track.
I block third party cookies, I use AdBlockPlus. But I can't block all cookies and html5 storage (most websites wouldn't work anymore). And it only takes one website to see me coming with the same cookie from different IPs to establish that link (take a pick: google, facebook, twitter, etc). And once that link is established it will be pretty valuable (as it is static) and you can bet that these boys will exploit it.
So to me RFC7217 is pretty much as bad as static addresses.
I'm not sure why websites would even care what IP address you're coming from if they've got a cookie, which provides an even stronger way to track you. They might care what the network prefix is, since that would identify your geographical location, but not even privacy extensions prevent that.
You have ways to block third party cookies so that you cannot be tracked on the internet but if you have a website that is advertising focused (say google) and see you coming from two different IPs (and it doesn't need to be a third party website, it can be just when you search something on google), then it will be able to associate these IPs to your profile. Then every time you visit another website, that website will be able to get from google your ID from your IPs even if you block third party cookies. And this is the end of privacy.
If privacy addresses pose multicast problems, then the multicast protocol or implementation needs to be fixed. But static IP addresses isn't the solution.
I think you're putting too much faith in blocking third party cookies. Through collusion with Google (such as an IFRAME or JSONP), sites can get your Google ID from your Google cookie without needing to consult your IP address or use third party cookies. Web browsers open up such a huge can of privacy worms that I don't think it's very useful to talk about IP addresses until you fix the browser.
Personally, I clear all cookies, cache, and local storage (except from a handful of trusted sites, Google not being one) when I exit my browser (and I exit my browser often), and I occasionally examine my browser profile for traces of super-cookies. (And even this is probably not sufficient because of browser fingerprinting.) I don't think privacy extensions provide an appreciable privacy improvement over stable privacy addresses.
[1] https://tools.ietf.org/html/rfc7217