Update limits file to exclude IPv6 private networks from bogons

[laeti-tia]

Running pscheduler troubleshoot on an IPv6-enabled container in my local Docker Desktop setup results in a rejected Idle test because of limits.

  Idle test... Failed.

Failed to post task. Code: [403] Error: [Task forbidden by limits:
Hints:
  requester: fd18:aba0:3212::2
  server: fd18:aba0:3212::2
Identified as everybody, local-interfaces, bogons
Classified as default, friendlies, hostiles
Rewriter made changes:
  Bumped duration to 5-second minimum
Application: Hosts we don't want running any tests
  Group 1: Limit 'never' failed: Forced failure
  Group 1: Want all, 0/1 passed, 1/1 failed: FAIL
  Application FAILS
Failed; stop forced
Proposal does not meet limits

I think we should add fc00::/7 in the exclude clause of the bogons identifiers, and maybe 64:ff9b:1::/48 too?

[mfeit-internet2]

The unique local address block (fc00::/7) seems like the right thing to do, so I added it.

I'm on the fence about the the NAT64 block. If we allow that, IPv4 bogons could be translated into that space unless Team Cymru has figured that into its bogon service.

In your specific case, the requesting address was on a local interface, which makes classifies it friendly and was a bogon, which classifies it hostile. The applications section was arranged to reject implicit hostiles before allowing explicit friendlies, so I've re-ordered it the other way.

[mfeit-internet2]

Release Notes:

The default pScheduler limit configuration has been changed to be smarter about not rejecting requests from local interfaces that are bound to the IPv6 unique local address (ULA) block.

[timchown]

ULA addresses are actually global scope, because they are probabilistically unique.
They might be routed between sites, by agreed routing, but you'd not see ULAs in the Internet DFZ, which is what the bogon list is for.
But what do you mean by the NAT64 prefix? There is the PREF64 prefix 64:ff9b::/96, but the move now is towards hosts translating with built-in CLATs so they'd just use their subnet prefix picked up from RAs.
There's no reason perfSONAR should block any such addresses.