 | This is an explanatory essay about the blocking policy. This page provides additional information about concepts in the page(s) it supplements. This page is not one of Wikipedia's policies or guidelines as it has not been thoroughly vetted by the community. |
Blocking of IP addresses on Wikipedia is a special case of IP address blocking. This page contains guidelines for administrators carrying out such blocks.
Guidelines
Sensitive IP addresses
Sensitive due to public relations implications
If you block an IP address in any of the following ranges, you are required to immediately notify the Wikimedia Foundation Communications Committee. These ranges are allocated to major governmental organizations and blocks of these organizations have political and public relations implications that must be managed by the Foundation's press relations team. Avoid long blocks of these addresses and be especially careful in formulating your block messages, which may appear in the press. Make doubly sure you're blocking the right address.
Note that the IPv6 list is not complete. Therefore, always be sure to look up an IPv6 address in WHOIS to make sure it isn't that of a sensitive organization, and if so add the range to this list.
| IPv4 | IPv6 | Description |
|---|---|---|
| 143.228.0.0/16, 143.231.0.0/16, 137.18.0.0/16, 12.185.56.0/29, 12.147.170.144/28, 74.119.128.0/22 | 2620:0:e20::/46 | The United States House of Representatives |
| 156.33.0.0/16 | 2620:0:8a0::/48, 2600:803:618::/48 | The United States Senate |
| 165.119.0.0/16, 198.137.240.0/23, 204.68.207.0/24 | 2620:10F:B000::/40 | The Executive Office of the President of the United States |
| 149.101.0.0/16 | 2607:f330::/32 | The United States Department of Justice |
| 65.165.132.0/24, 204.248.24.0/24, 216.81.80.0/20 | 2600:400::/32 | The United States Department of Homeland Security |
| 131.132.0.0/14, 131.136.0.0/14, 131.140.0.0/15 | The Canadian Department of National Defence | |
| 192.197.82.0/24 | The Canadian House of Commons | |
| 194.60.0.0/18 | The Parliament of the United Kingdom | |
| 138.162.0.0/16 | The United States Department of the Navy and the United States Marine Corps |
If the IP address belongs to anything that might be closely related to the above, or a major corporation, for example UnitedHealth Group or Berkshire Hathaway (both of which are in the top ten of the Fortune 100 and unlikely to have data centers for lease attributed directly to them), or others, it may be a good idea to notify the committee.
Sensitive for other reasons
Blocking an IP address listed in this section can cause undesired effects on Wikipedia, which vary depending on the IP address in question. Please issue soft blocks on any bot coming from this address. If you are unsure as to how to do this correctly, please do not issue the block, but contact another admin.
| IPv4 | IPv6 | Description |
|---|---|---|
| 91.198.174.0/24, 185.15.56.0/22, 198.35.26.0/23, 208.80.152.0/22 | 2620:0:860::/46, 2a02:ec80::/32 | The Wikimedia Foundation |
| 45.79.106.114 | 2600:3c01::f03c:93ff:fe24:db1b | Dashboard.wikiedu.org OAuth application, maintained by Wiki Education Foundation |
| 192.0.2.0/24 | RFC 5737 reserved test range |
Note: 192.0.2.0/24 is not actually a sensitive address. It is included in this list for testing and training purposes and may safely be blocked with no requirement to notify the WMF. Other private network addresses (127.0.0.1, 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) are sometimes used by Wikimedia infrastructure, sometimes intentionally. These should not generally be blocked without good reason or consultation as there may be unintended consequences.
Addresses of organizations with a responsive IRT
Some organizations have an Incident Response Team that has demonstrated willingness and ability to be responsive to reports of abuse at the source (the user). In those cases, it is preferable to contact their response team through the provided contact information rather than blocking all or part of their IP ranges – although it remains appropriate to place short blocks to interrupt ongoing vandalism or disruption.
| IP address or range | Description | Email capability |
|---|---|---|
| 193.113.57.160/27 | British Telecommunications plc (response team) | No |
| 129.127.0.0/16 | University of Adelaide (response team) | No |
| (TBD) | University of Cambridge (response team) | No |
| 71.0.0.0/14, 65.40.0.0/15, 76.0.0.0/13 | CenturyLink / Lumen (email abuse aup.lumen.com) |
Yes |
Organizations should be encouraged to be involved in managing disruption caused by their users to avoid the inconvenience to their other users. When placing a long block on an IP or IP range, a politely worded email to the organization's IT suggesting that they participate this way would be a good idea, and it is important to be liberal in unblocking ranges of organizations that collaborate.
Block lengths
Blocks should be based on the protection of Wikipedia rather than the punishment of offenders. Most IP addresses should not be blocked more than a few hours, since the malicious user will probably move on by the time the block expires. If there is persistent disruption or vandalism from an IP address, the block should be extended (with the 'anon-only' option selected) as long as is necessary to prevent further disruption.
However, IP addresses should almost never be indefinitely blocked. Many IP addresses are dynamically assigned and change frequently from one person to the next, and even static IP addresses are periodically reassigned or have different users. In cases of long-term vandalism from an IP address, consider blocks over a period of months or years instead. Long-term blocks should never be used for isolated incidents, regardless of the nature of their policy violation. IP addresses used by blatant vandals, sockpuppets and people issuing legal threats should never be blocked for long periods unless there is evidence that the IP address has been used by the same user for a long time.
Open proxies should generally be reported to the WikiProject on open proxies and blocked for the length of time they are likely to remain open on the same IP address, which in most cases is likely to be only a few months.[1] Many open proxies have been blocked indefinitely, but this is no longer considered good practice. A large proportion of indefinitely blocked proxies are no longer open proxies.
If you do indefinitely block an IP address, place {{blocked proxy}} (do not substitute) on its user or user talk page for tracking purposes.
Shared IP addresses
Before implementing a long-term block on an IP address with a long history of vandalism, please check if it is shared by performing a WHOIS and Reverse DNS lookup query on the IP address to determine if it belongs to a school or an ISP. If a Shared IP address' talk page is not already identified or tagged as such, use either the {{Shared IP}}, {{Shared IP edu}}, or any one of the templates at Category:Shared IP header templates to do so. For anonymous-only blocks of shared IP addresses, please consider using {{anonblock}} or {{schoolblock}} as your blocking reason as it causes less offence to innocent users.
Note that IPv6 addresses are almost never shared, even for large organizations, because network address translation is typically not used with IPv6.
Range blocks
Administrators can block ranges of IP addresses (commonly called rangeblocking). Use careful judgement and make them as brief as possible; they can affect up to 65,536 IPv4 addresses (for /16 blocks) or 649,037,107,316,853,453,566,312,041,152,512 (649 thousand billion billion billion, ~6.49×1032, 2109) IPv6 addresses (for /19 blocks) each, potentially affecting millions of users. These should be reserved as an absolute last resort, especially very large rangeblocks.
For more information, see mw:Help:Range blocks (mw:Help:Range blocks/IPv6 for IPv6). You need some knowledge of how networks and IP address numbering work, and of binary arithmetic. If you don't, many other administrators do — ask on the Administrators' noticeboard or on #wikipedia-en connect. This essay contains advice for dealing with disruption by users on IPv6 addresses.
If you propose to block a significant range, or for a significant time, consider asking a user with checkuser access to check for collateral damage – that is, for the presence of other users who may be unintentionally affected by the range block. Alternately, if you are unsure whether disruptive edits from a specific range are a specific user, you can post a request at sockpuppet investigations where another editor will attempt to match users with IP addresses.
You can calculate a rangeblock using this tool or {{IP range calculator}}.
Problems and solutions
Shared and dynamic IP addresses
Many users operate from shared IP addresses, often those belonging to proxies used by large networks or home users with their Internet service providers. Since it is impossible to distinguish between individual users operating from shared IP addresses, blocking one may affect a very large number of legitimate users (ranging up to millions). Users operating from dynamic IP addresses change IP addresses periodically. This can compound the autoblock problem, particularly when they are also shared, because a block targeted at a malicious user may shift to a legitimate user while the target shifts to an unblocked IP address.
Note that IPv6 addresses are almost never shared, even for large organizations, because network address translation is typically not used with IPv6. Although IPv6 addresses can be highly dynamic, possibly changing even more often than IPv4 addresses, a single user will generally use the same /64 range, and their IPv6 address is unlikely to be shared with other devices (although multiple people can use a single device, e.g. a shared computer). See Wikipedia:WikiProject on XFFs
Open proxies
Open proxies may be blocked on sight according to the policy on open proxies. The IP should be unblocked once the proxy has been closed. Since the IPs may eventually be reassigned or the proxies closed, blocks should not be indefinite, but in some particular cases can be very long term. Block lengths should typically range from several weeks for dynamic IPs and short term Tor nodes, up to several years for long term proxies hosted on static IP addresses.
Administrators who block open proxies should attempt to record in the block log or on the user talk page how to verify whether the IP address is still an open proxy at a future date. Administrators who deal with unblock requests from blocked open proxies should typically seek advice from either the blocking admin or the WikiProject on open proxies before unblocking.
Indefinite blocks
Some behaviour by users, for example egregious threats and harassment, is so extreme that an indefinite block of the user is warranted. There are also some Wikipedia policies, for example Wikipedia:No legal threats and Wikipedia:Sock puppetry where an indefinite block of the user is suggested. These indefinite periods apply to users and not their IP addresses. While the user may be considered indefinitely blocked and subsequently blocked on sight, the IP addresses they use should only be blocked for as long as they are likely to remain assigned to the same user.
Blocking account creation but permitting editing
In some cases administrators may wish to block account creation within an IP range, but permit editing. This can be accomplished by imposing a partial block and leaving the "Pages" and "Namespaces" fields blank.
Notes
- ^ See nl:Gebruiker:RonaldB/Open_proxy_fighting#Lifetime_of_OP.27s (in English) for more information on the lifetimes of open proxies