CODEWITHSUNDEEP
network-programmingip
RaistlinMolina
RaistlinMolina

Reputation: 355

Is 192.056.2.01 a valid representation of an v4 IP?

I'm writing some code to convert an v4 IP stored in a string to a custom data type (a class with 4 integers in this case).

I was wondering if I should accept IPs like the one I put in the title or only IPs with no preceding zeros, let's see it with an example.

This two IPs represent the same to us (humans) and for example windows network configuration accepts them:

192.56.2.1 and 192.056.2.01

But I was wondering if the second one is actually correct or not.

I mean, according to the RFC is the second IP valid?

Thanks in advance.

Upvotes: 3

Views: 930

Answers (4)

Scott - Слава Україні
Scott - Слава Україні

Reputation: 678

Textual Representation of IPv4 and IPv6 Addresses is an “Internet-Draft”, which, I guess, is like an RFC wanna-be.  (Also, it expired a decade ago, on 2005-08-23, and, apparently, has not been reissued, so it’s not even close to being official.)  Anyway, in Section 2: History it says,

The original IPv4 “dotted octet” format was never fully defined in any RFC, so it is necessary to look at usage, rather than merely find an authoritative definition, to determine what the effective syntax was.  The first mention of dotted octets in the RFC series is … four dot-separated parts, each of which consists of “three digits representing an integer value in the range 0 through 255”.

A few months later, [IPV4-NUMB] … used dotted decimal format, zero-filling each encoded octet to three digits.
                ⋮
Meanwhile, a very popular implementation of IP networking went off in its own direction.  4.2BSD introduced a function inet_aton(), … [which] allowed octal and hexadecimal in addition to decimal, distinguishing these radices by using the C language syntax involving a prefix “0” or “0x”, and allowed the numbers to be arbitrarily long.

The 4.2BSD inet_aton() has been widely copied and imitated, and so is a de facto standard for the textual representation of IPv4 addresses.  Nevertheless, these alternative syntaxes have now fallen out of use … [and] All the forms except for decimal octets are seen as non-standard (despite being quite widely interoperable) and undesirable.

So, even though POSIX defines the behavior of inet_addr to interpret leading zero as octal (and leading “0x” as hex), it may be safest to avoid it.

P.S. RFC 790 has been obsoleted by RFC 1700, which uses decimal numbers of one, two, or three digits, without leading zeroes.

Upvotes: 2

nodakai
nodakai

Reputation: 8033

Be careful, inet_addr(3) is one of Unix's standard API to translate a textual representation of IPv4 address into an internal representation, and it interprets 056 as an octal number:

All numbers supplied as parts in IPv4 dotted decimal notation may be decimal, octal, or hexadecimal, as specified in the ISO C standard (that is, a leading 0x or 0X implies hexadecimal; otherwise, a leading '0' implies octal; otherwise, the number is interpreted as decimal).

Its younger brothers like inet_ntop(3) and getaddrinfo(3) are all the same:

Summary

Although such textual representations of IP addresses like 192.056.2.01 might be valid on all platforms, different OS interpret them differently.

This would be enough reason for me to avoid such a way of textual representation.

Upvotes: 4

apomene
apomene

Reputation: 14389

Defining if it is correct or not depends on your implementation. As you mentioned windows OS considers it correct because it removes any leading zeros when it resolves the IP.

So if in your program you set an appropriate logic, e.g every subset of the IP stored in your 4 integer class, without the leading zeros, it will be correct for your case too.

Upvotes: 0

Orelsanpls
Orelsanpls

Reputation: 23515

Pros

In decimal numerotation 056 is equals to 56 so why not?

Cons

0XX format is commonly used to octal numerotation

Whatever your decisions just put it on your documentation and it will be ok :)

Upvotes: 1

Related Questions