4 ms·

The last time this came up on HN, I decided to dig into ping and glibc's resolver stuff to find out exactly why this worked. http://rachelbythebay.com/w/2012/1

The last time this came up on HN, I decided to dig into ping and glibc's resolver stuff to find out exactly why this worked. http://rachelbythebay.com/w/2012/10/13/ping/ http://rachelbythebay.com/w/2012/10/13/ping/

300bps 13y ago
That article is focused on ping and glibc but the reason why this works is fundamental to IPv4 itself. All IPv4 address are 32 bit addresses. That's why each number of an IPv4 address that people are familiar with are called octets. They represent 8 bits of the 32 bit address. So if you have 127.0.0.1, then the first octet is 127, the second is 0 and so on. Any representation of this 32 bit number (including the most familiar A.B.C.D format) is a kind of short-hand for representing that 32 bit number. I tried finding a link to a particular site that was phenomenal for learning the entire TCP/IP stack but I haven't seen that site since at least 1998. But basically, if you want to spend time learning about IPv4 right before IPv6 becomes the dominant standard, then look into how hosts use the combination of IP address and subnet mask to determine if something is on the local network, how hosts use ARP to translate a 32 bit IP address into a MAC address and all the other low level protocols.
- rachelbythebay 13y ago
  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.
- VLM 13y ago
  "if you want to spend time learning about IPv4 right before IPv6 becomes the dominant standard" Not as much is changing as you think, at least for basic concepts and intro level stuff. Simpler in some ways. To kick over a real bee hive, as I guy who's used ipv6 for I donno a decade or so now, the main issues are NAT6 love it (noobs) or hate it (folks who know what they're doing), believe it or not its easier to make a statefull firewall than to do NAT, some folks have bizarre ideas about ipv6 netmasks and what other people should be permitted to have, the concept of RFC1918 in ipv6 is more complicated, router advertisements RA love them or filter them, you probably need DHCPv6 or maybe not, and some firewall nuts filter DNS traffic into packets too small to hold AAAA records (but large enough to hold A records) Other than that ipv6 is just obese ipv4, the concepts of subnet and mask aren't changing, you've still got ARP just different address family in the protocol... (edited to add my favorite topic, hand editing text zone files is probably not the most scalable way to implement reverse (or forward!) DNS for ipv6 from pure PITA perspective. Then again doing things by hand instead of automating is a PITA for ipv4 not just ipv6.)
chris_wot 13y ago
That's an awesome article! I love reading Rachel's blog. It's almost always interesting.

300bps 13y ago

That article is focused on ping and glibc but the reason why this works is fundamental to IPv4 itself. All IPv4 address are 32 bit addresses. That's why each number of an IPv4 address that people are familiar with are called octets. They represent 8 bits of the 32 bit address. So if you have 127.0.0.1, then the first octet is 127, the second is 0 and so on. Any representation of this 32 bit number (including the most familiar A.B.C.D format) is a kind of short-hand for representing that 32 bit number. I tried finding a link to a particular site that was phenomenal for learning the entire TCP/IP stack but I haven't seen that site since at least 1998. But basically, if you want to spend time learning about IPv4 right before IPv6 becomes the dominant standard, then look into how hosts use the combination of IP address and subnet mask to determine if something is on the local network, how hosts use ARP to translate a 32 bit IP address into a MAC address and all the other low level protocols.

rachelbythebay 13y ago
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.
VLM 13y ago
"if you want to spend time learning about IPv4 right before IPv6 becomes the dominant standard" Not as much is changing as you think, at least for basic concepts and intro level stuff. Simpler in some ways. To kick over a real bee hive, as I guy who's used ipv6 for I donno a decade or so now, the main issues are NAT6 love it (noobs) or hate it (folks who know what they're doing), believe it or not its easier to make a statefull firewall than to do NAT, some folks have bizarre ideas about ipv6 netmasks and what other people should be permitted to have, the concept of RFC1918 in ipv6 is more complicated, router advertisements RA love them or filter them, you probably need DHCPv6 or maybe not, and some firewall nuts filter DNS traffic into packets too small to hold AAAA records (but large enough to hold A records) Other than that ipv6 is just obese ipv4, the concepts of subnet and mask aren't changing, you've still got ARP just different address family in the protocol... (edited to add my favorite topic, hand editing text zone files is probably not the most scalable way to implement reverse (or forward!) DNS for ipv6 from pure PITA perspective. Then again doing things by hand instead of automating is a PITA for ipv4 not just ipv6.)

chris_wot 13y ago

That's an awesome article! I love reading Rachel's blog. It's almost always interesting.