Page MenuHomePhabricator

Have one aggregated talk page for ipv6 /64
Open, LowPublic

Description

In the old days with ipv4 your ipv4 address tends to be quite static. You might have one for one session (a working day?) up until a static ipv4 address that you use for years. If you contact a user editing under an ipv4 address you have a big chance of actually reaching that user.

In came ipv6. A lan in ipv6 is always a /64 (in case you're interested or just bored, read https://tools.ietf.org/html/rfc7421) and within this /64 the next /64 bits are calculated based on your mac address (see for example http://ben.akrin.com/ipv6_mac_address_to_link_local_converter/?mode=api&mac=52:74:f2:b1:a8:7f). This looks promising. First 64 bits of the 128 are assigned and static, last 64 bits of the 128 bits are based on a burned in mac address. You would expect to be the total address to be quite static.

In came the privacy extensions (https://tools.ietf.org/html/rfc4941). This seems to be enabled by default on machines using Windows. So the user ends up having a different ipv6 address every couple of minutes and a very small chance of getting a previous address again. This means that if you contact a user on his or her ipv6 talk page, the message will probably never be found by this user.

We would have to come up with some sort of system to group everything in a /64 together in a convenient way so it becomes possible again to interact with such a user.

Event Timeline

Multichill raised the priority of this task from to Needs Triage.
Multichill updated the task description. (Show Details)
Multichill subscribed.

Would we also want to do this for pages like Special:Contributions too? just show everything in the /64?

Would we also want to do this for pages like Special:Contributions too? just show everything in the /64?

If that would be possible, it would be great.

Catrope subscribed.

I imagine that everywhere we interact with an IPv6 address, we'd normalize it to the /64 version, and we'd never link to individual IPs or something. This should probably have an RfC.