User talk:Jonathan de Boyne Pollard/Guide to blocking IP version 6 addresses

Factual errors

1. It's called a 48-bit, not a 47-bit, prefix. Count the actual bit quantity and not the bit ID #s used in documentation.
2. IP addresses don't have accounts, that's going to confused admins. They identify users without accounts.
3. It's still too technical for most admins with more confusing details; "unicast" is not something we should even mention.
4. I do not agree on rangeblocking being the norm as a rule, because some /64s may represent a whole office building or campus and that's not necessarily what we want. The general rule is check your WHOIS!

Please correct these issues; otherwise it's pretty fine.--Jasper Deng (talk) 01:04, 5 June 2012 (UTC)

It's you that is in error. Aside from the fact that you've invented IP version 5, you clearly haven't read BCP 157 (The world isn't /48 as standard any more, kid.) and you keep combining ::0/128 and ::1/128 wrongly (It was correct as it initially stood.). Jonathan de Boyne Pollard (talk) 01:15, 5 June 2012 (UTC)

• No, where did I change it to IPv5 (if I did it was a typo). /48 may be used by organizations or end-users, and is often dealed out by tunnelbrokers to anyone.--Jasper Deng (talk) 01:16, 5 June 2012 (UTC)
  • and your RFCs fail to mention the combined ::/127 representation.--Jasper Deng (talk) 01:21, 5 June 2012 (UTC)
    • My RFCs? Don't be daft. That's a very silly attitude to take. I'm very surprised, also, that you cannot combine ::1/128 and ::0/128 and work out that that's a /127. Jonathan de Boyne Pollard (talk) 01:28, 5 June 2012 (UTC)
      • "My RFCs"->"RFCs cited" - it's confusing to combine these two because they are very different in purposes. For example you'll see ::1/128 editing from time to time, but not 0::/128. You must explain why these are reserved; it's just like you cannot mention 0.0.0.0 and 127.0.0.1 as the same.--Jasper Deng (talk) 01:30, 5 June 2012 (UTC)
        • They are indeed very different in purpose, but all that we're saying here is not to block them. That's what the section is about, after all. For the details the footnote already explains what they are, with hyperlinks to Wikipedia articles for even more information. It's ironic that you started by removing that explanation entirely, and yet now want to put an explanation of your own in. Jonathan de Boyne Pollard (talk) 01:40, 5 June 2012 (UTC)
          • No, it isn't; an explanation was needed, I never said that. I disagree on ::1 because ::1 may have malfunctioning stuff and also 127.0.0.1 is sorta used as an IP block sandbox on enwiki.--Jasper Deng (talk) 01:42, 5 June 2012 (UTC)
            • Of course it is about that. It says "Don't block" in the section heading and in the précis. I don't know what you're disagreeing with, but it's not the statement, which was in the very first revision, not to block the entire 0::/127, which of course includes ::1. And yes, you most definitely edited out the explanation that you now want to have, in your very first edit, the one where you introduced IP version 5, and where you even edited out the quite explicit "Don't block" instruction for some incomprehensible reason. Jonathan de Boyne Pollard (talk) 01:54, 5 June 2012 (UTC)
              • I will not argue with you any more with you; "don't block" is not accurate at all and I should just point out that they are special, especially since no admin will encounter them at all. You still haven't satisfied why the distinction doesn't have to be made. In fact, even better: only addresses in 2000::/3 can be blocked - we don't even have to worry about ::1 etc.--Jasper Deng (talk) 01:58, 5 June 2012 (UTC)
                • You haven't first read what you're editing, have you? There's far better advice than that in the 1 line précis right at the top of that very section. And of course "Don't block" is right. It's what the section is all about: What not to block. That's no way in which it can be inaccurate for a section about what not to block to use the words "Don't block". My goodness you are propounding some foolishness, and are dreadfully confused. You appear to be arguing at random. The section clearly said all along not to block these ranges, the big clue being the words "Don't block" all over the place, and here you are arguing that it should say not to block them, as if somehow it weren't saying that. Read before writing. Jonathan de Boyne Pollard (talk) 02:22, 5 June 2012 (UTC)
                  • I've read everything. You should say "don't usually block", it isn't the end of the world if you do. There are cases where you will block in those ranges like localhost and local addresses because those may appear from malfunctioning WP servers.--Jasper Deng (talk) 02:37, 5 June 2012 (UTC)
                    • Those cases haven't happened once for 127.0.0.1/32, which has an entirely clean block log across all wikis where it has ever edited according to the toolserver, in over ten years. What makes you think that they'll happen for ::1/128? Jonathan de Boyne Pollard (talk) 03:05, 5 June 2012 (UTC)
                      • huh? what's this? Even if they aren't malfunctions it serves as our sandbox. This is why it's not accurate to say "don't ever block."--Jasper Deng (talk) 03:07, 5 June 2012 (UTC)
                        • It's something that the toolserver (as I said) doesn't report when queried. And no, five people in ten years isn't sandboxing, by any stretch of the imagination; especially when almost the same number of blocks (four in ten years) were mistakes not tests. Most people block themselves when they do test blocks, if they do test blocks at all. That is in fact where "our" sandbox is in reality. Jonathan de Boyne Pollard (talk) 18:10, 10 June 2012 (UTC)
                          • At least mention that it's an option. It has little effect, so I don't see what's the point in it.--Jasper Deng (talk) 18:57, 10 June 2012 (UTC)

/64 blocking

I will mention that I formerly endorsed blocking /64s by default by do not any more. You have to make sure you aren't blocking a whole office building when only one worker is at fault.--Jasper Deng (talk) 01:29, 5 June 2012 (UTC)

Why it should not be done by default

A primary reason for IPv6 on wikis is to avoid collateral damage from several users using one NAT. A single /64 could incite that same amount of collateral damage, which is why the block should occur only for extreme cases or when it is clear the user will and does switch IPs.--Jasper Deng (talk) 18:50, 10 June 2012 (UTC)

Private addresses

While fec0::/7 is wrong, fc00::/7 is not - [1].--Jasper Deng (talk) 01:34, 5 June 2012 (UTC)

Factual errors introduced by Jasper Deng, sad to say.

Personal attacks
The following discussion has been closed. Please do not modify it.
So here's a list of the clueless and innumerate factual errors introduced by Jasper Deng, as supposed "fix"es or corrections to factual errors, so far. We have: the invention of IP version five the introduction of information that is eight years out of date even though the six-year-old RFC cited directly explained that this is not so. Note the /0 prefix length, too. the binary 11110000 instead of 11111111 for the hexadecimal FF, again mis-named a "fix" reduction of the same to 7-bit number even though it's an /8 a failure to do simple subtraction and realize that 0x2A00 is less than 0x2C0F inability to do simple subtraction again inability to do simple subtraction again inability to do simple subtraction again despite the error being pointed out explicitly introduction of a spelling error while wasting database space with a new revision that otherwise does nothing except change space characters correcting a change to mood that Jasper Deng made in the first place And this aside from all of Jasper Deng's repeated nonsense, clearly not having read BCP 157 (or even the various RIR policies), about /64s. Jonathan de Boyne Pollard (talk) 19:49, 10 June 2012 (UTC)

Please cool down a bit. Vituzzu said the IPv6 example you gave was invalid. Isn't it possible you made some mistakes here? Trijnstel_talk 17:58, 14 June 2012 (UTC)

Could you please categorize this page in Category:Edit blocks and bans?

Thanks. Apokrif (talk) 02:38, 1 April 2022 (UTC)