Bug #7147
closed
pfsense-utils.inc - is_ipaddr_configured() does not work properly with some IPv6 formats
100%
Description
This one is working:
require_once('pfsense-utils.inc');
$ip = "2001:470:dead:beef:1:2::3";
var_dump(where_is_ipaddr_configured($ip));
array(1) {
[0] =>
array(2) {
'if' =>
string(3) "lan"
'ip_or_subnet' =>
string(27) "2001:470:dead:beef:1:2::3"
}
}
This one is not working.
require_once('pfsense-utils.inc');
$ip = "2001:470:dead:beef:1:2:0:3";
var_dump(where_is_ipaddr_configured($ip));
array(0) {
}
Updated by Phillip Davis almost 8 years ago
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!
Updated by Kill Bill almost 8 years ago
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.
Updated by Phillip Davis almost 8 years ago
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.
Updated by Phillip Davis almost 8 years ago
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.
Updated by Kill Bill almost 8 years ago
I'd rather avoid input validation here. Would just upset users for no good reason.
Updated by Phillip Davis almost 8 years ago
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.
Updated by Luiz Souza over 7 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
I'll close this ticket as the original issue was fixed by Phillip's commit.
The whole IPv6 input, store and output needs some extra thought, but we should handle that with a new issue (better describing at we are aiming to).
Thanks!