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.

Peter Mortensen
  • 12,090
  • 23
  • 70
  • 90
Brock Vond
  • 1,053
  • 1
  • 7
  • 9
  • 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?) – Hagen von Eitzen Dec 28 '14 at 19:24
  • 4
    That really is quite a bizarre validation. I'd switch security systems, as @Hagen alludes to. – Lightness Races in Orbit Dec 29 '14 at 13:37
  • 2
    This can be software specific, too. They are valid with or without the leading `0`s, but I've run into some applications not supporting an IP address that didn't have 3 digits in each octet. – ps2goat Dec 29 '14 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 01 '15 at 04: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 '17 at 16:13
  • For more fun with doing things in an absurd way, ping 67240450 and also ping 134744072 – TOOGAM Jul 15 '17 at 18:07

10 Answers10

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),
Heinzi
  • 3,697
  • 9
  • 35
  • 50
Greenstone Walker
  • 1,042
  • 2
  • 7
  • 8
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

Austin T French
  • 10,505
  • 27
  • 42
  • 64
    The dots are also for convenience; the real IP is 11000000101010000000000000000001 – cpast Dec 28 '14 at 04:15
  • 14
    @cpast or as a hexadecimal number: `C0A80001` – jfs Dec 28 '14 at 08: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 '14 at 17:50
  • 15
    or as a decimal number [`3232235521`](http://3232235521) – oldmud0 Dec 29 '14 at 02: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 '14 at 21:54
  • 3
    The hex, octal, and decimal conversions made me smile, but the real IP address is strictly binary. Even if your hardware device uses three-state logic and stores the address in ternary form for some reason, IP routing protocols mandate that [longest prefix matching](http://en.wikipedia.org/wiki/Longest_prefix_match) is performed on the binary-formatted address for network ID estimation. – kdbanman Dec 30 '14 at 21:30
  • 5
    This answer is just plain **WRONG**. While they *may* be equivalent on some systems, they are *not* equivalent when using APIs that interpret leading zeros as octal notation. To say, without caveat, that *yes* they are the same is **WRONG** and irresponsible. – Jonathon Reinhart Jun 30 '15 at 15:03
  • Luckily it wasn't with out caveat when I specifically stated "assuming all software you are using is using dot-decimal" which implicitly excludes octal... – Austin T French Jun 30 '15 at 18:20
  • 1
    @JonathonReinhart : Quite a strong stance, especially when so arguably wrong. The first part of this answer states, "Assuming all software" [...] "is using dot-decimal" [...] "correctly". If APIs do things wrong, this answer's truth isn't invalidated. So the question is, do the APIs do it right or wring? This [standards track document](https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02) shows so much ambiguity in what's right, with "the IETF version and the BSD version" being incompatible, "the only way to generate an interoperable textual IPv4 address is to suppress leading zeroes." – TOOGAM Jul 15 '17 at 17:56
  • No, @TOOGAM, see the quote from some documentation in Jonathan's answer. And even the premise of this answer were true, it's simply very misleading, like it seems you've proven yourself by being surprised by your own experiments? – Arjan Jul 15 '17 at 19:35
  • 1
    Arjan: Note I didn't call him wrong, but "arguably wrong". Weasel word? Yes. But intentional, to be accurate. (I abbreviated my statements, too much it seems, endeavoring to fit in 1 comment.) The "argument" is this: IETF (RFC) language used one approach; code based on the BSD code violates that "standards" documentation & so its design was therefore buggy (even if popular). A counter argument could favor implementation over docs. Although, if you value implementation higher, Brock Vond's question was based on an implementation that seems to use the style found in IETF (not BSD's approach). – TOOGAM Jul 15 '17 at 20:37
  • Sorry, @Arjan, you asked a question and I failed to place an @ so you'd be alerted to the existence of my answer. (I also placed a comment to [Jonathan's answer](https://superuser.com/a/858397/401839). I figure that if people take strong stances, they should be able to explain the positions.) – TOOGAM Jul 15 '17 at 20:48
  • 1
    Wow, 2.5 years later and this gets traction again! Honestly, this answer could have been much more complete. Decimal is the de facto standard (hence my original answer's bluntness) but the spec does specifically allow octal (Going back at least to RFC 790/791 for IPV4 and addressing). Oddly the spec doesn't really ever get very specific from what I know. Additionally, I'd love to expand the answer now but the other answers provide such great examples I'd hate to take any credit from them – Austin T French Jul 15 '17 at 21:09
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.

cde
  • 1,816
  • 13
  • 22
  • 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 '14 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 '14 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 '14 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 '14 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.

Jonathon Reinhart
  • 3,384
  • 12
  • 35
  • 54
  • 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](https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02)? – TOOGAM Jul 15 '17 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.

kasperd
  • 2,861
  • 1
  • 18
  • 29
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.

  • 5
    Interesting. Can you provide a reference for this? – Scott - Слава Україні Jan 18 '16 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 '16 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
  • 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 '17 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 '17 at 17:29
  • 1
    Yes, @TOOGAM, octal 070 is decimal 56. And octal 080 is not a valid number. – Arjan Jul 15 '17 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.

YetAnotherRandomUser
  • 1,919
  • 4
  • 24
  • 49
-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.

xR34P3Rx
  • 372
  • 2
  • 5
  • 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. – Patrick Seymour Dec 28 '14 at 02:52
  • Ok... so for stupid sake... 192.186.002.001 is the same as 192.168.2.1? – Brock Vond Dec 28 '14 at 02:55
  • 1
    @Brock Vond: Yes, except I think you transposed the 186 and 168 accidentally. – Patrick Seymour Dec 28 '14 at 02:57
  • I did yeah - lol... sorry. Both answers are def right but I was looking for a deeper answer so I choose AthomSfere's answer. Thank you all I'd up vote you if I could. – Brock Vond Dec 28 '14 at 03:07
  • 6
    Using ping with 3-digit numbers may not work. It may treat them as octal. – Greenstone Walker Dec 28 '14 at 04:09
  • @GreenstoneWalker I've done it in Linux and it worked fine. – xR34P3Rx Dec 28 '14 at 04:12
  • @xR34P3Rx: No, Greenstone is right. Check again. – Lightness Races in Orbit Dec 28 '14 at 22:27
  • 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 '14 at 13:29
  • 1
    @MarchHo: Yes, that's what we are all saying. – Lightness Races in Orbit Dec 29 '14 at 13:35
  • @MarchHo As of Windows Vista they will be taken as "doesn't look to be a valid ip, so it has to be a FQDN". Windows will attempt a DNS lookup for the bad IP-address. XP tried to make a number out of it regardless leading to weird results. – Tonny Dec 29 '14 at 16:06
  • Yea, i double checked in windows and yes, the 3 digit method doesn't work, only in Linux. – xR34P3Rx Dec 30 '14 at 02:34
  • @xR34P3Rx What specific IP addresses did you try to do it with and have it work? Just because 001 seems to work doesn't mean that 008 or 012 will work, given the concerns people have mentioned about octal (which are not windows-specific). – Random832 Jan 01 '15 at 22:51
  • I assume you're taking about Linux. I have tried 192.168.001.001 – xR34P3Rx Jan 01 '15 at 23:39
-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.

  • 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 '14 at 03: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". – Lightness Races in Orbit Dec 28 '14 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 03 '20 at 22:35