IP addresses, and why there are two kinds

Every device that talks to the internet needs an address, and for decades that meant IPv4: four numbers between 0 and 255, such as 203.0.113.25. That format allows about 4.3 billion addresses. It sounded like plenty in the 1980s. It ran out as a free resource years ago, which is why you now see address blocks being bought and sold like property.

IPv6 is the fix. Its addresses are 128 bits long and written in hexadecimal, like 2001:db8::25, which allows a number of addresses so large that nobody bothers to say it aloud. The two systems run side by side. A server can answer on both, and a visitor's device picks whichever it can use, usually preferring IPv6 when both work.

For someone running a website, the practical questions are narrower than the history. Does my site answer on both kinds? Why does my computer show an address that nothing on the internet recognises? Do I need a dedicated IP? This article goes through each, with the commands to check your own setup.

How the two formats differ

An IPv4 address is 32 bits, written as four decimal numbers separated by dots. An IPv6 address is 128 bits, written as eight groups of four hexadecimal digits separated by colons. Because that is unwieldy, there are two shortening rules: leading zeros in a group can be dropped, and one run of all-zero groups can be replaced by a double colon.

The double colon can appear only once in an address, otherwise nobody could tell how many zero groups each one stood for. In a URL, an IPv6 address goes in square brackets: https://[2001:db8::25]/.

Why a site owner should care

Two reasons. First, a good share of mobile networks and some home providers now use IPv6 by default, so a site that only answers on IPv4 is working a bit harder for those visitors. Their traffic may pass through translation equipment on the way, which adds a little delay and one more thing that can go wrong. It will usually still load, just not as directly as it could.

Second, if your DNS has an AAAA record (the IPv6 kind) pointing somewhere that does not actually serve your site, some visitors will see errors while everyone else sees nothing wrong. That one catches people out after a migration. The old server's IPv6 address stays in DNS, the new server only has an IPv4 address, and visitors on IPv6-capable networks are sent to the wrong machine. Devices try the faster-looking path first, so the fault is intermittent and hard to reproduce from the office, where the network may be IPv4 only.

A worked example: the half-migrated site

A small design studio moves its site to a new host. DNS is updated: the A record now points at 203.0.113.50. Nobody notices the AAAA record still pointing at 2001:db8:old::10, an address that now belongs to a machine nobody pays for. The studio's staff, on an IPv4-only office network, see the new site. Two clients on a mobile network report that the site "doesn't load, sometimes".

The diagnosis takes a minute once you ask for both record types:

dig +short example.com A
203.0.113.50

dig +short example.com AAAA
2001:db8:old::10

curl -6 -I https://example.com/
curl: (7) Failed to connect to example.com port 443

The AAAA record answers, the connection fails, and that matches the reports. Removing the stale record (or adding a working IPv6 address on the new server) fixes it, once the old record's TTL has expired. The TTL planner helps work out how long that wait will be.

Private addresses

Addresses beginning 10., 192.168. or 172.16 to 172.31 are reserved for internal networks. Your home router hands them out, and the whole house shares one public address through a trick called NAT, network address translation. The router rewrites outgoing traffic so it appears to come from the public address, and keeps a table to send replies to the right device.

If a tool tells you your computer's address is 192.168.1.20, that is no use to a server on the internet. You need your public address, which any "what is my IP" page will show, or this from a terminal:

curl -4 https://ifconfig.example/
curl -6 https://ifconfig.example/

(Substitute any address-echo service you trust.) The two commands may return quite different things, or the second may fail, which just means your network has no IPv6.

A few other special ranges turn up in support conversations. 127.0.0.1 is the machine itself ("localhost"). Addresses starting 169.254. are self-assigned when a device cannot get one from a router, so seeing one usually means something is wrong with the local network. Some mobile and home providers go further and share one public address among many customers, using carrier-grade NAT, with addresses from 100.64.0.0 to 100.127.255.255 inside their network. That is why allow-listing "my home IP" is sometimes unreliable.

Shared and dedicated addresses

On shared hosting, many sites can sit behind one address and the server decides which site to show by reading the hostname in the request. For HTTP that is the Host header; for HTTPS the browser sends the name during the handshake, in a field called SNI, so the right certificate can be chosen.

