Browser Arcana: IP Literals in URLs

While virtually all web traffic flows over connections based on the Internet Protocol, most of the time your browser first uses DNS to look up the target hostname’s IP address. However, sometimes URLs directly specify an IP address, skipping DNS altogether. When an IP appears directly within such an URL, it is said to have an IP-Literal Hostname. In general, using IP-Literal hostnames is a bad idea (as they don’t support DNS Failover and other useful features) but in rare cases their use may be reasonable-- e.g. when communicating directly with network devices like switches and routers.

The most common IP-Literal URLs use the dotted-quad notation for an IP v4 address; for instance, The introduction of IPv6 complicated matters a bit, since IPv6 literals must be placed within square-brackets in the URL, like so: http://[::1]/mypage. Many users are surprised, however, to learn that IPv4 literals can be expressed using other notations.

For instance, any internal “0“ components of a dotted quad may be omitted, and thus http://127.0.1 and http://127.1 are both equivalent to

The more interesting of the notations are the raw integer forms—remember, an IPv4 address is simply a 32bit integer. As such, you can represent in its decimal form as http://2130706433/ or even in octal form as http://017700000001/. The reason that these variants are interesting is that they don’t contain any dots, and various software components may treat hostnames without dots as special1. In 2001, for instance, incorrect mapping of all dotless hostnames to the (privileged) Intranet security zone resulted in a serious security vulnerability which was patched by introducing special detection for IP address literals.

In Internet Explorer 7, the CURI object was introduced to standardize handling of URLs throughout the browser and OS; one of the first steps that class undertakes when constructing a URL object from a string is to convert any IP literal hostname into its canonical dotted-quad form. Chrome and Opera appear to match Internet Explorer’s behavior here, while Firefox 27 leaves the undotted decimal in the address bar and in the request sent to the network2:

IE, Chrome, Opera

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.45 Safari/537.36


GET / HTTP/1.1
Host: 2130706433
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0

If your code makes any sort of security decision based on the absence of dots within a hostname, be sure that you aren’t fooled by undotted IP literals!


1 For instance, the isPlainHostName function in PAC scripts, or the network.automatic-ntlm-auth.allow-non-fqdn preference in Firefox.

2 Mozilla has an issue filed to remove support for undotted IP literals entirely, and while it’s tagged as “New,” it is today just over 13 years old.

Comments (3)
  1. Anne says:

    Parsing those forms as IP addresses is forbidden by the relevant RFCs and now the URL Standard.

    [EricLaw] Indeed, this syntax is not permitted under a number of RFCs (I'm not sure which ones you are citing, or which "URL Standard" you're referring to– RFC3986, perhaps?) but it's an academic point– all browsers support this syntax and likely will continue to do so for quite some time.

  2. I didn't know this is possible. Previously I wrote a blog post about the Windows 8.1 security bug in which IE11 did not treat requests to http://localhost and with equal merit. I must certainly try and add this scheme to the mix.

    [EricLaw] Security Zones have always treated "localhost" and differently– the former is zoned Intranet and the latter is zoned Internet. This isn't new to Windows 8.1. What you discovered is that in the original release of IE11, EPM was enabled in Desktop IE by default for the first time (previously, it was only enabled in Immersive IE or if the user manually enabled for desktop. In a later monthly update, the IE team backed off (for compatibility reasons) and reverted IE11 behavior to IE10 behavior (disabling EPM for Desktop IE by default).

    So, as to the question of why you were having problems with connecting– that's due to EPM's AppContainer's loopback restriction. In contrast, Localhost works because it is in the Intranet Zone, which runs outside of EPM by default.

  3. ^ Well, that was a great summary of my posts! I'm already feeling I wasted words and images. 😉 Not that I regret, for statistical reasons.

    But since localhost is resolved by the local resolver, I expected to be in Local Intranet zone as well. Hardcoded stuff like this have a way of being disappointing.

Comments are closed.

Skip to main content