Strange dotless decimal notation of IP address... How does it work?

88

18

Earlier today I thought I had a URL in my clipboard, but I actually had four 9 digit integers copied from a spreadsheet, which were identification numbers from a proprietary system. Completely unrelated to the task at hand. I pasted it into Firefox and was surprised to find that it actually loaded a page. I've seen dotless decimal notations of IPv4 addresses before, but this long number is something much, much larger.

714687644714805209715128610715964400 (stick a HTTP:// in front)

How does this work? All of the decimal -> IPv4 converters that I've found on the Internet all consider it an invalid input. If I take the IPv4 address that it actually loads, and perform the same calculations to convert it to dotless decimal, I get a vastly smaller number.

I've read that ping can accept dwords and do some conversion, but it cannot convert this number to an IP address. IPv6 is out of the question as this host does not have IPv6 connectivity.

What kind of madness is this? It's stumped myself and my coworkers.

Edit: It's back online now.

beeks

Posted 2014-04-02T01:38:27.017

Reputation: 1 031

4

See http://www.pc-help.org/obscure.htm

– Shamtam – 2014-04-02T01:49:27.987

@Shamtam, yes, I've been there, and using the calculations on that site to obfuscate an IPV4 address, I get a MUCH smaller number. None of the calculations I've tried will result in the number I stumbled across, which resolves properly in a browser. – beeks – 2014-04-02T01:53:05.210

2Are you really sure it's not an IPv6 address? Because this number breaks down to 8 digits in base 65536; IPv6 addresses have 8 digits in base 65536. Represented in hex as is usual for IPv6, it's 89:a4d2:471b:45ef:77ed:c70f:da35:93f0. – Christian – 2014-04-02T14:50:29.417

2@Christian His explanation for the source of the number jives with the actual number shown, which has 36 digits (each ID is 9 digits either 714xxxxxx or 715xxxxxx). The computer doesn't even have IPv6, and the number taken as an IPv4 address does indeed return a web page. Numbers from ~5E33 to ~3E38 have 8 digits in base 65536, I think it's just a coincidence that his falls in that range (plus, any smaller number would also be a valid IPv6 address) – Tim S. – 2014-04-03T14:31:40.643

@TimS. Well, the IP peanut_butter calculated doesn't return pings for me and doesn't return a web site either. But then, neither does that huge number return anything for me. I think it would help to run a wireshark while letting firefox do its thing and at least see what IP it actually connects to. – Christian – 2014-04-03T19:49:50.463

@Christian, it no longer returns a ping or page for me either. The page that was returning was actually a router in Korea, which was not secured and had a default login/password of 'ADMIN/ADMIN.' With the number of hits this question has received, I wouldn't doubt if someone did something nefarious to bring it offline. – beeks – 2014-04-03T19:55:43.050

1@beeks Ok, it already didn't work when I tried it yesterday but given that it was an unsecured router maybe that's not so surprising. So are you saying that you basically put a random number into your address bar? Or what kind of spreadsheet did you have there that contains weirdly coded IP addresses of unsecured routers? ;) – Christian – 2014-04-03T20:01:27.810

1@Christian, LOL. They were some unique message identifiers in a compliance system. Totally freak chance that I pasted them into the address bar, and it worked. I bet that will never happen again to me in my life :) – beeks – 2014-04-03T20:46:43.363

1

See also https://bugzilla.mozilla.org/show_bug.cgi?id=67730

– Jason C – 2014-04-03T23:06:37.840

It seems to work for me right now. I am getting a router page looking like this.

– eis – 2014-04-04T13:03:39.090

1@eis And did you check what IP your browser actually connected to in wireshark or iftop or something? – Christian – 2014-04-04T16:19:19.273

nope, sorry, somehow missed that comment. Have to try to remember to do it some other time (host seems offline now). But the screenshot shows the ip peanut_butter calculated. – eis – 2014-04-04T18:20:56.593

Answers

92

This is quite an interesting question, and took me a little while to figure out. The short answer is the last 32-bits of the number are 3660944368 (in decimal, which can be found by 714687644714805209715128610715964400 mod 2^32)