A dedicated IP gives your account its own address. It helps if you need to allow-list the address in someone else's firewall, or if you run your own mail server and want an isolated reputation, since mail receivers judge senders partly by the address they come from. It also lets you set a reverse DNS (PTR) record that matches your mail hostname, which many receivers check.

It is not needed for HTTPS, which surprises people. Modern browsers and servers all support SNI, so certificates work fine on shared addresses. Paying for a dedicated address "for the padlock" is a leftover from around 2010. See what the padlock actually tells you for the other half of that story.

Allow-listing and its traps

The commonest reason people ask for a dedicated address is allow-listing: a payment provider, a database host or a partner's firewall will only accept connections from a named address. The idea is sound, but it fails in predictable ways.

• The address you give is your office or home address, which changes when the provider reassigns it, or is shared with other customers behind carrier-grade NAT.
• The address you give is the web server's, but outgoing connections leave from a different address, because the server has several or sits behind a gateway. Check the address that actually appears at the other end, not the one on the invoice.
• Only the IPv4 address is listed, and the connection arrives over IPv6, or the reverse. A rule has to cover whichever your server uses to connect out.
• A move to a new host or plan changes the address and nobody remembers the allow-list exists.

For outgoing connections, ask the server what it looks like from outside: curl -4 https://ifconfig.example/ run on the server itself gives the address the other party will see. Write that address, the date and the reason in a note, so that the next migration includes a step for updating every list it appears on.

Addresses in your logs

Your access log records the address of whoever connected. Behind a CDN, load balancer or proxy, that address is the proxy's, and the real visitor is carried in a header, usually X-Forwarded-For or a provider-specific equivalent. If every line in your log shows the same few addresses, or a security plugin blocks "an attacker" that turns out to be your own proxy, the real client address is not being read. The fix is a server or plugin setting that trusts the header, but only from known proxy addresses; trusting it from anywhere lets anyone claim to be any address.

IPv6 adds one quirk to log reading. Home connections are usually given a whole block, commonly a /64, so one household can appear to come from many addresses that differ only in the final part, because devices rotate temporary addresses for privacy. Rate limits and blocklists that treat each address as a separate visitor will miss this, which is why good ones work on the block rather than the single address.

Reverse DNS and mail

Normal DNS turns a name into an address. Reverse DNS goes the other way: a PTR record says which name an address belongs to. For web browsing nobody cares. For mail, receiving servers often check that the sending address has a PTR record, and that the name it gives leads back to the same address. A missing or generic one (a long string of numbers from the provider's default) pushes messages towards spam folders.

dig -x 203.0.113.25 +short
mail.example.com.

dig +short mail.example.com A
203.0.113.25

The pair should agree. The PTR is set by whoever owns the address block, which is your host, not in your own DNS zone; open a ticket or use the panel option for it. The SPF builder covers the other half of sender identity, where the list of permitted sending addresses lives in a DNS record.

Switching IPv6 on for your own site

On shared or managed hosting this is usually a matter of checking if the account has an IPv6 address and adding it as an AAAA record next to the existing A record. On a VPS you do three things: confirm the provider has given the server an IPv6 address, make the web server listen on it, and open the same ports in the firewall for both families. In nginx that means a second listen line.

listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

Apache listens on both by default when no address is given. Add the AAAA record last, after curl -6 against the server's own address works, since DNS is the step that sends visitors to it. Give the record a short TTL while testing and lengthen it afterwards. If anything misbehaves, deleting the AAAA record puts things back within one TTL.

What changes between hosting types

On shared hosting the provider assigns the address, you rarely choose it, and moving between servers changes it, so keep DNS records under your own control. On a VPS you typically get one IPv4 address and often a block of IPv6 addresses (a /64 is common), and you configure the server to listen on both. On dedicated servers the same applies, with more addresses available on request. On managed plans, the platform may sit behind a proxy, so the address your visitors see is the proxy's, not the server's, and your logs may record the proxy unless the real client address is passed on in a header.

Commands worth running

1. Run dig +short example.com A and dig +short example.com AAAA, then repeat for www.example.com. Every address listed should be one you recognise.
2. Test each protocol: curl -4 -I https://example.com/ and curl -6 -I https://example.com/.
3. If you send mail, run dig -x 203.0.113.25 +short to see the reverse record.
4. Compare answers from a mobile connection, which is often IPv6-first, as well as your office.

The DNS cheat sheet lists the record types, and the glossary covers the terms used here.