pfSense

Net_IPv6 validation allows compressed addresses that are not strictly in the "correct" compressed form.
e.g.
2001:2::1:0:0:0:1
should really be
2001:2:0:1::1

Put the top one in as the IPv6 address on an interface. Then enable DHCPv6 server with a range like:
2001:2::1:0:0:0:2 to 2001:2::1:0:0:0:ffff

You get dhcpdv6.conf subnet6 section like:
@
subnet6 2001:2:0:1::/64 {
range6 2001:2::1:0:0:0:2 2001:2::1:0:0:0:ffff;
do-forward-updates false;
option dhcp6.name-servers 2001:2::1:0:0:0:1;

}
@
The subnet prefix has been converted to the expected form, but the name-servers and range are specified as the user entered them. dhcpdv6 does not seem to complain, but in general it is not a great idea to feed addresses like this to other utilities - sometimes they may not like them!

Yeah, they definitely should be compressed before comparing. I hit this case since I've copied the local LAN IP from ifconfig output for some package code testing, and it failed the validation here.

PR https://github.com/pfsense/pfsense/pull/3414 should fix the particular bug reported here and make a start on fixing this kind of thing throughout the system.

There are a few approaches to a full fix throughout the system:
a) Catch this at input validation, always store a "correct" (as per the 2 RFCs) compressed form in the config. Then rely on that form being correct for use in the back-end.

b) Allow to also store a full-form address (i.e. do not automatically compress what the user entered - some users might like to enter, keep and see the full form for whatever reason). Use Net_IPv6::compress whenever needed to convert to a compressed form for comparison etc. (Net_IPv6::compress will work fine on full-form addresses)

c) Allow whatever Net_IPv6 allows in its validation (which includes these "free form compression" examples like 2001:2::1:0:0:0:1 and 2001:470:dead:beef:1:2::3). Make sure all back-end routines use a wrapper around any IPv6 address as it is used out of the config, that ensures conversion of a possibly-dodgy compression to the proper compression before making use of it for anything remotely important.

I'd rather avoid input validation here. Would just upset users for no good reason.

Yes, option (c) is the most flexible - let users put in whatever format they like (within reason) and deal with it in the back end as needed.