Hi all,
June 6, 2012 is IPv6 Day ( http://www.worldipv6day.org/ ). The goal of this global event is to move more ISPs, equipment manufacturers and web services to permanent adoption of IPv6.
We're planning to do limited production testing of IPv6 during the Berlin Hackathon 2012 (June 2-3). Provided that the number of issues we encounter are manageable, we may fully enable IPv6 on IPv6 day, and keep it enabled.
MediaWiki has been used with IPv6 by third party wikis for some time. Wikimedia uses a set of additional features (GlobalBlocking, CheckUser, etc.) which weren't fully IPv6-ready until recently. In addition, we're working to ensure that all of Wikimedia's various services (mailing lists, blogs, etc.) are IPv6-ready.
== What's the user impact going to be? ==
At least in the June 2-3, 2012 time window, you may see a small number of edits from IPv6 addresses, which are in the form "2001:0db8:85a3:0000:0000:8a2e:0370:7334". See [[w:IPv6 address]].
These addresses should behave as any other IP adress would: You can leave messages on their talk pages; you can track their contributions; you can block them. CIDR notation is supported for rangeblocks.
An important note about blocking: A single user may have access to a much larger number of addresses than in the IPv4 model. This means that range blocks (e.g. address with "/64") have to be applied in more cases to prevent abuse by more sophisticated users.
In the mid term, user scripts and tools that use simple regular expressions to match IPv4 addresses will need to be adapted for IPv6 support to behave correctly. We suspect that IPv6 usage is going to be very low initially, meaning that abuse should be manageable, and we will assist in the monitoring of the situation.
User:Jasper Deng is maintaining a comprehensive analysis of the long term implications of the IPv6 migration here: https://en.wikipedia.org/wiki/User:Jasper_Deng/IPv6
We've set up a test wiki where you can see IPv6 IP addresses. This works by assigning you a fake IPv6 address the moment you visit the wiki, and allows you to see the behavior of various tools with the new address format: http://ipv6test.wmflabs.org/wiki/index.php/Main_Page
The best way to report issues is to register them in Bugzilla and to ensure that they are marked as blockers for the IPv6 tracking bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=35540
We'll post updates to wikitech-l and elsewhere as appropriate.
All best, Erik
Hi,
It would be so easier to update the tools if we had ipv6 enabled on wikimedia labs. Right now the development is complicated since there is no test site. But I am happy to see that we are getting some progress in this.
On Fri, Jun 1, 2012 at 11:12 PM, Erik Moeller erik@wikimedia.org wrote:
Hi all,
June 6, 2012 is IPv6 Day ( http://www.worldipv6day.org/ ). The goal of this global event is to move more ISPs, equipment manufacturers and web services to permanent adoption of IPv6.
We're planning to do limited production testing of IPv6 during the Berlin Hackathon 2012 (June 2-3). Provided that the number of issues we encounter are manageable, we may fully enable IPv6 on IPv6 day, and keep it enabled.
MediaWiki has been used with IPv6 by third party wikis for some time. Wikimedia uses a set of additional features (GlobalBlocking, CheckUser, etc.) which weren't fully IPv6-ready until recently. In addition, we're working to ensure that all of Wikimedia's various services (mailing lists, blogs, etc.) are IPv6-ready.
== What's the user impact going to be? ==
At least in the June 2-3, 2012 time window, you may see a small number of edits from IPv6 addresses, which are in the form "2001:0db8:85a3:0000:0000:8a2e:0370:7334". See [[w:IPv6 address]].
These addresses should behave as any other IP adress would: You can leave messages on their talk pages; you can track their contributions; you can block them. CIDR notation is supported for rangeblocks.
An important note about blocking: A single user may have access to a much larger number of addresses than in the IPv4 model. This means that range blocks (e.g. address with "/64") have to be applied in more cases to prevent abuse by more sophisticated users.
In the mid term, user scripts and tools that use simple regular expressions to match IPv4 addresses will need to be adapted for IPv6 support to behave correctly. We suspect that IPv6 usage is going to be very low initially, meaning that abuse should be manageable, and we will assist in the monitoring of the situation.
User:Jasper Deng is maintaining a comprehensive analysis of the long term implications of the IPv6 migration here: https://en.wikipedia.org/wiki/User:Jasper_Deng/IPv6
We've set up a test wiki where you can see IPv6 IP addresses. This works by assigning you a fake IPv6 address the moment you visit the wiki, and allows you to see the behavior of various tools with the new address format: http://ipv6test.wmflabs.org/wiki/index.php/Main_Page
The best way to report issues is to register them in Bugzilla and to ensure that they are marked as blockers for the IPv6 tracking bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=35540
We'll post updates to wikitech-l and elsewhere as appropriate.
All best, Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Nevermind, I didn't check that the ipv6 was recently enabled there as well
On Sat, Jun 2, 2012 at 10:08 AM, Petr Bena benapetr@gmail.com wrote:
Hi,
It would be so easier to update the tools if we had ipv6 enabled on wikimedia labs. Right now the development is complicated since there is no test site. But I am happy to see that we are getting some progress in this.
On Fri, Jun 1, 2012 at 11:12 PM, Erik Moeller erik@wikimedia.org wrote:
Hi all,
June 6, 2012 is IPv6 Day ( http://www.worldipv6day.org/ ). The goal of this global event is to move more ISPs, equipment manufacturers and web services to permanent adoption of IPv6.
We're planning to do limited production testing of IPv6 during the Berlin Hackathon 2012 (June 2-3). Provided that the number of issues we encounter are manageable, we may fully enable IPv6 on IPv6 day, and keep it enabled.
MediaWiki has been used with IPv6 by third party wikis for some time. Wikimedia uses a set of additional features (GlobalBlocking, CheckUser, etc.) which weren't fully IPv6-ready until recently. In addition, we're working to ensure that all of Wikimedia's various services (mailing lists, blogs, etc.) are IPv6-ready.
== What's the user impact going to be? ==
At least in the June 2-3, 2012 time window, you may see a small number of edits from IPv6 addresses, which are in the form "2001:0db8:85a3:0000:0000:8a2e:0370:7334". See [[w:IPv6 address]].
These addresses should behave as any other IP adress would: You can leave messages on their talk pages; you can track their contributions; you can block them. CIDR notation is supported for rangeblocks.
An important note about blocking: A single user may have access to a much larger number of addresses than in the IPv4 model. This means that range blocks (e.g. address with "/64") have to be applied in more cases to prevent abuse by more sophisticated users.
In the mid term, user scripts and tools that use simple regular expressions to match IPv4 addresses will need to be adapted for IPv6 support to behave correctly. We suspect that IPv6 usage is going to be very low initially, meaning that abuse should be manageable, and we will assist in the monitoring of the situation.
User:Jasper Deng is maintaining a comprehensive analysis of the long term implications of the IPv6 migration here: https://en.wikipedia.org/wiki/User:Jasper_Deng/IPv6
We've set up a test wiki where you can see IPv6 IP addresses. This works by assigning you a fake IPv6 address the moment you visit the wiki, and allows you to see the behavior of various tools with the new address format: http://ipv6test.wmflabs.org/wiki/index.php/Main_Page
The best way to report issues is to register them in Bugzilla and to ensure that they are marked as blockers for the IPv6 tracking bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=35540
We'll post updates to wikitech-l and elsewhere as appropriate.
All best, Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Jun 1, 2012 at 5:12 PM, Erik Moeller erik@wikimedia.org wrote:
Hi all,
June 6, 2012 is IPv6 Day ( http://www.worldipv6day.org/ ). The goal of this global event is to move more ISPs, equipment manufacturers and web services to permanent adoption of IPv6.
We're planning to do limited production testing of IPv6 during the Berlin Hackathon 2012 (June 2-3). Provided that the number of issues we encounter are manageable, we may fully enable IPv6 on IPv6 day, and keep it enabled.
Thanks Erik and all who are working on this! It's important work and I'm glad to see us joining the community of sites and organizations who are prepared for this necessity.
(Acknowledging the potential issues others have mentioned, I'm also glad to see it while there are still few users who will be using IPv6, so the problems that arise will be much smaller than they would be in the future.)
Cheers, Kat
Hi folks,
Mark Bergsma just shared the following recap with me, for those who are interested in the details of what happened at the hackathon and next steps. tl;dr: If all goes well we'll be ready to launch full production deployment on Wednesday, starting around 10AM UTC (MediaWiki engineers will be working closely with the ops team Wednesday to monitor bugs/issues).
Keep an eye on the server admin log and the puppet repo if you want to know what's going on in full detail:
http://wikitech.wikimedia.org/view/Server_admin_log https://gerrit.wikimedia.org/r/#/q/status:merged+project:operations/puppet,n...
Erik
- - -
The last few days we've worked on getting the software ready (mainly PyBal/LVS) as well as Puppet support for provisioning of IPv6 addresses to servers and configuration changes for IPv6 connectivity. That's now 90% done. What remains is mostly to actually roll this out for all services in all data centers, which we will be doing tomorrow. Besides that, we have a few "would be nice to haves" left to do, such as having our own 6to4 and miredo relays.
I just got the first LVS service running with IPv6, and am now browsing upload.wikimedia.org over IPv6 (local /etc/hosts entry of course, not in DNS yet). ipv6 support for LVS in Ubuntu Precise was the last major uncertain factor on the infrastructure side; besides a few quick tests in labs we had not really tested this yet in our production setup. Fortunately, it appears to be working fine. Tomorrow the remaining (inactive) LVS balancers will be reinstalled with Precise and made IPv6-ready to support all other services, while the currently active IPv4 balancers will keep their current setup for some time to come - so we won't hit any surprises on IPv4 at least.
But, we haven't done any production tests with MediaWiki yet. We can do some dark testing and actual edits tomorrow. Assuming we see no surprises there, we can enable it for the all wikis and the general public on Wednesday.
To conclude, we're on track on the infrastructure side. It is tight, though. Assuming the MediaWiki side has no unwelcome surprises for us, I expect to be able to make it.
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Erik Moeller wrote:
If all goes well we'll be ready to launch full production deployment on Wednesday, starting around 10AM UTC (MediaWiki engineers will be working closely with the ops team Wednesday to monitor bugs/issues).
All,
It seem that IPv6 got enabled just yet. At least, this morning I was not able to browse Wikipedia this morning on a IPv6only network, and it works like a charm now.
I want to express my gratitude for all engineers who made this happen. Kudos and compliments to all of you.
It is noted and appreciated. Thanks!
Freek
Yes, good job guys! Now someone just needs to get Wikipedia.org (etc) added to http://www.worldipv6launch.org/participants/?q=1 :-) On the English Wikipedia someone from Indiana University was the first to do a logged out edit. The first edit (and only) anonymous edit on Commons was by Team Cymru.
Now that we have ipv6 someone should start making statistics of the number of logged out edits in a month by ip adresses vs ipv6 address. I wonder when we'll hit 50-50 :-)
Maarten
Op 6-6-2012 15:59, Freek Dijkstra schreef:
Erik Moeller wrote:
If all goes well we'll be ready to launch full production deployment on Wednesday, starting around 10AM UTC (MediaWiki engineers will be working closely with the ops team Wednesday to monitor bugs/issues).
All,
It seem that IPv6 got enabled just yet. At least, this morning I was not able to browse Wikipedia this morning on a IPv6only network, and it works like a charm now.
I want to express my gratitude for all engineers who made this happen. Kudos and compliments to all of you.
It is noted and appreciated. Thanks!
Freek
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I am in central europe and there is almost no ipv6 connectivity, more far on east it's ever worse, so I doubt
On Wed, Jun 6, 2012 at 5:07 PM, Maarten Dammers maarten@mdammers.nl wrote:
Yes, good job guys! Now someone just needs to get Wikipedia.org (etc) added to http://www.worldipv6launch.org/participants/?q=1 :-) On the English Wikipedia someone from Indiana University was the first to do a logged out edit. The first edit (and only) anonymous edit on Commons was by Team Cymru.
Now that we have ipv6 someone should start making statistics of the number of logged out edits in a month by ip adresses vs ipv6 address. I wonder when we'll hit 50-50 :-)
Maarten
Op 6-6-2012 15:59, Freek Dijkstra schreef:
Erik Moeller wrote:
If all goes well we'll be ready to launch full production deployment on Wednesday, starting around 10AM UTC (MediaWiki engineers will be working closely with the ops team Wednesday to monitor bugs/issues).
All,
It seem that IPv6 got enabled just yet. At least, this morning I was not able to browse Wikipedia this morning on a IPv6only network, and it works like a charm now.
I want to express my gratitude for all engineers who made this happen. Kudos and compliments to all of you.
It is noted and appreciated. Thanks!
Freek
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I also join the ranks of people who are happy with IPv6 and thank the WMF staff and the volunteers who made this possible.
2012/6/6 Petr Bena benapetr@gmail.com:
I am in central europe and there is almost no ipv6 connectivity, more far on east it's ever worse, so I doubt
Wrong. :) Come to Romania and you'll have (native) IPv6 from the main ISP and some universities (although I suspect they use some kind of tunnel upstream since the NREN does not have IPv6 AFAIK). We've already had a IPv6 edit on ro.wp, unfortunately it was vandalism :(
Strainu
On Wed, Jun 6, 2012 at 6:59 AM, Freek Dijkstra software@macfreek.nl wrote:
I want to express my gratitude for all engineers who made this happen. Kudos and compliments to all of you.
Credit goes to Mark Bergsma, Faidon Liambotis, Ryan Lane, Asher Feldman, Aaron Schulz, Chris Steipp, and many others for helping make this happen. Many members of the team worked practically nonstop to ensure that we can launch on IPv6 Day. Here's a full update from Mark:
[begin quote] Today, between 10:00 and 11:00 UTC, we've gradually enabled IPv6 for all wikis. We started with upload, followed by bits, then the main wikis, and concluded with the mobile cluster.
So far it seems to be working fine. We're seeing some edits being made over IPv6, and IPv6 traffic is in the low tens of Mbps range. Browsing the sites over IPv6 seems to just work like it does with v4. I haven't heard of a single complaint yet. It was very uneventful. :-)
Nonetheless, there will be a very small (fractional) percentage of clients who no longer can access our sites. Part of the idea of today - IPv6 Launch Day - is to collectively force these clients and relevant network issues to get fixed. Faidon has also improved my old "selective-answer.py" DNS backend, previously used for IPv6 DNS whitelisting, to allow it to be used as a blacklist. If we find networks that are unable or unwilling to resolve any IPv6 issues, then we can selectively disable IPv6 for their IP address prefixes. This is not in use yet, but can be deployed quickly. [end quote]
There will surely be new MediaWiki or tool/bot level issues as well, but hopefully they'll be manageable without a rollback. The best way to report most issues is through https://bugzilla.wikimedia.org/ and by adding the "ipv6" keyword.
On 7 June 2012 00:46, Erik Moeller erik@wikimedia.org wrote:
So far it seems to be working fine. We're seeing some edits being made over IPv6, and IPv6 traffic is in the low tens of Mbps range.
At the very least, all pywikipedia bots on the toolserver will edit over IPv6 - and I think a lot of the non-pywikipedia bots also, unless they resolve IP addresses manually. Of course, they won't edit anonymously, so you'll only see it in the access logs.
See also the pywikipedia-l post about it: http://lists.wikimedia.org/pipermail/pywikipedia-l/2012-June/007539.html
Best, Merlijn
On Thu, Jun 07, 2012 at 09:26:25AM +0200, Merlijn van Deen wrote:
On 7 June 2012 00:46, Erik Moeller erik@wikimedia.org wrote:
So far it seems to be working fine. We're seeing some edits being made over IPv6, and IPv6 traffic is in the low tens of Mbps range.
At the very least, all pywikipedia bots on the toolserver will edit over IPv6 - and I think a lot of the non-pywikipedia bots also, unless they resolve IP addresses manually. Of course, they won't edit anonymously, so you'll only see it in the access logs.
Speaking of the toolserver, does anyone happen to know which IPv6 addresses belong to it? Just looking in DNS, it seems the named servers are currently in 2620:0:862:101::2:0/124, with some other toolserver.org addresses resolving in 2620:0:862:101::1:3/124 and 2620:0:862:101::3:0/124.
Once figured out, might be a good idea to add them to: https://meta.wikimedia.org/wiki/User:Jonathan_de_Boyne_Pollard/Guide_to_bloc...
DJ
On Thu, Jun 7, 2012 at 4:04 PM, Brad Jorsch b-jorsch@alum.northwestern.edu wrote:
On Thu, Jun 07, 2012 at 09:26:25AM +0200, Merlijn van Deen wrote:
On 7 June 2012 00:46, Erik Moeller erik@wikimedia.org wrote:
So far it seems to be working fine. We're seeing some edits being made over IPv6, and IPv6 traffic is in the low tens of Mbps range.
At the very least, all pywikipedia bots on the toolserver will edit over IPv6 - and I think a lot of the non-pywikipedia bots also, unless they resolve IP addresses manually. Of course, they won't edit anonymously, so you'll only see it in the access logs.
Speaking of the toolserver, does anyone happen to know which IPv6 addresses belong to it? Just looking in DNS, it seems the named servers are currently in 2620:0:862:101::2:0/124, with some other toolserver.org addresses resolving in 2620:0:862:101::1:3/124 and 2620:0:862:101::3:0/124.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The first IPv6 edit to English Wikipedia required suppression, I have been advised, so I think there are some valid concerns about the implications this change will have on vandalism management.
Does nobody else see the issues associated with having what little guidance there is about IPv6 locked into pages in user space on a single project, when this is a global change?
Risker/Anne
On 7 June 2012 13:49, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:
Once figured out, might be a good idea to add them to:
https://meta.wikimedia.org/wiki/User:Jonathan_de_Boyne_Pollard/Guide_to_bloc...
DJ
On Thu, Jun 7, 2012 at 4:04 PM, Brad Jorsch b-jorsch@alum.northwestern.edu wrote:
On Thu, Jun 07, 2012 at 09:26:25AM +0200, Merlijn van Deen wrote:
On 7 June 2012 00:46, Erik Moeller erik@wikimedia.org wrote:
So far it seems to be working fine. We're seeing some edits being made over IPv6, and IPv6 traffic is in the low tens of Mbps range.
At the very least, all pywikipedia bots on the toolserver will edit over IPv6 - and I think a lot of the non-pywikipedia bots also, unless they resolve IP addresses manually. Of course, they won't edit anonymously, so you'll only see it in the access logs.
Speaking of the toolserver, does anyone happen to know which IPv6 addresses belong to it? Just looking in DNS, it seems the named servers are currently in 2620:0:862:101::2:0/124, with some other toolserver.org addresses resolving in 2620:0:862:101::1:3/124 and 2620:0:862:101::3:0/124.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Risker wrote:
The first IPv6 edit to English Wikipedia required suppression, I have been advised, so I think there are some valid concerns about the implications this change will have on vandalism management.
Does nobody else see the issues associated with having what little guidance there is about IPv6 locked into pages in user space on a single project, when this is a global change?
There's already https://meta.wikimedia.org/wiki/IPv6_initiative. Just move that user page[1] to a subpage of IPv6 initiative or something? You have an account at Meta-Wiki, as I recall. :-)
MZMcBride
[1] https://meta.wikimedia.org/wiki/User:Jonathan_de_Boyne_Pollard/Guide_to_bloc king_IP_version_6_addresses
2012/6/7 Risker risker.wp@gmail.com:
The first IPv6 edit to English Wikipedia required suppression, I have been advised, so I think there are some valid concerns about the implications this change will have on vandalism management.
Does nobody else see the issues associated with having what little guidance there is about IPv6 locked into pages in user space on a single project, when this is a global change?
Risker, I think you're over-reacting here. Yes, there are risks associated with IPv6. No, they haven't been addressed completely before IPv6 day (apparently because of the very late moment the decision to participate was taken). But it hasn't destroyed the projects so far and chances are, by the time IPv6 vandalism will have any significant effect, they will be solved (estimates are that 50% of the Internet users will have IPv6 only in 6 years [1]).
I will compare this with the SOPA blackout (and the equivalent event on it.wp). Back then, there were people talking about the negative effects the blackout will have on the credibility of Wikipedia. The blackout happened and passed without any significant drop in pageviews, but with huge media and popular attention.
IPv6 is now in a stage where it needs that kind of attention. There are only 3 countries in the world with more than 1% of IPv6 users [2][3], and in one of them there are still troubles with the new protocol. If there is little content available on IPv6, people will not even be aware it exists and they will not demand it from their ISP, which means there will be no users for IPv6 content making it useless and the loop will continue. Someone had to break this loop and the content providers were the easiest place this could happen.
It is good to have people aware of the problems ahead, but just crying wolf does not really help.
Strainu
[1] http://www.enterprisenetworkingplanet.com/netsp/ipv6-launch-day.-how-many-pe... [2] http://www.google.com/ipv6/statistics.html#tab=per-country-ipv6-adoption [3] AFAIK, in both Romania and France, the huge percentages are due to a single ISP providing "experimental" IPv6 connection
(both links come from the Slashdot stopry: http://tech.slashdot.org/story/12/06/07/1752201/after-launch-day-taking-stoc... )
On Fri, Jun 8, 2012 at 4:14 PM, Strainu strainu10@gmail.com wrote:
IPv6 is now in a stage where it needs that kind of attention. There are only 3 countries in the world with more than 1% of IPv6 users
Correction: 4 :) Bhutan was too small to see on the global map (and it's actually the leader, at 8.18% IPv6 adoption).
And it can be seen on [1] btw.
[1] http://www.google.com/intl/en_ALL/ipv6/statistics/data/worldmap.js
-Liangent
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8 June 2012 04:08, Strainu strainu10@gmail.com wrote:
2012/6/7 Risker risker.wp@gmail.com:
The first IPv6 edit to English Wikipedia required suppression, I have
been
advised, so I think there are some valid concerns about the implications this change will have on vandalism management.
Does nobody else see the issues associated with having what little
guidance
there is about IPv6 locked into pages in user space on a single project, when this is a global change?
Risker, I think you're over-reacting here. Yes, there are risks associated with IPv6. No, they haven't been addressed completely before IPv6 day (apparently because of the very late moment the decision to participate was taken). But it hasn't destroyed the projects so far and chances are, by the time IPv6 vandalism will have any significant effect, they will be solved (estimates are that 50% of the Internet users will have IPv6 only in 6 years [1]).
I will compare this with the SOPA blackout (and the equivalent event on it.wp). Back then, there were people talking about the negative effects the blackout will have on the credibility of Wikipedia. The blackout happened and passed without any significant drop in pageviews, but with huge media and popular attention.
IPv6 is now in a stage where it needs that kind of attention. There are only 3 countries in the world with more than 1% of IPv6 users [2][3], and in one of them there are still troubles with the new protocol. If there is little content available on IPv6, people will not even be aware it exists and they will not demand it from their ISP, which means there will be no users for IPv6 content making it useless and the loop will continue. Someone had to break this loop and the content providers were the easiest place this could happen.
It is good to have people aware of the problems ahead, but just crying wolf does not really help.
I have never said that moving to IPv6 is a bad idea. What I am
complaining about is the dismissive attitude taken toward the volunteers that are stuck cleaning up the mess when Engineering decides to do something, apparently on the spur of the moment, without telling anyone outside their own little walled garden. It would have taken one email to the Checkuser mailing list two months ago saying "We're really serious about trying to get IPv6 up and running for June 5" and people would have been pulling together the resources and making the software changes for the various tools we use. But no, we're told we're being wimps for having the nerve to complain that we've just been steamrollered, and that advance notice and the opportunity to plan are unimportant. Bluntly put, you're not the ones cleaning up the mess, we are; our job is easier if we have time to order in the extra mops.
Earlier, Erik said: "Regarding privacy, both IPv4 and IPv6 addresses can be dangerously revealing in terms of personal identity (e.g. some ISPs even tie street address information to your IPv4 address). It's always been fundamentally problematic that MediaWiki reveals this information nakedly, and it's what enabled past large-scale investigations like WikiScanner, for good and for ill. In the mid to long term, I believe we need to investigate moving away from full disclosure of IP addresses when editing without logging in, but this is independent of IPv4/IPv6."
Do this now, please. Even I can see how easy it ought to be to replace the last three digits of an IPv4 address with XXX in publicly viewable lists and logs....and reduce the publicly visible IPv6 string to its first three segments. That will suffice until a brighter idea comes to the fore. The WMF projects are the *only* major user-interactive website that takes this cavalier attitude toward what the rest of the world is increasingly viewing as personal information, and about 30% of the suppression requests coming in at English Wikipedia relate to IP addresses of users who accidentally edit logged out, or new users who didn't really understand that their IP would show when they edited.
The issues I point out with the IPv6 transition are social issues. Nobody expects Engineering to go all touchy-feely. But we do expect to be treated with respect. Next time, give us a month or two of warning. And please don't insult people by pretending this was a spur of the moment decision: the more I read, the more clear it is that for months IPv6 Day was the target for bringing this online.
Best,
Risker
I have never said that moving to IPv6 is a bad idea. What I am complaining about is the dismissive attitude taken toward the volunteers that are stuck cleaning up the mess when Engineering decides to do something, apparently on the spur of the moment, without telling anyone outside their own little walled garden. It would have taken one email to the Checkuser mailing list two months ago saying "We're really serious about trying to get IPv6 up and running for June 5" and people would have been pulling together the resources and making the software changes for the various tools we use. But no, we're told we're being wimps for having the nerve to complain that we've just been steamrollered, and that advance notice and the opportunity to plan are unimportant. Bluntly put, you're not the ones cleaning up the mess, we are; our job is easier if we have time to order in the extra mops.
Your tone is non-helpful. Maybe you should take a day or two to calm yourself.
We're not being dismissive; this truly was a spur of the moment thing. We had thoughts we might do this for IPv6 day, just like we did last year, but higher priority work constantly comes up. At the last minute we decided to kill this off at the hackathon (which, by the way, last year's hackathon is when we started this work on the ops side).
That said, it's pretty obvious that IPv6 has been coming for years. It's been supported in the software for quite some time, and we're actively running out of IPv4 addresses (I used one of our last available IPv4 addresses in esams for HTTPS last year). There are a lot of bugs in bugzilla about it. I don't think it's fair to blame the engineers for lack of foresight.
- Ryan
2012/6/8 Risker risker.wp@gmail.com:
The issues I point out with the IPv6 transition are social issues. Nobody expects Engineering to go all touchy-feely. But we do expect to be treated with respect. Next time, give us a month or two of warning. And please don't insult people by pretending this was a spur of the moment decision: the more I read, the more clear it is that for months IPv6 Day was the target for bringing this online.
Hi, First of all, let me clear up any possible misunderstanding: I am not affiliated with the Engineering team other than being a programmer myself and having an insight on how cool, but non-core ideas (such as IPv6 for the WMF) are pushed in such an environment. I also agree that the WMF has more than once ignored the communities.
But from the same discussions that you read, my impression is that, while it was clear since 11/6/6 for everybody that the best moment for deployment was 12/6/6, the actual testing and bugfixing began very close to the due date. This is why I said the decision was taken in the last minute. I also don't agree with your implication that there is much mess to be picked-up after the IPv6 rollup, nor with your suggested solution - the checkuser distribution list is much too limited for the implications of this deployment.
Ryan has sent his email while I was composing mine so I might be repeating some of the stuff he said, but he made a decent justification of why this was a last-minute decision.
All the best to you too, Strainu
I don't think that Risker is wrong, it is true, that ipv6 was enabled on production almost with no warning and since it wasn't available on any test site before, neither on wmflabs it was almost impossible for developers to fix all issues in tools related to this. For example one of tools that broke was huggle, people are complaining now at us (huggle devs) that it doesn't work, and my reply is: We knew that, we know that, but no one gave us a chance to prepare. I have no working ipv6 wiki I could test it on, neither there is any on wmflabs. So when it was enabled on production we couldn't be prepared for this. Huggle is not the only tool which broke, there are many others and devs never had a chance to adapt to ipv6 without any test wiki to try it on.
On Fri, Jun 8, 2012 at 1:13 PM, Strainu strainu10@gmail.com wrote:
2012/6/8 Risker risker.wp@gmail.com:
The issues I point out with the IPv6 transition are social issues. Nobody expects Engineering to go all touchy-feely. But we do expect to be treated with respect. Next time, give us a month or two of warning. And please don't insult people by pretending this was a spur of the moment decision: the more I read, the more clear it is that for months IPv6 Day was the target for bringing this online.
Hi, First of all, let me clear up any possible misunderstanding: I am not affiliated with the Engineering team other than being a programmer myself and having an insight on how cool, but non-core ideas (such as IPv6 for the WMF) are pushed in such an environment. I also agree that the WMF has more than once ignored the communities.
But from the same discussions that you read, my impression is that, while it was clear since 11/6/6 for everybody that the best moment for deployment was 12/6/6, the actual testing and bugfixing began very close to the due date. This is why I said the decision was taken in the last minute. I also don't agree with your implication that there is much mess to be picked-up after the IPv6 rollup, nor with your suggested solution - the checkuser distribution list is much too limited for the implications of this deployment.
Ryan has sent his email while I was composing mine so I might be repeating some of the stuff he said, but he made a decent justification of why this was a last-minute decision.
All the best to you too, Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Jun 8, 2012 at 7:36 AM, Petr Bena benapetr@gmail.com wrote:
I don't think that Risker is wrong, it is true, that ipv6 was enabled on production almost with no warning and since it wasn't available on any test site before, neither on wmflabs it was almost impossible for developers to fix all issues in tools related to this. For example one of tools that broke was huggle, people are complaining now at us (huggle devs) that it doesn't work, and my reply is: We knew that, we know that, but no one gave us a chance to prepare. I have no working ipv6 wiki I could test it on, neither there is any on wmflabs. So when it was enabled on production we couldn't be prepared for this. Huggle is not the only tool which broke, there are many others and devs never had a chance to adapt to ipv6 without any test wiki to try it on.
Not true--I tested (and fixed) several IPv6 bugs years ago. Labs may not have been setup for IPv6, but as long as your operating system supports IPv6 there's no reason you can't test it locally.
Without getting too far OT, I'd like to mention that labs does not have feature parity with the production sites (yet). This is the way it's been for years, and until we get more things available to labs, we should test our code the way we've always done it--locally. I don't think it's reasonable to hold up projects *just because* they haven't been through labs yet.
-Chad
On 8 June 2012 11:49, Risker risker.wp@gmail.com wrote:
I have never said that moving to IPv6 is a bad idea. What I am complaining about is the dismissive attitude taken toward the volunteers that are stuck cleaning up the mess when Engineering decides to do something, apparently on the spur of the moment, without telling anyone outside their own little walled garden.
No, at this point you're just being deliberate rude. People have already noted on this thread that this has been in the works for years, whether you were listening or not.
- d.
On 8 June 2012 07:33, David Gerard dgerard@gmail.com wrote:
On 8 June 2012 11:49, Risker risker.wp@gmail.com wrote:
I have never said that moving to IPv6 is a bad idea. What I am complaining about is the dismissive attitude taken toward the volunteers that are stuck cleaning up the mess when Engineering decides to do something, apparently on the spur of the moment, without telling anyone outside their own little walled garden.
No, at this point you're just being deliberate rude. People have already noted on this thread that this has been in the works for years, whether you were listening or not.
The problem was never IPv6. The problem was always about the unspoken expectation that everyone else would just drop everything else they have going on to patch up all the stuff that got broken as a result of this sudden change. I get that this was an exciting step for the engineers who got it done, and I tip my hat to all of them for pulling it off; from that sense it's been a successful implementation. I also get that at least 30% of WMF users on hundreds of projects -that's roughly how many use one or more gadgets, scripts or tools that didn't work after this switch - have now had their "editing experience" negatively affected, and that almost all of it could have been avoided with a month or two of notice so that patches could be written and resources could be put into place in advance. One has to hope this was a knowledge gap and that Engineering did not actually know the extent to which it would impact the projects and the end-users.
Engineering has worked very hard over the last couple of years to improve its communication processes, to re-integrate with the various communities, and to become more responsive to the hundreds of volunteers who work on engineering projects as well as the tens of thousands who use the product on WMF sites. This has made a big difference in the acceptance and success of its innovations and work. It's really sad to see the reversion to the deprecated pattern of poor communication over such a significant and important change.
Risker
The problem was never IPv6. The problem was always about the unspoken expectation that everyone else would just drop everything else they have going on to patch up all the stuff that got broken as a result of this sudden change. I get that this was an exciting step for the engineers who got it done, and I tip my hat to all of them for pulling it off; from that sense it's been a successful implementation. I also get that at least 30% of WMF users on hundreds of projects -that's roughly how many use one or more gadgets, scripts or tools that didn't work after this switch - have now had their "editing experience" negatively affected, and that almost all of it could have been avoided with a month or two of notice so that patches could be written and resources could be put into place in advance. One has to hope this was a knowledge gap and that Engineering did not actually know the extent to which it would impact the projects and the end-users.
Are the breakages on the site really that massive? We've been getting little to no reports of breakages.
If you are asking for us to notify the community earlier, I accept that. We did this last minute because we wanted to participate on IPv6 day, and we had a few free days to do so right before it. I apologize that it's poorly affecting your workflow, but your level of anger is unwarranted. We've been pretty good about announcing things in general. All user-facing HTTPS changes were announced weeks before they were made, for instance. Remember, that this is the ops group you're complaining about, and not engineering as a whole, and we rarely make user-facing changes.
If you are complaining about things being broken, we need to know exactly what they are, or we can't help. Tell us whats broken here, or even better, add some bugs.
- Ryan
On 8 June 2012 10:12, Ryan Lane rlane32@gmail.com wrote:
The problem was never IPv6. The problem was always about the unspoken expectation that everyone else would just drop everything else they have going on to patch up all the stuff that got broken as a result of this sudden change. I get that this was an exciting step for the engineers
who
got it done, and I tip my hat to all of them for pulling it off; from
that
sense it's been a successful implementation. I also get that at least
30%
of WMF users on hundreds of projects -that's roughly how many use one or more gadgets, scripts or tools that didn't work after this switch - have now had their "editing experience" negatively affected, and that almost
all
of it could have been avoided with a month or two of notice so that
patches
could be written and resources could be put into place in advance. One
has
to hope this was a knowledge gap and that Engineering did not actually
know
the extent to which it would impact the projects and the end-users.
Are the breakages on the site really that massive? We've been getting little to no reports of breakages.
From what I understand, most of these breakages are in tools and scripts
developed and operated by volunteer developers, not WMF developers. The big one is Huggle, which on enwp is used by a large majority of admins and recent changes patrollers. There are additional notes on the enwp village pump (technical) that appear to be related, although I do not have the expertise to assess this. I have been told that there are parallel issues on some of the other large projects, although I don't have direct knowledge.
If you are asking for us to notify the community earlier, I accept that. We did this last minute because we wanted to participate on IPv6 day, and we had a few free days to do so right before it. I apologize that it's poorly affecting your workflow, but your level of anger is unwarranted. We've been pretty good about announcing things in general. All user-facing HTTPS changes were announced weeks before they were made, for instance. Remember, that this is the ops group you're complaining about, and not engineering as a whole, and we rarely make user-facing changes.
Yes, the team has been good at giving advance heads-ups, even for things that are relatively low impact, and it has been a very positive experience. Thus this unexpectedly short notice is more jarring.
I think one opportunity that was not considered was taking it live on IPv6 Day as a "trial" and then pulling it back to allow everyone else to fix what didn't work during the trial day. Yes, it is important to test things; no, it's not necessary to make a permanent change without assessing the results of the test.
If you are complaining about things being broken, we need to know exactly what they are, or we can't help. Tell us whats broken here, or even better, add some bugs.
As I've noted, almost everything I'm aware of that is genuinely not functioning correctly is stuff that is written by and maintained by volunteer developers, not the WMF, so bugzillas aren't going to help here. For non-WMF related reasons, I use very few scripts, gadgets or tools so I don't have the experience to tell you which volunteer-produced tools are or are not functioning well.
Risker
On 8 June 2012 16:18, Risker risker.wp@gmail.com wrote:
On 8 June 2012 10:12, Ryan Lane rlane32@gmail.com wrote:
The problem was never IPv6. The problem was always about the unspoken expectation that everyone else would just drop everything else they have going on to patch up all the stuff that got broken as a result of this sudden change. I get that this was an exciting step for the engineers
who
got it done, and I tip my hat to all of them for pulling it off; from
that
sense it's been a successful implementation. I also get that at least
30%
of WMF users on hundreds of projects -that's roughly how many use one or more gadgets, scripts or tools that didn't work after this switch - have now had their "editing experience" negatively affected, and that almost
all
of it could have been avoided with a month or two of notice so that
patches
could be written and resources could be put into place in advance. One
has
to hope this was a knowledge gap and that Engineering did not actually
know
the extent to which it would impact the projects and the end-users.
Are the breakages on the site really that massive? We've been getting little to no reports of breakages.
From what I understand, most of these breakages are in tools and scripts developed and operated by volunteer developers, not WMF developers. The big one is Huggle, which on enwp is used by a large majority of admins and recent changes patrollers. There are additional notes on the enwp village pump (technical) that appear to be related, although I do not have the expertise to assess this. I have been told that there are parallel issues on some of the other large projects, although I don't have direct knowledge.
I only see one report of IPv6 problems at the village pump: https://en.wikipedia.org/wiki/Wikipedia:Vpt#MediaWiki:Sp-contributions-foote... That was a template which was fixed within a few hours.
Note that the API has had some downtime recently, which has been wreaking havoc on various scripts and tools. So many of the reports at the village pump are unrelated to IPv6.
Pete / the wub
Are the breakages on the site really that massive? We've been getting little to no reports of breakages.
From what I understand, most of these breakages are in tools and scripts developed and operated by volunteer developers, not WMF developers. The big one is Huggle, which on enwp is used by a large majority of admins and recent changes patrollers. There are additional notes on the enwp village pump (technical) that appear to be related, although I do not have the expertise to assess this. I have been told that there are parallel issues on some of the other large projects, although I don't have direct knowledge.
Petr mentioned huggle on list. I just checked the enwiki village pump and don't see a single complaint. In fact, I see comments in the IPv6 section saying things like "we've been anticipating this for years".
If you are asking for us to notify the community earlier, I accept that. We did this last minute because we wanted to participate on IPv6 day, and we had a few free days to do so right before it. I apologize that it's poorly affecting your workflow, but your level of anger is unwarranted. We've been pretty good about announcing things in general. All user-facing HTTPS changes were announced weeks before they were made, for instance. Remember, that this is the ops group you're complaining about, and not engineering as a whole, and we rarely make user-facing changes.
Yes, the team has been good at giving advance heads-ups, even for things that are relatively low impact, and it has been a very positive experience. Thus this unexpectedly short notice is more jarring.
Again the actual implementation date wasn't announced, but it's been known for years that we'd enable IPv6.
I think one opportunity that was not considered was taking it live on IPv6 Day as a "trial" and then pulling it back to allow everyone else to fix what didn't work during the trial day. Yes, it is important to test things; no, it's not necessary to make a permanent change without assessing the results of the test.
That makes no sense. How are people going fix things when they have no place to test the fixes? Unless massive portions of the site are broken, or there's rampant vandalism that can't be fixed, it's silly to disable IPv6.
If you are complaining about things being broken, we need to know exactly what they are, or we can't help. Tell us whats broken here, or even better, add some bugs.
As I've noted, almost everything I'm aware of that is genuinely not functioning correctly is stuff that is written by and maintained by volunteer developers, not the WMF, so bugzillas aren't going to help here. For non-WMF related reasons, I use very few scripts, gadgets or tools so I don't have the experience to tell you which volunteer-produced tools are or are not functioning well.
From what I'm seeing, there's not many complaints, and not much that's
actually broken. When things are really broken, we tend to hear about it from a number of people.
I don't want to sound dismissive, but other than a lack of communication about the date of deployment, I'm not seeing the problem here.
- Ryan
On Fri, 08 Jun 2012 03:49:01 -0700, Risker risker.wp@gmail.com wrote:
On 8 June 2012 04:08, Strainu strainu10@gmail.com wrote:
2012/6/7 Risker risker.wp@gmail.com:
The first IPv6 edit to English Wikipedia required suppression, I have
been
advised, so I think there are some valid concerns about the
implications
this change will have on vandalism management.
Does nobody else see the issues associated with having what little
guidance
there is about IPv6 locked into pages in user space on a single
project,
when this is a global change?
Risker, I think you're over-reacting here. Yes, there are risks associated with IPv6. No, they haven't been addressed completely before IPv6 day (apparently because of the very late moment the decision to participate was taken). But it hasn't destroyed the projects so far and chances are, by the time IPv6 vandalism will have any significant effect, they will be solved (estimates are that 50% of the Internet users will have IPv6 only in 6 years [1]).
I will compare this with the SOPA blackout (and the equivalent event on it.wp). Back then, there were people talking about the negative effects the blackout will have on the credibility of Wikipedia. The blackout happened and passed without any significant drop in pageviews, but with huge media and popular attention.
IPv6 is now in a stage where it needs that kind of attention. There are only 3 countries in the world with more than 1% of IPv6 users [2][3], and in one of them there are still troubles with the new protocol. If there is little content available on IPv6, people will not even be aware it exists and they will not demand it from their ISP, which means there will be no users for IPv6 content making it useless and the loop will continue. Someone had to break this loop and the content providers were the easiest place this could happen.
It is good to have people aware of the problems ahead, but just crying wolf does not really help.
I have never said that moving to IPv6 is a bad idea. What I am complaining about is the dismissive attitude taken toward the volunteers that are stuck cleaning up the mess when Engineering decides to do something, apparently on the spur of the moment, without telling anyone outside their own little walled garden. It would have taken one email to the Checkuser mailing list two months ago saying "We're really serious about trying to get IPv6 up and running for June 5" and people would have been pulling together the resources and making the software changes for the various tools we use. But no, we're told we're being wimps for having the nerve to complain that we've just been steamrollered, and that advance notice and the opportunity to plan are unimportant. Bluntly put, you're not the ones cleaning up the mess, we are; our job is easier if we have time to order in the extra mops.
Earlier, Erik said: "Regarding privacy, both IPv4 and IPv6 addresses can be dangerously revealing in terms of personal identity (e.g. some ISPs even tie street address information to your IPv4 address). It's always been fundamentally problematic that MediaWiki reveals this information nakedly, and it's what enabled past large-scale investigations like WikiScanner, for good and for ill. In the mid to long term, I believe we need to investigate moving away from full disclosure of IP addresses when editing without logging in, but this is independent of IPv4/IPv6."
Do this now, please. Even I can see how easy it ought to be to replace the last three digits of an IPv4 address with XXX in publicly viewable lists and logs....and reduce the publicly visible IPv6 string to its first three segments.
It's not. This is not something simple to do technically.
The first thing you have to get out of the way is the fact that we only have one api interface where a user attached ip comes from. This is used by both internals and public facing things. This means we can't make tweaks in single spots to deal with this. If the system didn't completely fall apart from the attempt, then at the least every single ip block would become a range block.
So with the possibility of a simple backend change out of the way there's only one other option. Change the public facing places where ips are used. Except ips are used every single place a user name is used. So every place a user name is used needs to be changed. It needs to understand the difference between an ip and a username and needs to do something different for the ip. The problem there however is that we have numerous places this is done in. This is not something simple to do because it would require whoever takes this task on to go through our entire huge codebase and track down every spot a username is used, figure it if it's public facing or internal, and then modify it. Inevitably spots are going to be missed and this will become a continual game of duck taping hole after hole in a boat that looks like swiss cheese.
And this gets worse when you think of one other factor. Extensions. MediaWiki isn't the only thing that displays this stuff. Extensions do to. That means that not only does our massive core need to be modified, but every extension needs to be modified as well.
And that's just the technical issue. What happens to our anon talkpages and contribution lists when all this information disappears? I doubt that sysops are the only people who deal with users from individual ips.
This isn't a simple technical issue to solve. Whatever we do is going to require a large change to the MediaWiki codebase to even function. More to work the way it really should. And likely actually going to require restructuring how MediaWiki handles some things and getting rid of some of the assumptions made in code. But before that. It's going to require someone coming forward with a really good idea on how we can have MediaWiki work with anonymous contributions in the ideal way.
That will suffice until a brighter idea comes to the fore. The WMF projects are the *only* major user-interactive website that takes this cavalier attitude toward what the rest of the world is increasingly viewing as personal information, and about 30% of the suppression requests coming in at English Wikipedia relate to IP addresses of users who accidentally edit logged out, or new users who didn't really understand that their IP would show when they edited.
The issues I point out with the IPv6 transition are social issues. Nobody expects Engineering to go all touchy-feely. But we do expect to be treated with respect. Next time, give us a month or two of warning. And please don't insult people by pretending this was a spur of the moment decision: the more I read, the more clear it is that for months IPv6 Day was the target for bringing this online.
Best,
Risker
On Sat, Jun 9, 2012 at 7:51 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Fri, 08 Jun 2012 03:49:01 -0700, Risker risker.wp@gmail.com wrote:
Do this now, please. Even I can see how easy it ought to be to replace the last three digits of an IPv4 address with XXX in publicly viewable lists and logs....and reduce the publicly visible IPv6 string to its first three segments.
It's not. This is not something simple to do technically.
When someone edits without being logged in, automatically log them in under a newly created username "X.Y.Z.xxx #N", where N is just the lowest number which creates a unique name.
(Of course, if you're going to do that, just abandon the whole IP address thing altogether. When a user who is not logged in gets to the edit screen, there are two extra fields: username and password. Username is pre-filled with "Random User #NNNNNNNN", where NNNNNNNN is a random not-yet-used number.)
Is there a bugzilla feature request for hiding IP addresses?
Another solution: add a new database table that maps IP addresses to some kind of key. Let's call it IP-key. Almost everywhere where now the IP is used, use IP-key instead. Only resolve IP-key to IP (and vice versa) when you have to.
Doesn't sound like a huge effort, but I guess it would take at least a few days to weeks to implement.
I don't know how the difference between IPs and usernames is currently handled in MediaWiki. If it's a syntactical check if a username 'looks like' an IP, then an IP-key should 'look like' an IP. Which may lead to confusion...
JC On Jun 9, 2012 2:40 PM, "Anthony" wikimail@inbox.org wrote:
On Sat, Jun 9, 2012 at 7:51 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Fri, 08 Jun 2012 03:49:01 -0700, Risker risker.wp@gmail.com wrote:
Do this now, please. Even I can see how easy it ought to be to replace the last three digits of an IPv4 address with XXX in publicly viewable lists and logs....and reduce the publicly visible IPv6 string to its first
three
segments.
It's not. This is not something simple to do technically.
When someone edits without being logged in, automatically log them in under a newly created username "X.Y.Z.xxx #N", where N is just the lowest number which creates a unique name.
(Of course, if you're going to do that, just abandon the whole IP address thing altogether. When a user who is not logged in gets to the edit screen, there are two extra fields: username and password. Username is pre-filled with "Random User #NNNNNNNN", where NNNNNNNN is a random not-yet-used number.)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This thread has drifted from IPv6 deployment to "showing IP addresses of edits is bad".
Please open a new thread if you want to continue discussing it. And be prepared to justify why is it so evil to show the IP address of the author of an edit. IPs magically disappear if you just open an account.
On Fri, Jun 8, 2012 at 4:08 AM, Strainu strainu10@gmail.com wrote:
Risker, I think you're over-reacting here. Yes, there are risks associated with IPv6. No, they haven't been addressed completely before IPv6 day (apparently because of the very late moment the decision to participate was taken). But it hasn't destroyed the projects so far and chances are, by the time IPv6 vandalism will have any significant effect, they will be solved (estimates are that 50% of the Internet users will have IPv6 only in 6 years [1]).
You seem to be assuming that vandals will switch to IPv6 at the same rate as non-vandals.
An analogous assumption, which has proven to be false, would be that vandals would use anonymizing proxies at the same rate as non-vandals.
If there is little content available on IPv6, people will not even be aware it exists and they will not demand it from their ISP, which means there will be no users for IPv6 content making it useless and the loop will continue. Someone had to break this loop and the content providers were the easiest place this could happen.
No one has to break the loop. The loop will break itself. Either enough people will get sick of NAT to cause demand for IPv6, or they won't.
2012/6/8 Anthony wikimail@inbox.org:
You seem to be assuming that vandals will switch to IPv6 at the same rate as non-vandals.
An analogous assumption, which has proven to be false, would be that vandals would use anonymizing proxies at the same rate as non-vandals.
Perhaps. There's no way to know unless we try.
If there is little content available on IPv6, people will not even be aware it exists and they will not demand it from their ISP, which means there will be no users for IPv6 content making it useless and the loop will continue. Someone had to break this loop and the content providers were the easiest place this could happen.
No one has to break the loop. The loop will break itself. Either enough people will get sick of NAT to cause demand for IPv6, or they won't.
That one way of seeing things, but I fear it's a bit simplistic and naive. People won't "get sick of NAT", since most of them don't know what NAT is anyway. They'll just notice that "the speed sucks" or that they can't edit Wikipedia because their public IP was blocked. But they won't know IPv6 is (part of) the solution unless someone tells them to, by events like the IPv6 day.
Strainu
On Fri, Jun 8, 2012 at 9:59 AM, Strainu strainu10@gmail.com wrote:
2012/6/8 Anthony wikimail@inbox.org:
No one has to break the loop. The loop will break itself. Either enough people will get sick of NAT to cause demand for IPv6, or they won't.
That one way of seeing things, but I fear it's a bit simplistic and naive. People won't "get sick of NAT", since most of them don't know what NAT is anyway. They'll just notice that "the speed sucks" or that they can't edit Wikipedia because their public IP was blocked. But they won't know IPv6 is (part of) the solution unless someone tells them to, by events like the IPv6 day.
Or by the ISP which provides IPv6 advertising those faster speeds or decreased privacy.
On Sat, Jun 9, 2012 at 4:29 PM, Anthony wikimail@inbox.org wrote:
On Fri, Jun 8, 2012 at 9:59 AM, Strainu strainu10@gmail.com wrote:
2012/6/8 Anthony wikimail@inbox.org:
No one has to break the loop. The loop will break itself. Either enough people will get sick of NAT to cause demand for IPv6, or they won't.
That one way of seeing things, but I fear it's a bit simplistic and naive. People won't "get sick of NAT", since most of them don't know what NAT is anyway. They'll just notice that "the speed sucks" or that they can't edit Wikipedia because their public IP was blocked. But they won't know IPv6 is (part of) the solution unless someone tells them to, by events like the IPv6 day.
Or by the ISP which provides IPv6 advertising those faster speeds or decreased privacy.
Here at BestISP, we assign you a unique number that you can never change! We attach this unique number to all your Internet communications, so that every time you go back to a website, that website knows they're dealing with the same person.
Switch to BestISP! 1% faster communications, and the increased ability for websites to track you!
Anthony wikimail@inbox.org wrote:
On Sat, Jun 9, 2012 at 4:29 PM, Anthony wikimail@inbox.org wrote:
On Fri, Jun 8, 2012 at 9:59 AM, Strainu strainu10@gmail.com wrote:
2012/6/8 Anthony wikimail@inbox.org:
No one has to break the loop. The loop will break itself. Either enough people will get sick of NAT to cause demand for IPv6, or they won't.
That one way of seeing things, but I fear it's a bit simplistic and naive. People won't "get sick of NAT", since most of them don't know what NAT is anyway. They'll just notice that "the speed sucks" or that they can't edit Wikipedia because their public IP was blocked. But they won't know IPv6 is (part of) the solution unless someone tells them to, by events like the IPv6 day.
Or by the ISP which provides IPv6 advertising those faster speeds or decreased privacy.
Here at BestISP, we assign you a unique number that you can never change! We attach this unique number to all your Internet communications, so that every time you go back to a website, that website knows they're dealing with the same person.
Switch to BestISP! 1% faster communications, and the increased ability for websites to track you!
There are numerous reasons to have fixed IPv6 addresses per connection. For example, I have right now around 6 devices supporting IPv6 at home and I do connect between them internally (for example one of the is printer - my laptop prints on my printer no matter whether it is at home or somewhere else provided it has IPv6). You *DON'T* want to renumber your whole home network every time your ISP changes your IPv6 prefix.
Just because some people got away with the stuff they do on the Internet because their ISP changes their IPv4 address every so and then does not mean that dynamic IPv4 address provides *any* privacy.
I could argue that current scheme w/dynamic IPv4 provides less privacy in the long term for the user. One of the reasons for that is it is difficult to run your own infrastructure (like mail server, web server) on one's own residential connection and you have to rely on external (called "cloud" today) providers for that with obvious privacy consequences of that.
The whole point of IPv6 is to give the choice not to use external providers - you become part of the "cloud", not just a dumb consumer.
//Saper
On Sun, Jun 10, 2012 at 2:03 PM, Marcin Cieslak saper@saper.info wrote:
You *DON'T* want to renumber your whole home network every time your ISP changes your IPv6 prefix.
If only they had some service which converted easy to remember names into IPv6 addresses.....
Just because some people got away with the stuff they do on the Internet because their ISP changes their IPv4 address every so and then does not mean that dynamic IPv4 address provides *any* privacy.
A dynamic address (IPv4 or IPv6) generally provides *some* privacy above a static one. Not a lot, especially not without taking other measures, but some.
The whole point of IPv6 is to give the choice not to use external providers - you become part of the "cloud", not just a dumb consumer.
I didn't realize that was the whole point of IPv6.
In any case, I'd say most Internet users *want* to be treated as a dumb consumer, and not become part of the cloud.
Yes, there's a small portion of the population that wants to run their own webserver and own email server and maintain an always on computer, constantly updated with the latest security fixes, sitting in their DMZ. But not more than 4,294,967,296 of them.
On Tue, 12 Jun 2012 05:14:07 -0700, Anthony wikimail@inbox.org wrote:
On Sun, Jun 10, 2012 at 2:03 PM, Marcin Cieslak saper@saper.info wrote:
You *DON'T* want to renumber your whole home network every time your ISP changes your IPv6 prefix.
If only they had some service which converted easy to remember names into IPv6 addresses.....
You don't want to put DNS names inside of firewall rules. Some won't let you, and for others it's risky... ever read a manual? http://www.shorewall.net/configuration_file_basics.htm#dnsnames
IPv6 uses global addresses not internal ones (and for good reason). So if your prefix changes you have to rewrite firewall rules.
Forcing local networks using local addresses to host local data remotely is also ridiculous.
And just to sum it up. DNS != Automatic renumbering. Local network things like firewall config will not necessarily constantly check DNS for changes. Even if you do use DNS programs are liable to keep using the same IP addresses even after your network is renumbered.
Just because some people got away with the stuff they do on the Internet because their ISP changes their IPv4 address every so and then does not mean that dynamic IPv4 address provides *any* privacy.
A dynamic address (IPv4 or IPv6) generally provides *some* privacy above a static one. Not a lot, especially not without taking other measures, but some.
The whole point of IPv6 is to give the choice not to use external providers - you become part of the "cloud", not just a dumb consumer.
I didn't realize that was the whole point of IPv6.
In any case, I'd say most Internet users *want* to be treated as a dumb consumer, and not become part of the cloud.
Yes, there's a small portion of the population that wants to run their own webserver and own email server and maintain an always on computer, constantly updated with the latest security fixes, sitting in their DMZ. But not more than 4,294,967,296 of them.
This discussion has turned into a bit of a general IPv6 discussion, rather than a Wikipedia-on-IPv6 or Mediawiki-tools-IPv6-support discussion.
Marcin Cieslak wrote:
You *DON'T* want to renumber your whole home network every time your ISP changes your IPv6 prefix.
You probably don't want to *manually* renumber your whole home network every time your ISP changes your IPv6 prefix. But since your home network will use global IPv6 addresses, you will have to.
As a side-note: I don't think (and hope) that IPv6 prefix renumbering is very common; it sure is not needed like re-assigning IPv4 addresses was required. After all, IPv4 re-assigned was only introduced after they became scarce. Some will remember the time when end-users where assigned a whole block op IPv4 addresses (I still have 16 public IPv4 addresses at home).
Anyway, renumbering is probably just a matter of sending out a new prefix in the Router Advertisement message of the Neighbour Discovery Protocol. This happens automatically, so I don't see an issue here.
And for those few nerds who really don't want to renumber (for example, because they are multi-homed: e.g. have multiple ISP connections to their home), there is something called prefix renumbering, akin to NAT in IPv4.
For detailed info on IPv6 renumbering, please read http://tools.ietf.org/html/rfc4192 (This details the procedure for IPv6 renumbering of larger office networks).
Anthony wrote:
A dynamic address (IPv4 or IPv6) generally provides *some* privacy above a static one. Not a lot, especially not without taking other measures, but some.
An issue that was brought up earlier is that there is a significant change in IPv6: Most device and networks use stateless address autoconfiguration (SLAAC). By default, the MAC address of your computer is added to the network prefix (plus a 2-byte filler 0xFEFF to get to right number of bits). For example, the MAC address of my laptop is "00:23:6c:97:6c:e6" and the IPv6 address of at home might be: 2a01:238:43ed:a300:223:6cff:fe97:6ce6 while the IPv6 address of this laptop at work could be: 2001:610:108:2006:223:6cff:fe97:6ce6 Despite that the prefixes differ, you still know this is the same laptop because the last part of the address is the same. This allows a site such as Wikipedia to track users by their IP address, thus without cookies.
This problem has been acknowledged for quite some time, and the solution is something called "privacy extensions" for IPv6. The solution is that the host picks a random address, rather than using the MAC address, and change this random address about once per day.
These privacy extensions are supported by most (all?) major operating systems nowadays, so I do not seen any issue regarding privacy of IPv6 addresses anymore.
Details can be found in http://tools.ietf.org/html/rfc3041
Marcin Cieslak wrote:
The whole point of IPv6 is to give the choice not to use external providers - you become part of the "cloud", not just a dumb consumer.
I don't think so, but to be honest I have no clue what you are trying to say here. A consumer always need one (or more) network providers for connectivity. What *is* a non-external provider?
Also, remember that the work on IPv6 was started in 1994, and the IPv6 specification was published in 1998, well over 10 years ago. I can testify that "cloud" was not yet part of the obligatorily hype-speak at the time.
For the record: There have been about four proposals for IPNG, and the one that the IETF choose was one which only solved one issue: adding more addresses, and explicitly did not add any other features. Yes, there has been some talk about making IPsec manditory (thus theoretically making IPv6 more secure) but I don't think that has ever been implemented in practise, so there is no functional difference there. The only significant change of IPv6 over IPv4 is that it makes much better use of multicast, but that really is a small technical change that most users will never notice.
The only problem I still see with IPv6 related to Wikipedia is that it is so easy for vandals to get a new IP address, that blocking a single IPv6 address is not going to stop them. Hence, I suspect it is better to block a whole /64 prefix by default. To what extend this is a problem, and if this is indeed a good solution is best judged after gathering some actual vandalism statistics in the coming months.
Allow me to once more iterate my gratitude to the Mediawiki team and those present at the Berlin hackaton to make Wikipedia available over IPv6. Many of use already run Mediawiki over IPv6, but we all realise that doing it for Wikipedia is a different ballpark with all the Squid instances and separate backends. Given that I haven't seen any mention of major incidents, this only testifies for the overall quality of the software and infrastructure. Kudos.
Regards, Freek Dijkstra
On Thu, Jun 14, 2012 at 12:54 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
On Tue, 12 Jun 2012 05:14:07 -0700, Anthony wikimail@inbox.org wrote:
On Sun, Jun 10, 2012 at 2:03 PM, Marcin Cieslak saper@saper.info wrote:
You *DON'T* want to renumber your whole home network every time your ISP changes your IPv6 prefix.
If only they had some service which converted easy to remember names into IPv6 addresses.....
You don't want to put DNS names inside of firewall rules. Some won't let you, and for others it's risky... ever read a manual?
That comment was uncalled for.
IPv6 uses global addresses not internal ones (and for good reason).
IPv6 supports unique local addresses in addition to global addresses.
Forcing local networks using local addresses to host local data remotely is also ridiculous.
Well, I think I misunderstood what Marcin was saying. So, sorry about that.
But, on the other hand, there is nothing that prohibits people from hosting DNS only locally. If, for some reason, you want to use an IP address which is assigned by your ISP, for a host which is only accessible via the local network, then you might even want to do this. I'm not sure why you'd want to use an IP address which is assigned by your ISP for a host which is only supposed to be accessible via the local network, though.
On 9 June 2012 21:51, Anthony wikimail@inbox.org wrote:
Here at BestISP, we assign you a unique number that you can never change! We attach this unique number to all your Internet communications, so that every time you go back to a website, that website knows they're dealing with the same person. Switch to BestISP! 1% faster communications, and the increased ability for websites to track you!
Whereas in the real world, IPv4 static IPs are considered a cost-extra feature, and one source of IPv6 resistance at consumer ISPs has been that they couldn't sell said cost-extra feature with it.
- d.
On Sun, Jun 10, 2012 at 2:28 PM, David Gerard dgerard@gmail.com wrote:
On 9 June 2012 21:51, Anthony wikimail@inbox.org wrote:
Here at BestISP, we assign you a unique number that you can never change! We attach this unique number to all your Internet communications, so that every time you go back to a website, that website knows they're dealing with the same person. Switch to BestISP! 1% faster communications, and the increased ability for websites to track you!
Whereas in the real world, IPv4 static IPs are considered a cost-extra feature, and one source of IPv6 resistance at consumer ISPs has been that they couldn't sell said cost-extra feature with it.
Sure they can. There's nothing stopping them from charging more for static IPv6 vs. dynamic IPv6.
On 07/06/12 16:04, Brad Jorsch wrote:
At the very least, all pywikipedia bots on the toolserver will edit over IPv6 - and I think a lot of the non-pywikipedia bots also, unless they resolve IP addresses manually. Of course, they won't edit anonymously, so you'll only see it in the access logs.
Speaking of the toolserver, does anyone happen to know which IPv6 addresses belong to it? Just looking in DNS, it seems the named servers are currently in 2620:0:862:101::2:0/124, with some other toolserver.org addresses resolving in 2620:0:862:101::1:3/124 and 2620:0:862:101::3:0/124.
A little playing shows:
hemlock 2620:0:862:101:0:0:2:0 clematis* 2620:0:862:101:0:0:2:1 zedler 2620:0:862:101:0:0:2:2 nightshade 2620:0:862:101:0:0:2:3 willow* 2620:0:862:101:0:0:2:4 hawthorn* 2620:0:862:101:0:0:2:5 wolfsbane* 2620:0:862:101:0:0:2:6 ortelius* 2620:0:862:101:0:0:2:7 yarrow* 2620:0:862:101:0:0:2:8 daphne 2620:0:862:101:0:0:2:9
damiana 2620:0:862:101:0:0:3:0 2620:0:862:101:0:0:3:1 2620:0:862:101:0:0:3:2 2620:0:862:101:0:0:3:3 turnera 2620:0:862:101:0:0:3:4 2620:0:862:101:0:0:3:5 2620:0:862:101:0:0:3:6 2620:0:862:101:0:0:3:7
thyme 2620:0:862:301:0:0:2:0 ptolemy 2620:0:862:301:0:0:2:1 hemlock 2620:0:862:301:0:0:2:2 [outdated dns entry?] rosemary 2620:0:862:301:0:0:2:3 hyacinth 2620:0:862:301:0:0:2:4 cassia 2620:0:862:301:0:0:2:5 adenia 2620:0:862:301:0:0:2:6 scs-oe10 2620:0:862:301:0:0:2:7 (Cisco) scs-oe16 2620:0:862:301:0:0:2:8
2620:0:862:101::1:0, 2620:0:862:101::1:1, 2620:0:862:101::1:2, 2620:0:862:101::1:3, 2620:0:862:101::1:4 point to www.toolserver.org, ha-dns-auth.toolserver.org, ha-mail.toolserver.org, ha-www.toolserver.org, ha-lb.toolserver.org which seem to mean they are handled by the damiana-turnera pair.
You will probably only view toolserver edits from the server marked with * (plus nightshade when it gets setup again) until the cluster grows. I have tested for those that the listed ips are indeed those viewed as source by the wikis.
wikitech-l@lists.wikimedia.org