This is the decimal value of the IPv4 address 218.53.147.240, which can be found by converting it to base-256 3660944368 = 218*(256^3)+53*(256^2)+147*(256)+240 analogous to writing out a number in decimal (base-10). For example 234 = 2*10^2+ 3*10 + 4.

As @chritohnide points out, each section of dotted IPv4 addresses is called an octet as it represents 8 binary digits. It is also worth noting that the various formats of IPv4 addresses (such as the dotted decimal, or the pure decimal) are just different ways of representing the 32-bit binary number for out benefit.

Since IPv4 addresses are 32-bit numbers, so only last 32-bits of the number are used to resolve the address. Why this is true is not as obvious. As others have pointed out, the full number looks strikingly similar an IPv6 address in decimal, but is not a valid address.

Looking at the Teredo specification (see 4. Teredo Addresses), the Client IPv4 occupies the last 32-bits of the IPv6 address, but the prefix of the number does not match the Teredo specification (Also see wikipedia).

peanut_butter

Posted 2014-04-02T01:38:27.017

Reputation: 1 722

12Nice answer. It might also be useful to mention that each section of a dotted IPv4 address is called an octet because it is the decimal representation of an 8 bit binary number (4 octets = 4 x 8 bits = 32 bits of IPv4 address) and that the decimal version is really only for our benefit. – chritohnide – 2014-04-02T05:55:31.263

1Nice answer! I think it could be cleaned up more in the why and how, but it's still a complete answer. +1 – Raystafarian – 2014-04-02T09:19:16.523

Awesome. I would have never thought to try a base as high as 256. Kudos! – beeks – 2014-04-02T12:16:58.077

@beeks: Actually, you can just think of the "standard" way to write an IPv4 address as writing down a 32-bit number in base-256. – Jörg W Mittag – 2014-04-02T14:13:11.963

4You sure it's not IPv6 decimal notation? It successfully converts to 0089:a4d2:471b:45ef:77ed:c70f:da35:93f0 – Izkata – 2014-04-02T14:28:18.203

1@Izkata You are completely correct. The last 32-bits of an IPv6 address is the public IPv4 address of the client. – peanut_butter – 2014-04-02T14:56:43.807

@peanut_butter Can you clarify that as part of the last paragraph? I'd never actually heard that before – Izkata – 2014-04-02T15:04:34.193

5@Izkata: Unlikely because that address would be in an unallocated and reserved part of IPv6 address space. – hmakholm left over Monica – 2014-04-02T16:05:38.003

@Izkata Look at section 4 (Teredo Addresses) of http://www.rfc-editor.org/rfc/rfc4380.txt

– peanut_butter – 2014-04-02T20:34:35.537

The inet_aton man page explains the 4 IPv4 address formats.

– mniip – 2014-04-03T08:19:46.617

1@Christian this is actually a perfectly plausible explanation. E.g. 74.125.224.72 is an IP address for google.com. If I type the decimal equivalent, 1249763400, into Firefox, it sends a request to the right IP, 74.125.224.72, with a "Host" header of 1249763400. If I add a multiple of 2^32 to this (5313657853246575461916744 == 1249763400 mod 2^32), it still sends a request to the right IP, except with a "Host" header of the larger number, "5313657853246575461916744". Google decides that the shorter IP representation is valid (302 Found), while the larger is not (404; but it does respond!). – Tim S. – 2014-04-03T20:03:12.187

3The number (in ASCII) will probably just be run through one of the C stdlib string to int functions to convert in into the 32-bit ipv4 address. In most implementations of the C stdlib those conversions will automatically do a modulo 2^<desired integer size>. The result in that case is exactly to observed behavior. – Tonny – 2014-04-03T22:45:46.410

3It's worth noting that this is probably a quirk of Firefox's URL parser. It seems to recognize that it is a number rather than a URL and attempts to parse it as a 32-bit undotted IP address (the resulting parsed integer ends up modulo 32-bit and it doesn't really do any error checking on the input). Chrome, for example, does not show this behavior. It actually might be worth reporting it as a trivial bug in Firefox. – Jason C – 2014-04-03T23:03:37.260

3

In fact: A request to ignore these types of addresses, and others, in Firefox was already submitted a few years ago, but never seemed to take hold.

– Jason C – 2014-04-03T23:05:35.697