Are IP addresses with and without leading zeroes the same?

92

11

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.

Brock Vond

Posted 2014-12-28T02:45:11.980

Reputation: 1 023

16Accoerding 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 – 2014-12-28T19:24:54.867

4That really is quite a bizarre validation. I'd switch security systems, as @Hagen alludes to. – Lightness Races with Monica – 2014-12-29T13:37:17.833

2This 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 – 2014-12-29T17:51:04.350

2All 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. – 2015-01-01T04:40:44.243

1Can you please accept another answer? The one you accepted is really wrong (or at least incomplete) and has 11 downvotes. – Arjan – 2017-07-15T16:13:00.040

For more fun with doing things in an absurd way, ping 67240450 and also ping 134744072 – TOOGAM – 2017-07-15T18:07:32.683

Answers

103

It depends on the tool.

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

For example, if you use a 3-digit number starting with a zero (or a two-digit one starting with zero, thanks @Dietrich-Epp), then ping will assume the numbers are 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),

Greenstone Walker

Posted 2014-12-28T02:45:11.980

Reputation: 1 022

37Not so much ping, but the underlying routine it uses inet_addr() – cde – 2014-12-28T17:31:28.647

2It's also happening on OSX. – Johann Philipp Strathausen – 2014-12-29T12:03:40.290

21It'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. – Dietrich Epp – 2014-12-30T07:34:56.150

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

Posted 2014-12-28T02:45:11.980

Reputation: 9 766

63The dots are also for convenience; the real IP is 11000000101010000000000000000001 – cpast – 2014-12-28T04:15:15.590

14@cpast or as a hexadecimal number: C0A80001 – jfs – 2014-12-28T08:34:28.900

13or as octal number (starting with 0, with or without dots)

e.g. ping 0300.0250.2.0144 for 192.168.2.100 – Sergey – 2014-12-28T17:50:17.100

15

or as a decimal number 3232235521

– oldmud0 – 2014-12-29T02:52:19.967

14As @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 – 2014-12-29T21:54:00.340

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 is performed on the binary-formatted address for network ID estimation.

– kdbanman – 2014-12-30T21:30:14.360

5This 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 – 2015-06-30T15:03:30.237

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 – 2015-06-30T18:20:23.580

@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 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 – 2017-07-15T17:56:47.277

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 – 2017-07-15T19:35:44.383

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 – 2017-07-15T20:37:18.273

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. I figure that if people take strong stances, they should be able to explain the positions.)

– TOOGAM – 2017-07-15T20:48:29.460

1Wow, 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 – 2017-07-15T21:09:54.893

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

Posted 2014-12-28T02:45:11.980

Reputation: 1 665

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 – 2014-12-29T13:34:04.743

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 – 2014-12-29T16:04:08.423

@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 – 2014-12-29T16:48:03.850

@cde I never bothered to delve that deep into the mechanics of inet_addr(). I'll take your word for it :-) – Tonny – 2014-12-29T19:30:45.117

13

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

Posted 2014-12-28T02:45:11.980

Reputation: 2 917

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 – 2017-07-15T20:46:09.740

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

Posted 2014-12-28T02:45:11.980

Reputation: 2 691

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.

Nick Gar

Posted 2014-12-28T02:45:11.980

Reputation: 1

3Interesting. Can you provide a reference for this? – Scott – 2016-01-18T11:44:40.953

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 – 2016-03-10T14:57:39.597

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

vchrizz

Posted 2014-12-28T02:45:11.980

Reputation: 11

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 – 2017-07-15T16:10:05.633

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 – 2017-07-15T17:29:20.677

1Yes, @TOOGAM, octal 070 is decimal 56. And octal 080 is not a valid number. – Arjan – 2017-07-15T19:07:41.667

-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

Posted 2014-12-28T02:45:11.980

Reputation: 1 494

-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

Posted 2014-12-28T02:45:11.980

Reputation: 350

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 – 2014-12-28T02:52:14.720

Ok... so for stupid sake... 192.186.002.001 is the same as 192.168.2.1? – Brock Vond – 2014-12-28T02:55:04.623

1@Brock Vond: Yes, except I think you transposed the 186 and 168 accidentally. – Patrick Seymour – 2014-12-28T02:57:56.997

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 – 2014-12-28T03:07:23.880

6Using ping with 3-digit numbers may not work. It may treat them as octal. – Greenstone Walker – 2014-12-28T04:09:39.437

@GreenstoneWalker I've done it in Linux and it worked fine. – xR34P3Rx – 2014-12-28T04:12:57.373

@xR34P3Rx: No, Greenstone is right. Check again. – Lightness Races with Monica – 2014-12-28T22:27:35.093

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 – 2014-12-29T13:29:41.820

1@MarchHo: Yes, that's what we are all saying. – Lightness Races with Monica – 2014-12-29T13:35:53.083

@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 – 2014-12-29T16:06:49.370

Yea, i double checked in windows and yes, the 3 digit method doesn't work, only in Linux. – xR34P3Rx – 2014-12-30T02:34:05.853

@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 – 2015-01-01T22:51:45.480

I assume you're taking about Linux. I have tried 192.168.001.001 – xR34P3Rx – 2015-01-01T23:39:56.500

-11

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.

RenegadeX

Posted 2014-12-28T02:45:11.980

Reputation: 1

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 – 2014-12-28T03:05:25.053

9-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 with Monica – 2014-12-28T22:28:13.400