95

I have a security system and the network setting only allows a three-digit IP address. I can't set it to 192.168.2.100, instead I have to use 192.168.002.100.

Are these two IP addresses different? Do I need to set my router's LAN to be all 192.168.xxx.xxx in order for this to work correctly? I can't find any solid information about this.

6
  • 17
    Accoerding to the answers below, 192.168.020.100 should not be the same as 192.168.20.100, but it may be the same if your system allows IPs only to be entered this way (I have seen this with copiers when the IP is entered digit by digit with up-down-arrows). - If your system has that quirk even when "normal" keyboard input is possible (i.e., you can technicall input 192.168.2.100, but it complains), then I suggest you have a word with the vendor (How trustworthy is the security system if its input validation is so crappy?) Dec 28, 2014 at 19:24
  • 4
    That really is quite a bizarre validation. I'd switch security systems, as @Hagen alludes to. Dec 29, 2014 at 13:37
  • 2
    This can be software specific, too. They are valid with or without the leading 0s, but I've run into some applications not supporting an IP address that didn't have 3 digits in each octet.
    – ps2goat
    Dec 29, 2014 at 17:51
  • 2
    All IP(v4) addresses are really just 32 bits represented in a nice way. If 192.168.002.100 is how your tool represents 0xc0a80264/3232236132 /192.168.2.100, then it's the same thing.
    – Tim S.
    Jan 1, 2015 at 4:40
  • 1
    Can you please accept another answer? The one you accepted is really wrong (or at least incomplete) and has 11 downvotes.
    – Arjan
    Jul 15, 2017 at 16:13

10 Answers 10

104

It depends on the tool.

For most purposes the two will be the same, but not always.

For example, if you use a number starting with a zero, then ping will assume the number is octal.

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users>ping 011.012.013.014

Pinging 9.10.11.12 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 9.10.11.12:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
4
  • 38
    Not so much ping, but the underlying routine it uses inet_addr()
    – cde
    Dec 28, 2014 at 17:31
  • 2
    It's also happening on OSX. Dec 29, 2014 at 12:03
  • 21
    It's not because it has three digits, it's because the number has a leading zero. You can test this by trying to ping 09.09.09.09, which doesn't work because 9 isn't valid in octal. Dec 30, 2014 at 7:34
  • 1
    Ping also accepts four-digit numbers starting with zero, but the maximum value is 0377, which is 255.
    – phoog
    Jun 2, 2020 at 22:05
66

Assuming all software you are using is using dot-decimal and subnetting correctly, yes they are the same.

192.168.0.1 for example is only the friendly dot-decimal notation of the dot-binary value 11000000.10101000.00000000.00000001.

Whether you type it as 192.168.0.1 or 192.168.000.001 they are both equal to 11000000.10101000.00000000.00000001

13
  • 64
    The dots are also for convenience; the real IP is 11000000101010000000000000000001
    – cpast
    Dec 28, 2014 at 4:15
  • 14
    @cpast or as a hexadecimal number: C0A80001
    – jfs
    Dec 28, 2014 at 8:34
  • 13
    or as octal number (starting with 0, with or without dots) e.g. ping 0300.0250.2.0144 for 192.168.2.100
    – Sergey
    Dec 28, 2014 at 17:50
  • 15
    or as a decimal number 3232235521
    – oldmud0
    Dec 29, 2014 at 2:52
  • 14
    As @GreenstoneWalker 's answer pointed out, many programs will not perceive of them as the same; a number with a leading zero (that does not contain the digits 8 or 9) will be understood as an octal-notation number; therefore 010.000.001.063 would be interpreted as "8.0.1.51" (octal 010 = decimal 8; octal 063 = decimal 51) instead of "10.0.1.63"!
    – Doktor J
    Dec 29, 2014 at 21:54
37

It depends on the tools or functions any given program uses to parse the address given. Both Microsoft and Linux as well as other OSes use a POSIX compatible inet_addr() routine for parsing addresses.

Many TCP/IP programs such as Ping and FTP use the inet_addr() sockets function to translate IP address strings into 4-byte addresses. This function accepts an IP address in standard decimal, octal, and hexadecimal notation.
Microsoft KB115388 Ping and FTP Resolve IP Address with Leading Zero as Octal

 

The inet_addr() function converts the Internet host address cp from IPv4 numbers-and-dots notation into binary data in network byte order.

In all of the above forms, components of the dotted address can be specified in decimal, octal (with a leading 0), or hexadecimal, with a leading 0X). Addresses in any of these forms are collectively termed IPv4 numbers-and-dots notation. The form that uses exactly four decimal numbers is referred to as IPv4 dotted-decimal notation (or sometimes: IPv4 dotted-quad notation).
inet_addr(3): Internet address change routines - Linux man page

As such, your specific system might require three-digit decimal notation for each octet, but this is not universal, and care should be taken to ensure the proper IP address is entered.

Of course, only valid numbers for each type will work. Out of range Octal, Hex or Decimal numbers will also fail or cause issues. Octal 088, Hex 0xGG, or Decimal 280 are all invalid examples.

