I apologise off the bat if this question is too basic to belong in this group. Perhaps it can be moved elsewhere if that's the case, or I can be directed to another SE site.

With IPv4 I have long been aware that is probably assigned to the same owner as, and the ownership of contiguous ranges is easy to determine in the WHOIS.

How can I determine the same information from IPv6 addresses?

I note the following based on observation of these two groups of IP addresses that I'm convinced are related (within each group) based on similar traffic patterns:

2002:b9ea:d9d2::b9ea:d9d2 2002:b9ea:d998::b9ea:d998 2002:b9ea:d9c9::b9ea:d9c9 2002:b9ea:d9cd::b9ea:d9cd 2002:b9ea:d982::b9ea:d982

2002:c1a9:fe5c::c1a9:fe5c 2002:c1a9:fe50::c1a9:fe50 2002:c1a9:fe5e::c1a9:fe5e

The second and fourth groupings are all the same (vertically, across the whole group), and horizontally (i.e., within each IP address) the third and fifth groupings are the same as each other.

What does this tell me about how these IP addresses are related, in the same way that I can deduce from the the IPv4 example in my second paragraph? More specifically, if I'm trying to use ip6tables to block malicious traffic and I'm not terribly concerned about collateral damage from blocking innocent IP addresses, how can I do the equivalent of blocking based on knowing that I want to block all traffic connected to 2002:b9ea:d9d2::b9ea:d9d2, for example?

As much as I'd love to take the time to understand IPv6 thoroughly, I don't have the time or the absolute need, so I'm not asking anyone to explain the theory (that I can read elsewhere), the why's and the how's but just enough information at this point to manage traffic to my machine.



I'm struggling to understand why a simple question has ignited heated debate, frustration (or anger), and assumptions (some of which are contrary to what I've plainly stated in the question). My question could have actually ended at my first bolded sentence above, and been complete as far as I'm concerned. Anything I add at this point will just be redundant, and participating further in the two chats that have been created is pointless.

Zac67's answer was the most useful/practical (thanks, Zac), but it doesn't actually answer the question. Ron's answer (which has somehow risen above Zac's despite [at the time of writing] having the same number of up-votes) completely misses the point ... as technically correct as all of his information may be. Sorry Ron.

So I can't accept either answer as neither "solved [my] problem or was the most helpful in finding [a] solution". I'll leave it as is, although I suppose the "hold" means that nobody will ever be able to answer it. That's not my call though.

Thanks guys. (That's serious, not sarcastic. The process did broaden my understanding slightly.)

closed as too broad by user36472, Ron Maupin Mar 3 at 17:10

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


2002::/16 is used for 6to4 translation (deprecated). The following octets are the IPv4 address, repeated.

b9ea:d9d2 = and so on.

I guess if you don't need to use 6to4 translation you can safely filter 2002::/16.

  • Hmm, I see your point, but that would be an even bigger hammer than blocking an IPv4 class C block. – CraigH Mar 2 at 20:35
  • @CraigH, network classes were deprecated in 1993, maybe before you were born. Modern networking does not use network classes, and referring to them is meaningless, today. Your example network of would have been a Class A subnet, anyway, not a Class C network. The address determines the class, not the mask length. See the very last section of this answer for what the network classes were. – Ron Maupin Mar 2 at 20:40
  • @craigh Why so? Leaving 6to4 addressing open without any use for it is a potential attack vector. – Zac67 Mar 2 at 21:06
  • @Zac67 Good point, but I don't know the answer to that. Perhaps you're right, considering it seems that most (if not all) of the malicious IPv6 traffic I'm seeing is in the 6to4 addressing space (2002::/16). – CraigH Mar 2 at 21:24

Just like with IPv4, you need the mask length to determine which part of the address is the network, and which part of the address is the host. With IPv4, the mask length can be as long as /32, but with IPv6, it can be as long as /128.

You cannot simply look at an address and determine what the network portion of the address is, and assuming that all IPv4 addresses are /24 is a mistake. That is explained in this two-part answer that demonstrates that the IPv4 octets are only to make it easier for humans to read an IPv4 address, and the octets have nothing to do with addressing or subnetting of an IPv4 address.

Just as the octets of an IPv4 address cannot tell you about the network, the IPv6 words cannot tell you about the IPv6 network. You need to know the mask length. The strong recommendation is that IPv6 networks should be /64 networks (four colon separated words for the network), and each site should get a /48 prefix (three colon separated words), giving the site 65,536 /64 networks, but that is simply not always the case.

You will always need two pieces of information in order to determine the network and host portions of an address, and you seem to be trying to determine the second piece of information from the first piece of information, but it doesn't work that way. For example if you see the IPv4 address of, you are assuming a network of but the address could be one end of a point-to-point link using the network, or it could be part of the network. IPv6 addresses could be point-to-point links using /127 or /126, or even /128 loopback addresses. Without the mask or mask length, you are simply guessing at the network.

Simply assuming a mask length, especially when it comes to security, is asking for trouble.

Not the answer you're looking for? Browse other questions tagged or ask your own question.