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.

  • 4
    See pc-help.org/obscure.htm – Shamtam Apr 2 '14 at 1:49
  • 2
    Are 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 Apr 2 '14 at 14:50
  • 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. Apr 3 '14 at 14:31
  • 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 Apr 3 '14 at 20:01
  • 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 Apr 3 '14 at 20:46

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, 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).

  • 12
    Nice 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 Apr 2 '14 at 5:55
  • 4
    You sure it's not IPv6 decimal notation? It successfully converts to 0089:a4d2:471b:45ef:77ed:c70f:da35:93f0 – Izkata Apr 2 '14 at 14:28
  • 5
    @Izkata: Unlikely because that address would be in an unallocated and reserved part of IPv6 address space. – hmakholm left over Monica Apr 2 '14 at 16:05
  • 3
    The 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 Apr 3 '14 at 22:45
  • 3
    It'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 Apr 3 '14 at 23:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.