4
  • 3
    +1 for underlying function. To add, this function will cause IP parsing to fail if a valid byte (eg .88) is zero-padded, since 8 is not a valid number in octal.
    – March Ho
    Dec 29, 2014 at 13:34
  • In Windows XP (and before that) the function WILL accept invalid octal numbers and still attempts to convert them. This can lead to very non-obvious behavior. As of Vista invalid numbers are treated as domain names and Windows will attempt to do a DNS lookup for these. Which is pretty odd behavior too, but that will at least not cause any problems.
    – Tonny
    Dec 29, 2014 at 16:04
  • @tonny that's because POSIX inet_addr() returns -1 for invalid values, which loops around to 255. The newer routine, as mentioned in the Linux man page, has better error handling.
    – cde
    Dec 29, 2014 at 16:48
  • @cde I never bothered to delve that deep into the mechanics of inet_addr(). I'll take your word for it :-)
    – Tonny
    Dec 29, 2014 at 19:30
14

As Lightness Races in Orbit and others have pointed out,

The INET(3) man page describes inet_addr and inet_aton, the standard functions used for converting the "IPv4 numbers-and-dots notation into binary form". It says

...components of the dotted address can be specified in decimal, octal (with a leading 0), or hexadecimal, with a leading 0X).

So technically, NO, an IP address with leading zeros is not (always) the same as one without leading zeros. In your case however, 192.168.2.100 and 192.168.002.100 are identical, because 002 == 2.

Any user interface which requires each component to be exactly three characters in length, with incorrectly-required leading zeros is broken.

