According to this question IP address representation in the Maxmind Geolitecity database
What is the official name for this format of an ip-address?
Who invented it? Is it internationally standardised?
I mean the format without dots. Never heard of it. I know about the binary octets separated by dots.
It is called a decimal representation. IP address is a 32bit binary number which we usually represent in the dot-decimal notation you mentioned. Since it is originally an 32bit number it is easier (and faster) to store and manipulate it in it's native format (as a number) than to parse the string representation.
For example you have 10.0.0.1 address whose octets in binary looks like:
00001010.00000000.00000000.00000001
When you lose the dots and look at it like a number you get 167772161 which is what ip2long() function will return if you pass 10.0.0.1 as an argument.
Related
When using zero-compression on the following IPv6 address
2001:0DB8:0000:CD30:0000:0000:0000:0000/60
Why is this not correct:
2001:DB8::CD30::/60
... while this is:
2001:DB8:0:CD30::/60
Zero compression can only be made once. The reason for this is, that the IPv6 address is not unique any more otherwise.
Take your example 2001:DB8::CD30::/60 will it expand to
2001:0DB8:0000:0000:0000:CD30:0000:0000/60
or
2001:0DB8:0000:0000:CD30:0000:0000:0000/60
or
2001:0DB8:0000:CD30:0000:0000:0000:0000/60
...?
If only one "::" is used, the result will always be unique as there is only one possible fixed number of zeros to be inserted.
Because it is ambiguous.
The address 2001:DB8::CD30:: could be expanded in any of the following possibilities:
2001:DB8:0:CD30:0:0:0:0
2001:DB8:0:0:CD30:0:0:0
2001:DB8:0:0:0:CD30:0:0
2001:DB8:0:0:0:0:CD30:0
The reason is that :: is used to shorten multiple zeros in the 16-bit address field.
In your example 2001:0DB8:0000:CD30:0000:0000:0000:0000/60, it only has multiple 0s in the 16-bit field at the suffix, the 0000 in 2001:0DB8:0000:CD30: is just one 16-bit field and you'd just use 0 to shorten it.
More interesting question: How would you shorten this2001:0000:0000:CD30:0000:0000:0000:0000/60?
It is defined in the standard:
In addition, Section 2.2 of [RFC4291] notes,
'The "::" can only appear once in an address.'
What it means that the address can be written as either:
2001:0:0:CD30::/60 OR 2001::0:CD30:0:0:0:0/60.
Both are valid, but I'd prefer the first representation since the purpose of zeroco mpression is to shorten the address where the first representation is shorter.
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 wiht 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.
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:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
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:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_ntop.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html
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.
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 :)
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.
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][3]] …
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][4]
to interpret leading zero as octal (and leading “0x” as hex),
it may be safest to avoid it.
P.S. [RFC 790][3] has been obsoleted by [RFC 1700][5],
which uses decimal numbers of one, two, or three digits,
without leading zeroes.
[3]: https://www.rfc-editor.org/rfc/rfc790 "the "Assigned Numbers" RFC"
[4]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
[5]: https://www.rfc-editor.org/rfc/rfc1700
Normally, we see IP address in this format:
"108.169.14.35",
however, if I convert it to "-o pipe" (old machine) format ,it appears like this "0|0|0|1823018531"
Now I would like to understand what causes the IP address to look entirely different. And is there a way to convert it back from "-o pipe" to "normal" format ?
1823018531 is the IP address 108.169.14.35 written in decimal format. No way to know what the zeros are for.
To convert the decimal format to "dotted quad", the standard library of your programming language probably has a subroutine for it. if not, you get the numbers from last to first by dividing by 256 and taking the remainder, and then dividing by 256 again and taking the remainder, and repeating two more times.
has anybody some good ideas to compare two ipv6 addresses. It look like the shortage rules are making it complicated.
for instance the full address
1234:0db8:0000:0000:0000:ff00:ff00:0011
leading zero can be removed => 1234:0db8::::ff00:ff00:11
one group of empty fields can be removed 1234:0db8::ff00:ff00:00111
the last 32 bit can be an old fashioned ipv4 address 1234:0db8::::ff00:172.0.0.15
You can use the standard library function socket.inet_pton to convert the addresses into a byte string for comparison:
>>> socket.inet_pton(socket.AF_INET6,'1234:0db8::ff00:ff00:0011')
'\x124\r\xb8\x00\x00\x00\x00\x00\x00\xff\x00\xff\x00\x00\x11'
>>> socket.inet_pton(socket.AF_INET6,'1234:0db8:0000:0000:0000:ff00:ff00:0011')
'\x124\r\xb8\x00\x00\x00\x00\x00\x00\xff\x00\xff\x00\x00\x11'
This will reduce the risk of you creating your own IPv6 bug.
Example above is in python, but the inet_pton function is available on different platforms and languages:
http://msdn.microsoft.com/en-us/library/windows/desktop/cc805844(v=vs.85).aspx
http://man7.org/linux/man-pages/man3/inet_pton.3.html
You could just split it by colons and then compare each value.
If you encounter an empty field -> insert '0000' for it.
If you encounter a field with less than 4 digits -> fill it up with zeroes
Additionally you could give each of the fields a weight to emphasize the values of the fields.
I know that it is possible to write IPs in IPv4 as an integer e.g. 2130706433 instead of 127.0.0.1.
What is the reason for this possibility?
Is there a similar notation for IPv6?
I tried ping -6 1 as a try to ping ::1, but that don't work (the host would not exists).
IPv4 addresses can be represented in multiple ways. For example the default loopback IP can be one of:
127.0.0.1
0177.0.0.1
0x7f.0.0.1
127.0.1
127.1
2130706433
017700000001
0x7f000001
The first notation (full 8-bit decimal dotted) is in wide usage, the remaining ones are seldom used but allowed by the inet_addr POSIX standard function. Only the first familiar notation has been retained in the newer inet_ntop/inet_pton POSIX standard functions which process both IPv4 and IPv6 addresses.
With IPv6, 16-bit hexadecimal dotted notation with an optional decimal dotted trailer (for embedded IPv4) and also an optional zero compression is what the standard defines.
eg:
2001:0db8:85a3:0000:0000:8a2e:9370:7334
2001:0db8:85a3::8a2e:9370:7334
There are then still multiple representations of a single address. To avoid the resulting confusion RFC 5952 recommends a canonical form that allows a unique notation.
An IPv4 address is just a 32bit number. You could represent it in any way you can represent such a number (decimal, hex, octal). The dotted notation a.b.c.d is just much more practical.
You can do the same thing with IPv6 addresses, except that those are 128bit numbers - even harder to grok in decimal form.
The usual tools will only deal with usual notations. Decimal isn't one of those.