IP Address Formats?

[Bob_Zimmerman]

Is there documentation anywhere on what formats the management API accepts for IPv4 and IPv6 addresses? IPv4 is really poorly-specified, so all of these are technically valid representations of the same IPv4 address:

• 8.8.8.8
• 010.010.010.010
• 0x8.0x8.0x8.0x8
• 0x8.010.2056
• 134744072
• 0x8080808

I'm guessing the management API only accepts the first one, but it would be nice to get official confirmation of what should work. IPv6 is a lot more rigidly specified, but still explicitly allows some weird syntax like dotted decimal (but not other radixes, thank goodness) for the final two words. These are all valid IPv6 addresses:

• ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
• 2001:DB8:0:0:8:800:200C:417A
• FF01:0:0:0:0:0:0:101
• FF01::101
• 0:0:0:0:0:0:13.1.68.3
• ::13.1.68.3
• 0:0:0:0:0:FFFF:129.144.52.38
• ::FFFF:129.144.52.38

Is the API expected to accept all of these?

[Hugo_vd_Kooij]

You riase a very good  point. In my experience you can get away with a number of variants on the IPv6 address but the IPv4 only works in the normal dotted decimal variant.

The fields should be normalized by the API. As we all know what might happen if you don't normalize it.

[the_rock]

I agree. I was looking into bunch of documents for this and cant find anywhere that officially states formats that are supported or NOT supported. Maybe someone from R&D will comment, lets see.

Andy

[Bob_Zimmerman]

Got a chance to build a small script to try the addresses above:

#!/usr/bin/env bash
ipv4AddressList=(
8.8.8.8
010.010.010.010
0377.0377.0377.0377
0x8.0x8.0x8.0x8
0x8.010.2056
134744072
0x8080808
)

ipv6AddressList=(
ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
2001:DB8:0:0:8:800:200C:417A
FF01:0:0:0:0:0:0:101
FF01::101
0:0:0:0:0:0:13.1.68.3
::13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38
::FFFF:129.144.52.38
)

mgmt_cli -r true login >session.txt
for ipv4Address in "${ipv4AddressList[@]}";do
printf "%-50s" "IPv4 ${ipv4Address}"
returnedAddress=$(mgmt_cli -f json -s session.txt add host name "IP_Addr_Test" ipv4-address "$ipv4Address" | jq '."ipv4-address"' | tr -d '"')
mgmt_cli -f json -s session.txt discard >/dev/null
if [ "$returnedAddress" = "$ipv4Address" ];then
echo "Success"
else
echo "Fail"
fi
done

for ipv6Address in "${ipv6AddressList[@]}";do
printf "%-50s" "IPv6 ${ipv6Address}"
returnedAddress=$(mgmt_cli -f json -s session.txt add host name "IP_Addr_Test" ipv6-address "$ipv6Address" | jq '."ipv6-address"' | tr -d '"')
mgmt_cli -f json -s session.txt discard >/dev/null
normalizedAddress=$(ip route get "$ipv6Address" | head -n 1 | cut -d ' ' -f 1)
if [ "$returnedAddress" = "$normalizedAddress" ];then
echo "Success"
else
echo "Fail"
fi
done

mgmt_cli -s session.txt logout >/dev/null
rm session.txt

Note that Check Point management servers apparently perform some normalization of the IPv6 address. All letters become lowercase, and the longest run of zeroes is omitted. Thus, I had to come up with a way to normalize IPv6 addresses for the comparison. Here's the output:

[Expert@DallasSA]# ./addressTest.sh 
IPv4 8.8.8.8                                      Success
IPv4 010.010.010.010                              Success
IPv4 0377.0377.0377.0377                          Fail
IPv4 0x8.0x8.0x8.0x8                              Fail
IPv4 0x8.010.2056                                 Fail
IPv4 134744072                                    Fail
IPv4 0x8080808                                    Fail
IPv6 ABCD:EF01:2345:6789:ABCD:EF01:2345:6789      Success
IPv6 2001:DB8:0:0:8:800:200C:417A                 Success
IPv6 FF01:0:0:0:0:0:0:101                         Success
IPv6 FF01::101                                    Success
IPv6 0:0:0:0:0:0:13.1.68.3                        Fail
IPv6 ::13.1.68.3                                  Fail
IPv6 0:0:0:0:0:FFFF:129.144.52.38                 Success
IPv6 ::FFFF:129.144.52.38                         Success
[Expert@DallasSA]# 

The success for "010.010.010.010" is interesting, so I added a test for 0377.0377.0377.0377 (255.255.255.255, or 0xffffffff). That fails. The leading zeroes in 010 are retained, though. In most cases, a leading zero is interpreted as a base indicator. Leading 0b means binary, 0x means hexadecimal, but 0 by itself means octal.

After further testing, I confirmed while you can set an address byte with a leading zero via the API, and the leading zero is retained in the IPv4 address string, it is interpreted as base 10. While this is technically incorrect, and a sign of one or two minor bugs in the API (input validation and normalization, storage normalization, maybe output normalization), it is unlikely to cause an actual problem. Before I mentioned it here, how many people even knew bytes in IP addresses could be expressed in octal notation?

The bigger issue is that "0:0:0:0:0:0:13.1.68.3" and "::13.1.68.3" came from the IETF documentation specifying valid IPv6 addresses, and they are rejected. The weird notation with dotted decimal for the last two words is accepted in general (and retained), just not in those specific cases.