[arin-tech-discuss] zero-padded IP addresses in "startAddress" and "endAddress" values

[Andy Newton]

On Mar 30, 2012, at 5:20 AM, Jimmy Hess wrote:

> I would say that ad-hoc textual representation is dangerous when
> presented in an API for remote use,  because it visually _resembles_
> an IP so closely that it may confuse a human into thinking it is a
> valid IP address,   but  the leading zeros make it non-compliant with
> the standard representation of an IP address;   the result is
> ill-defined, and the octal interpretation is very common.

Jimmy,

The RFC literature quite liberally refers to the notation as "dotted-decimal" and therefore zero-padding is a good faith interpretation of the standard form. That being said...

> For example,
>   "012.020.030.040"   actually  indicates the IP address "10.16.24.32"
> 
> [root at orb1 ~ ]# ping -c 5 012.020.030.040
> PING 012.020.030.040 (10.16.24.32) 56(84) bytes of data.
>                                        ^^^^^^^^^^^
> 
> 
> ^C
> cat <<END > blah.c
>> #include <stdio.h>
>> #include <arpa/inet.h>
>> 
>> int main()
>> {
>>   char* input = "012.020.030.040";    struct in_addr address;
>> 
>>   if ( inet_aton(input, &address) != -1) {
>>      printf("%s == %s == %d == %X\n", input, inet_ntoa(address), htonl(address.s_addr), >htonl(address.s_addr));
>>   }
>> }
> END
> $ ./blah
> 012.020.030.040 == 10.16.24.32 == 168826912 == A101820
> $

I can see how this would trip up C programs and any languages using the inet_aton system call directly. Thanks for the example code.

As I replied to Seth, we can add elements that do not have the zero padding if that is what you desire.

Andy Newton