On Tue, Mar 17, 2015 at 06:48:14PM +0100, Daniel Quinn <dquinn@ripe.net> wrote a message of 14 lines which said:
Unfortunately, the issue of rejecting should-be-valid prefixes was not as simple a problem and that's going to take a little longer to fix. We have a few people tasked now with fixing this. It's a known problem with how we handle comparing IPs to prefixes in our database and we hope to have that working in production tomorrow as well -- though it may take a smidge longer than that.
Apparently, it is not yet fixed? For: {'definitions': [{'target': '2001:4b98:dc2:45:216:3eff:fe4b:8c5b', 'af': 6, 'packets': 3, 'type': 'ping', 'is_oneoff': True, 'description': 'Ping 2001:4b98:dc2:45:216:3eff:fe4b:8c5b from prefix 2000::/3'}], 'probes': [{'requested': 10, 'type': 'prefix', 'value': '2000::/3'}]} I get: Status 400, reason "{"error":{"message":"__all__: Your selected prefix is not covered by our network.","code":104}}" But 2000::/3 is the entire IPv6 space currently allocated, all the Atlas probes are certainly in it.