1
  • 2
    The idea that "leading zeros" are required (on some equipment) doesn't seem to be in dispute; What's the basis for calling that "incorrect-required"/"broken"? Just since it violates INET(3)/inet_addr/inet_aton? Implementations requiring such zeros is likely using other code which may communicate fine, hence not being "broken". (I've seen printers do this.) Is there a basis to say that the INET(3) man page is more "right" / a more authoritative resource than other official documents, like RFCs and others cited by this draft document?
    – TOOGAM
    Jul 15, 2017 at 20:46
6

Some implementations consider octets with leading zeros to be decimal other implementations consider them to be octal. As long as the octet is in the range from 0 to 7, this does not make a difference. So for example would 192.168.002.100 be interpreted as 192.168.2.100 in both implementations.

But if you were to type in an address as 192.168.010.100 it could be interpreted as either 192.168.10.100 or 192.168.8.100 depending on the implementation. It is also not unlikely that implementations do exists, which would consider leading zeros to be a syntax error. Additionally, there are scenarios in which software may insist that you have to use the canonical representation for one reason or another. For all of those reasons, I recommend on avoiding leading zeros when you write an IP address.

If you write software that need to parse an IP address, I would recommend accepting leading zeros, but output a warning to an appropriate location when it happens.

Slightly related there are implementations which allow you to have fewer than four components in the dotted notation. When there are fewer than four components the last component has more than 8 bits and the earlier components have exactly 8 bits. For example 192.168.612 would actually be a valid way to write 192.168.2.100. But again using that notation is not recommended.

0

Just a little tip: In some cases it is important to use zero prefixes in the IP addresses. An example, is Apache .htaccess deny rules.

If you use something like

deny from 11.22.33.22

Apache is so stupid that will also block access from the following IPs:

111.22.33.22

11.22.33.221

211.22.33.221

and in general, any IP address which includes 11.22.33.22

So, just to be sure that you will not block any IPs that you didn't mean to block, you should use:

deny from 011.022.033.022

to be sure that Apache will block access only from the 11.22.33.22 IP address.

2
  • 5
    Interesting. Can you provide a reference for this? Jan 18, 2016 at 11:44
  • The reference is personal experience and many trials and errors, after finding many visitors blocked as a result of not using leading zeros. Another way to avoid wrong bans is to use the IP in CIDR format. For example, 11.22.33.22/32 instead of just 11.22.33.22
    – Nick Gar
    Mar 10, 2016 at 14:57
0

be careful with this. it SHOULD be the same but it is NOT!
i couldn't find an explanation for this but i can definetly tell that on windows and linux ip addresses with and without leading zeroes are NOT the same! maybe this has to do with converting from other formats like hex or binary.

from my experience with windows and linux it is not tool dependend but os dependend it seems because im running in some problem using ips like 10.08.03.100:

  • note: "10.08.0.1" and 10.09.0.1 could not be found
  • note: "10.010.0.1" is resolved to 10.8.0.1

linux/debian7/8: same results with tool "ping" and "snmpget"

user@test:~$ ping 10.7.0.1
PING 10.7.0.1 (10.7.0.1) 56(84) bytes of data.
^C
--- 10.7.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.07.0.1
PING 10.07.0.1 (10.7.0.1) 56(84) bytes of data.
^C
--- 10.07.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
^C
--- 10.8.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.08.0.1
**ping: unknown host 10.08.0.1**
user@test:~$ ping 10.9.0.1
PING 10.9.0.1 (10.9.0.1) 56(84) bytes of data.
^C
--- 10.9.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.09.0.1
ping: unknown host 10.09.0.1
user@test:~$ ping 10.10.0.1
PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data.
^C
--- 10.10.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@test:~$ ping 10.010.0.1
PING 10.010.0.1 (10.8.0.1) 56(84) bytes of data.
^C
--- 10.010.0.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1001ms

windows7/8/10: same results with tool "ping" and "telnet"

(sorry, i dont have an english windows at hand, error tells that host could not be found)

C:\Users\user>ping 10.7.0.1

Ping wird ausgeführt für 10.7.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.07.0.1

Ping wird ausgeführt für 10.7.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.8.0.1

Ping wird ausgeführt für 10.8.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.08.0.1
Ping-Anforderung konnte Host "10.08.0.1" nicht finden. Überprüfen Sie den Namen,

C:\Users\user>ping 10.9.0.1

Ping wird ausgeführt für 10.9.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.09.0.1
Ping-Anforderung konnte Host "10.09.0.1" nicht finden. Überprüfen Sie den Namen,

C:\Users\user>ping 10.10.0.1

Ping wird ausgeführt für 10.10.0.1 mit 32 Bytes Daten:
STRG-C
^C
C:\Users\user>ping 10.010.0.1

Ping wird ausgeführt für 10.8.0.1 mit 32 Bytes Daten:
STRG-C
^C
3
  • A leading zero often denotes octal. Indeed, octal 010 is decimal 8, and 08 and 09 are invalid octal numbers. So yes, the (currently) accepted answer by AthomSfere is wrong (or at least incomplete). See its comments, and some of the other answers.
    – Arjan
    Jul 15, 2017 at 16:10
  • Ugh, that handling of 10.010.0.1 is just absolutely awful. In Microsoft Windows, ping 10.070.0.1 is treated as 10.56.0.1 and 10.080.0.1 gives an instant error, "Ping request could not find host 10.080.0.1. Please check the name and try again."
    – TOOGAM
    Jul 15, 2017 at 17:29
  • 1
    Yes, @TOOGAM, octal 070 is decimal 56. And octal 080 is not a valid number.
    – Arjan
    Jul 15, 2017 at 19:07
-4

The two IP addresses are different.

However:

  • People would generally consider them the same.
  • Some software would consider them the same.
  • Some software, on some platforms, will consider them different.

If that sounds confusing, it's because there is no standard governing the way IP addresses are supposed to be written, so different programmers at different points in history, and on different platforms, all had different ideas on what should be done.

IP addresses are actually binary, and people tend to use a dotted decimal notation to represent IP addresses. Software can accept various numerical bases (ie decimal, octal, hex) and interpret things various ways based on how you write it. How you write it can tell the software what base you are writing in.

I advise you: do not use leading zeros if you mean to use dotted decimal notation. Some software will consider that a flag to mean that you are entering an octal number. If you mean to enter in a decimal number, you will not get the results that you expect.

I asked a similar question and got some good responses, so if you want to go read up on RFC's, there's good info to be had there.

0
-6

It should work either way. You can even ping with three-digit numbers and the computer will understand the IP address.

Edit: windows will read it as octal, this only work for Linux.

13
  • This is true. The dotted decimal format, as it is known, is really only for humans. Devices on the network do not use this representation of an IP address. Dec 28, 2014 at 2:52
  • 1
    @Brock Vond: Yes, except I think you transposed the 186 and 168 accidentally. Dec 28, 2014 at 2:57
  • 6
    Using ping with 3-digit numbers may not work. It may treat them as octal. Dec 28, 2014 at 4:09
  • 1
    @LightnessRacesinOrbit Actually, the given example will work even if you zero-pad them, at least in Windows and Debian (I don't have a Mac). The bug/feature only occurs if the number is zero padded, and the zero padded number is greater than 7 (as octal and decimal would be identical). If you attempt to enter a valid decimal address zero-padded (eg 012.034.056.078), it will still attempt to parse this as octal, resulting in failure of the ping function.
    – March Ho
    Dec 29, 2014 at 13:29
  • 1
    @MarchHo: Yes, that's what we are all saying. Dec 29, 2014 at 13:35
-13

The leading zero is meaningless. The octets are (base-10) 0-255 numbers, not strings.

Since I'm not exactly sure what you're asking (or that you know what question to ask :)): That said, the IP # must be in the same subnet as your network. If you pick 11.12.13.14 within a subnetmask of 192.168.0.0, that device will not be able to talk to or use that subnet.

3
  • lol - no i def understand the subnet, and the basic concepts of networking... just never encountered a product that required 3 digits there. I was just using the 11.12.13.14 as variables... but thanks :)
    – Brock Vond
    Dec 28, 2014 at 3:05
  • 11
    -1: No, inet_addr and the hundreds of thousands of tools that rely on it for address parsing take a leading 0 to mean the byte is given in base-8 notation. That's hardly "meaningless". Dec 28, 2014 at 22:28
  • 1
    Try this ping 010.010.010.010 and notice you're pinging 8.8.8.8 So those leading zeros can be important.
    – Criggie
    Jun 3, 2020 at 22:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .