3 ms·

No, it works because the tool allows it by virtue of how it's implemented. Find a different ping or inet_aton implementation and it won't necessarily work.

nzmsv 13y ago
Interesting, I went searching and learned something new. You are right. Apparently the textual representation of IP addresses was not properly specified in any RFC, so this is in fact a quirk of the implementation. http://tools.ietf.org/html/draft-main-ipaddr-text-rep-02 http://tools.ietf.org/html/draft-main-ipaddr-text-rep-02
300bps 13y ago
Find a different ping or inet_aton implementation and it won't necessarily work. At best, you seem to be picking nits. More likely though I think you just have a very surface level understanding of what is going on here. The bottom line is that, as I said already, an IPv4 address is a 32 bit number. It's also true that various tools that communicate with IP addresses utilize different methods to arrive at the underlying 32 bit number. But it's not right to say that "this only applies to systems using ping from iptools and glibc" as the article you linked says. Many of these "tricks" worked in all manner of operating systems and applications. I was discussing many of them in IRC using Windows 3.1 and Trumpet Winsock before 1994. Again, the bottom line is that an IPv4 IP address is a 32 bit number and there are dozens of ways that various applications allow you to arrive at that number. It's silly for an article or someone quoting it to attempt to say it only applies to one implementation.
- jmillikin 13y ago
  > At best, you seem to be picking nits. More likely though > I think you just have a very surface level understanding > of what is going on here. You are replying to Rachel Kroll, and this quote is the networking equivalent of http://c2.com/cgi/wiki?KornShellStory http://c2.com/cgi/wiki?KornShellStory
  - barrkel 13y ago
    I rather think they're talking about different things. Rachel analyzed things from the bottom up, seeing the scope of how much worked from the implementation. But the flexibility of an implementation doesn't tell you much about the specification, as implementations are usually more lenient and broad than the specification. 300bps is talking about how in_addr is a 32-bit structure and indeed contains s_addr; IPv4 addresses are fundamentally 32-bit unsigned integers. To actually shed some light on this one would need to look into the specified encoding of in_addr in URLs. http://tools.ietf.org/html/rfc3986#section-7.4 http://tools.ietf.org/html/rfc3986#section-7.4 Although the URI syntax for IPv4address only allows the common dotted-decimal form of IPv4 address literal, many implementations that process URIs make use of platform-dependent system routines, such as gethostbyname() and inet_aton(), to translate the string literal to an actual IP address. Unfortunately, such system routines often allow and process a much larger set of formats than those described in Section 3.2.2. For example, many implementations allow dotted forms of three numbers, wherein the last part is interpreted as a 16-bit quantity and placed in the right-most two bytes of the network address (e.g., a Class B network). Likewise, a dotted form of two numbers means that the last part is interpreted as a 24-bit quantity and placed in the right-most three bytes of the network address (Class A), and a single number (without dots) is interpreted as a 32-bit quantity and stored directly in the network address. Adding further to the confusion, some implementations allow each dotted part to be interpreted as decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0 implies octal; otherwise, the number is interpreted as decimal). These additional IP address formats are not allowed in the URI syntax due to differences between platform implementations. http://tools.ietf.org/html/rfc3986#section-3.2.2 http://tools.ietf.org/html/rfc3986#section-3.2.2: A host identified by an IPv4 literal address is represented in dotted-decimal notation (a sequence of four decimal numbers in the range 0 to 255, separated by "."), as described in [RFC1123] by reference to [RFC0952]. Note that other forms of dotted notation may be interpreted on some platforms, as described in Section 7.4, but only the dotted-decimal form of four octets is allowed by this grammar. IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 http://tools.ietf.org/html/rfc1123 http://tools.ietf.org/html/rfc1123 Whenever a user inputs the identity of an Internet host, it SHOULD be possible to enter either (1) a host domain name or (2) an IP address in dotted-decimal ("#.#.#.#") form. The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System. So in this light, the headline on this page is both right and wrong. 3098282570 is indeed a valid IPv4 address; it is within the range of a 32-bit unsigned integer. It's not required or recommended to be recognized as such in host name contexts, though, and http://3098282570/ http://3098282570/ is not a valid URI.
- danellis 13y ago
  rachelbythebay didn't say it only applies to one implementation. She said it was implementation specific. A subtle distinction, but she's correct. Just because something is fundamentally a 32-bit number, that doesn't automatically mean that all possible representations of that number will be converted to it. They have to be implemented to do so.
  - 300bps 13y ago
    A subtle distinction Hence my reference to nit-picking.

