Ipv6Range fails to parse published IPv6 StackPath IP Blocks

[JamoCA]

I'm attempting to parse the IPv6 CFD/WAF & Monitoring IP Blocks from StackPath, I keep experiencing "{IPRANGE_STRING} is not a legal IPv6 address prefix". errors. If I enter the same string in the CIDR to IPv6 Conversion form, the first & last IPs appear to be correctly identified without any errors being thrown.

Am I doing something wrong or is this a bug?

2001:19f0:5800:8bfc:5400:ff:fe1c:5b87/64
2001:19f0:5800:8d34:5400:ff:fe1c:5b8c/64
2001:19f0:6000:9301:5400:ff:fe1c:85/64
2001:19f0:6000:95c5:5400:ff:fe1c:88/64
2001:19f0:7000:9aa1:5400:ff:fe1c:1090/64
2001:19f0:7000:9c35:5400:ff:fe1c:4562/64
2001:19f0:7401:834f:5400:ff:fe1c:c96/64
2001:19f0:7401:844e:5400:ff:fe1c:c99/64
2001:19f0:8000:8652:5400:ff:fe1c:45c2/64
2001:19f0:8000:8706:5400:ff:fe1c:45c4/64
2001:4801:7824:101:be76:4eff:fe10:24dc/64
2001:4801:7824:101:be76:4eff:fe10:55c6/64
2001:57a:300:1100::/6
2001:b60:1000:149:154:157:239:1/112
2001:b60:1000:151:236:18:167:1/112
2a00:1768:1003:151:236:14:231:1/112
2a00:1768:1003:151:236:14:238:1/112
2a00:1a28:1251:46:246:126:136:1/112
2a00:1a28:1251:46:246:93:179:1/112
2a00:1a48:7805:113:be76:4eff:fe08:25fa/64
2a00:1a48:7805:113:be76:4eff:fe09:1f07/64
2a00:1d70:ed15:151:236:23:142:1/112
2a00:1d70:ed15:151:236:23:78:1/112
2a01:348:99:151:236:21:35:1/112
2a01:348:99:151:236:21:87:1/112
2a03:f80:354:151:236:24:35:1/112
2a03:f80:354:151:236:24:50:1/112
2a03:f80:49:149:154:159:21:1/112
2a03:f80:49:151:236:15:26:1/112
2a03:f80:56:37:235:52:196:1/112
2a03:f80:56:37:235:52:70:1/112
2a03:f80:7:213:183:56:187:1/112
2a03:f80:7:213:183:56:71:1/112
2a03:f80:852:151:236:20:95:1/112
2a03:f80:852:158:255:208:86:1/112
2a07:4580:b0d:82::793a/64
2a07:4580:b0d:f::6324/64

[jgonian]

Hi @JamoCA,

As the error message suggests these IPv6 ranges are not valid subnet prefixes. There is no bug in the library as far as I can tell, although I can see where your confusion is coming from.

The library is designed to be more strict to protect user from accidental mistakes. If we take 2a07:4580:b0d:f::6324/64 as an example, the website that you linked says the following:

Now let's use the library to create an IPv6Range using the first and the last IP from the website and print the total hosts:

Ipv6Range
  .from("2A07:4580:0B0D:000F:0000:0000:0000:6324")
  .to("2A07:4580:0B0D:000F:FFFF:FFFF:FFFF:FFFF")
  .size()

// total hosts: 18,446,744,073,709,526,236

However, the website says Total Hosts: 18,446,744,073,709,551,616 which is bigger by 25380 hosts. How did this happen?

To get to the same number of total hosts using the library API you need to parse the valid network prefix instead. In this case 2a07:4580:b0d:f::/64:

Ipv6Range
  .parseCidr("2a07:4580:b0d:f::/64")
  .size()

// total hosts: 18,446,744,073,709,551,616

If you are wondering how to find out the beginning of the prefix from a known IPv6 address and a prefix length, you can use the lowerBoundForPrefix() method on an instance of Ipv6. For example:

System.out.println(Ipv6.of("2a07:4580:b0d:f::6324").lowerBoundForPrefix(64));

// will give you: 2a07:4580:b0d:f::

You can also enter some more ranges in https://www.cidr.eu/en/calculator which has a more clear output with regards to subnet prefixes.

Overall, I think that both, the websites and the library, are user-friendly in their own way. The websites are trying to figure out what the valid network prefix is, so that they can display some information, while the library is validating the user input and helping users avoid mistakes. Imagine if you are creating an IP filter and you accidentaly block more hosts than you intended.

We can consider adding a more lenient version of IPv6Range.parse in a future version of the library but for now I think we are good and I'd like to close this ticket.