Live data from Hacker News

This is a valid ipv4 address

184.172.10.74

71–80 of 101 posts

Re: This is a valid ipv4 address

#71
post #66

Earlier quoted context omitted.

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.

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 underly…

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.

Re: This is a valid ipv4 address

#72
post #63
post #5

The decoded URL for this submission is http://184.172.10.74/ — the server for Hacker News. Here's some other encodings you can use for the same address, they're all valid and recognised by most browsers and other software: http://3098282570/ http://7393249866/ http://0xb8.0xac.0x0a.0x4a/ http://0270.0254.0012.0112/ The source for this comment is an XSS filtering bypass tool by RSnake — http://ha.ckers.org/xsscalc.htm…

Funny. http://7393249866/ resolves to http://255.255.255.255/ in Opera (on linux), it appears to do saturating math for the overflow.

It works fine in my Opera 12.16 for Linux (amd64).

Re: This is a valid ipv4 address

#73
post #61

Using this python script to make the int-ip-address: #!/usr/bin/env python import socket import struct def ip2long(ip): packedIP = socket.inet_aton(ip) return struct.unpack("!L", packedIP)[0] print ip2long('192.241.224.102') # your website ip address # or download it on github: https://gist.github.com/Leask/7075483

Or more straightforward in Python 3.3+:

    import ipaddress

    print(int(ipaddress.ip_address('192.241.224.102')))

Re: This is a valid ipv4 address

#74
post #67

Earlier quoted context omitted.

Hexa addresses can be in one single number too: http://0xb8ac0a4a/

What? It's bothered me for years that IP addresses aren't just bitfields. Why would you use a format other than this?

10.0.0.1 or 0x0a000001?

4.2.2.1 or 0x04020201?

Mostly readability and speed of typing, I would think.

Re: This is a valid ipv4 address

#76
post #66

Earlier quoted context omitted.

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 underly…

> 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

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

    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:

    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

    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/ is not a valid URI.

Re: This is a valid ipv4 address

#77
post #66

Earlier quoted context omitted.

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 underly…

> 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

Oh, Rachel Kroll. You mean that Rachel Kroll? The one I've never heard of?

Anyway, https://yourlogicalfallacyis.com/appeal-to-authority

I don't care who someone is because I evaluate individual statements on their own merits. In Rachel's own statement, she just learned "why this worked" "the last time it came up on HN". I got my first modem in 1985 (have you noticed my username?) and been in IT for longer than most HN users have been alive. But feel free to tell me how I don't have a right to discuss something because I'm correcting the Rachel Kroll.

Re: This is a valid ipv4 address

#78
The inverse of this actually bit me when I was porting my company's app from iOS to Windows 8. We have a custom URI scheme to open stories in our app that looks like foo://. On iOS, we just take the bit after the scheme and use it directly. Windows, however, was giving it to us as a dotted-decimal string, so we had to convert back from that to the integer representation before using it. That was the day I learned that these different kinds of representations could be used and to not assume anything about URIs.

Re: This is a valid ipv4 address

#79
post #66

Earlier quoted context omitted.

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 underly…

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.

A subtle distinction

Hence my reference to nit-picking.

Re: This is a valid ipv4 address

#80
post #77

Earlier quoted context omitted.

> 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

Oh, Rachel Kroll. You mean that Rachel Kroll? The one I've never heard of? Anyway, https://yourlogicalfallacyis.com/appeal-to-authority I don't care who someone is because I evaluate individual statements on their own merits. In Rachel's own statement, she just learned "why this worked" "the last time it came up on HN". I got my first modem in 1985 (have you noticed my username?) and been in IT for longer than most H…

Agreed. I read that statement with the same disregard. Unless she wrote the entirety of the ip stack specification, the argument is moot. Not one single person does or can know every piece of the technology puzzle. This amounts to calling me stupid for using gnome because Linus likes KDE, or more recently vice versa.
Post reply on HN