nzmsv 13y ago

Interesting, I went searching and learned something new. You are right. Apparently the textual representation of IP addresses was not properly specified in any RFC, so this is in fact a quirk of the implementation. http://tools.ietf.org/html/draft-main-ipaddr-text-rep-02 http://tools.ietf.org/html/draft-main-ipaddr-text-rep-02

300bps 13y ago

Find a different ping or inet_aton implementation and it won't necessarily work. At best, you seem to be picking nits. More likely though I think you just have a very surface level understanding of what is going on here. The bottom line is that, as I said already, an IPv4 address is a 32 bit number. It's also true that various tools that communicate with IP addresses utilize different methods to arrive at the underlying 32 bit number. But it's not right to say that "this only applies to systems using ping from iptools and glibc" as the article you linked says. Many of these "tricks" worked in all manner of operating systems and applications. I was discussing many of them in IRC using Windows 3.1 and Trumpet Winsock before 1994. Again, the bottom line is that an IPv4 IP address is a 32 bit number and there are dozens of ways that various applications allow you to arrive at that number. It's silly for an article or someone quoting it to attempt to say it only applies to one implementation.

jmillikin 13y ago
> At best, you seem to be picking nits. More likely though > I think you just have a very surface level understanding > of what is going on here. You are replying to Rachel Kroll, and this quote is the networking equivalent of http://c2.com/cgi/wiki?KornShellStory http://c2.com/cgi/wiki?KornShellStory
- barrkel 13y ago
  I rather think they're talking about different things. Rachel analyzed things from the bottom up, seeing the scope of how much worked from the implementation. But the flexibility of an implementation doesn't tell you much about the specification, as implementations are usually more lenient and broad than the specification. 300bps is talking about how in_addr is a 32-bit structure and indeed contains s_addr; IPv4 addresses are fundamentally 32-bit unsigned integers. To actually shed some light on this one would need to look into the specified encoding of in_addr in URLs. http://tools.ietf.org/html/rfc3986#section-7.4 http://tools.ietf.org/html/rfc3986#section-7.4 Although the URI syntax for IPv4address only allows the common dotted-decimal form of IPv4 address literal, many implementations that process URIs make use of platform-dependent system routines, such as gethostbyname() and inet_aton(), to translate the string literal to an actual IP address. Unfortunately, such system routines often allow and process a much larger set of formats than those described in Section 3.2.2. For example, many implementations allow dotted forms of three numbers, wherein the last part is interpreted as a 16-bit quantity and placed in the right-most two bytes of the network address (e.g., a Class B network). Likewise, a dotted form of two numbers means that the last part is interpreted as a 24-bit quantity and placed in the right-most three bytes of the network address (Class A), and a single number (without dots) is interpreted as a 32-bit quantity and stored directly in the network address. Adding further to the confusion, some implementations allow each dotted part to be interpreted as decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0 implies octal; otherwise, the number is interpreted as decimal). These additional IP address formats are not allowed in the URI syntax due to differences between platform implementations. http://tools.ietf.org/html/rfc3986#section-3.2.2 http://tools.ietf.org/html/rfc3986#section-3.2.2: A host identified by an IPv4 literal address is represented in dotted-decimal notation (a sequence of four decimal numbers in the range 0 to 255, separated by "."), as described in [RFC1123] by reference to [RFC0952]. Note that other forms of dotted notation may be interpreted on some platforms, as described in Section 7.4, but only the dotted-decimal form of four octets is allowed by this grammar. IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 http://tools.ietf.org/html/rfc1123 http://tools.ietf.org/html/rfc1123 Whenever a user inputs the identity of an Internet host, it SHOULD be possible to enter either (1) a host domain name or (2) an IP address in dotted-decimal ("#.#.#.#") form. The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System. So in this light, the headline on this page is both right and wrong. 3098282570 is indeed a valid IPv4 address; it is within the range of a 32-bit unsigned integer. It's not required or recommended to be recognized as such in host name contexts, though, and http://3098282570/ http://3098282570/ is not a valid URI.
danellis 13y ago
rachelbythebay didn't say it only applies to one implementation. She said it was implementation specific. A subtle distinction, but she's correct. Just because something is fundamentally a 32-bit number, that doesn't automatically mean that all possible representations of that number will be converted to it. They have to be implemented to do so.
- 300bps 13y ago
  A subtle distinction Hence my reference to nit-picking.