Yes, we have no IP addresses, we have no addresses today

We’ve just about run out of the Internet equivalent of a natural resource – IP addresses.

ICANN allocated the last couple of blocks of general usage IPv4 addresses to APNIC earlier today.
There are just five usable blocks of addresses left, and they’re reserved by IANA policy for the final phase of IPv4 exhaustion, one for each RIR.
Like any other resource that’s been strip-mined to depletion that doesn’t mean that IP addresses are completely unavailable – there are still some in the delivery pipeline (the regional internet registries who handle allocation of addresses), ISPs have stockpiled addresses they don’t really need yet in anticipation of the exhaustion, and we can still recycle the addresses we’ve already got.
But there won’t be any new IPv4 addresses available.
What does that mean to you?
It’s going to affect your business in lots of ways over the next few years. And delaying thinking about it will just make it more expensive and more painful once you’re forced to pay attention.

IPv4 addresses are increasing in price
You’re going to find it increasingly difficult to get assigned new ones. It’s long past time to stop thinking of them as “effectively free”.
You’re going to need IPv6 production deployments fairly soon, and we’re well past the point of “it’s cheaper to wait, so that our vendors can do the IPv6 work that’s needed”. Delaying putting IPv6 prototypes into the field is going to get increasingly painful and expensive.
If your CTO and CFO are not concerned about this yet, they should be.
Stop wasting addresses
Dedicating even a single IP address to a customer is wasteful, if you don’t need that to handle the volume of email sent. You should be signing all your mail with DKIM today and building domain based reputation for your customers, as IPv4 based per-customer reputation is going away.
As you grow and gain more customers you’re going to have to start sharing v4 addresses between customers, which will share their IPv4-based reputation.
And fairly soon, you’ll want to start sending mail over IPv6 to some destinations. Odds are good that per-customer IPv6 reputation isn’t going to happen much. There’ll be some broad IPv6 based reputation to distinguish your outbounds from spammers and botnets, sure, but IPv6 based reputation down to a per-customer level isn’t something you’re likely to see much benefit from.
Assigning multiple IPv4 addresses to a single customer is ridiculously wasteful. You’re going to want to engineer away from any need to do that – and have your sales staff stop promising it – so that you can recycle those precious, precious IPv4 addresses for use elsewhere by other customers.
Your recipients are moving to IPv6
Big consumer access ISPs are some of the biggest consumers of IP addresses. They’re likely going to be moving to native IPv6 for end-users, combined with some sort of v6-to-v4 translation before anyone else.
That means that your web users, from home and mobile devices, will be trying to reach you via IPv6 sooner rather than later. Native v6 will mostly work better than v6-to-v4. So you want to be thinking about v6 access soon.
Have you got v6 space assigned from your ISP(s) yet? No? Ask them for it this week.
Do you have plans for making your image and click-tracking webservers v6-aware?
Everything you do with IPv4 you need to be able to do with IPv6
Does your address list management support tracking signups and confirmations from IPv6 users as well as IPv4?
Can you track opens and click throughs from IPv6 users?
How about reporting? Does your database and reporting engine support IPv6 addresses? Can you do geolocation for IPv6 addresses?
Does your smarthost vendor support preferentially routing mail via IPv6?
IPv6 is an opportunity
What would you do if someone were to offer you dedicated MX machines at Yahoo, Google and Hotmail. Machines that were much the same as their primary MXes, but lightly loaded with much more available capacity. How much would you be prepared to pay for access to them?
Sooner or later there’ll be IPv6-only MXes at those, and other ISPs. Will you be ready to use them?
Do your competitors offer an IPv6-ready system yet? How much of a business disadvantage will you be at once they do?
And finally
None of this is new. You’ve known for years that you need to be more frugal with IPv4 addresses and have dual-stack IPv6-capable services.
But it’s getting urgent.

Related Posts

The view from a blacklist operator

We run top-level DNS servers for several blacklists including the CBL, the blacklist of infected machines that the SpamHaus XBL is based on. We don’t run the CBL blacklist itself (so we aren’t the right people to contact about a CBL listing) we just run some of the DNS servers – but that means that we do get to see how many different ways people mess up their spam filter configurations.
This is what a valid CBL query looks like:

Read More

I want to avoid network outages

Number six of seven in our occasional series on why ESPs need, or don’t need, lots of IP addresses to send mail properly.

Read More

How to disable a domain

Sometimes you might want to make it clear that a domain isn’t valid for email.
Perhaps it’s a domain or subdomain that’s just used for infrastructure, perhaps it’s a brand-specific domain you’re only using for a website. Or perhaps you’re a target for phishing and you’ve acquired some lookalike domains, either pre-emptively or after enforcement action against a phisher, and you want to make clear that the domain isn’t legitimate for email.
There are several things to check before disabling email.
1. Are you receiving email at the domain? Is anyone else?
Check the MX records for the domain, using “host -t mx example.com” from a unix commandline, or using an online DNS tool such as xnnd.com.
If they’re pointing at a mailserver you control, check to see where that mail goes. Has anything been sent there recently?
If they’re pointing at a mailserver that isn’t yours, try and find out why.
If there are no MX records, but there is an A record for the domain then mail will be delivered there instead. Check whether that machine receives email for the domain and, if so, what it does with it.
Try sending mail to postmaster@ the domain, for instance postmaster@example.com. If you don’t get a bounce within a few minutes then that mail may be being delivered somewhere.
2. Are you sending email from the domain? Is anyone else?
You’re more likely to know whether you’re sending mail using the domain, but there’s a special case that many people forget. If there’s a server that has as it’s hostname the domain you’re trying to shut down then any system software running no that server – monitoring software, security alerts, output from cron and so on – is probably using that hostname to send mail. If so, fix that before you go any further.
3. Will you need mail sent to that domain for retrieving passwords?
If there are any services that might have been set up using an email address at the domain then you might need a working email address there to retrieve lost passwords. Having to set email back up for the domain in the future to recover a password is time consuming and annoying.
The domain registration for the domain itself is a common case, but if there’s any dns or web hosting being used for the domain, check the contact information being used there.
4. How will people contact you about the domain?
Even if you’re not using the domain for email it’s quite possible that someone may need to contact you about the domain, and odds are good they’ll want to use email. Make sure that the domain registration includes valid contact information that identifies you as the owner and allows people to contact you easily.
If you’re hosting web content using the domain, make sure there’s some way to contact you listed there. If you’re not, consider putting a minimal webpage there explaining the ownership, with a link to your main corporate website.
5. Disabling email
The easiest way to disable email for a domain is to add three DNS records for the domain. In bind format, they look like:

Read More