Anyone who has been watching the technology industry for more than a couple of years quickly learns to recognize FUD: Fear, Uncertainty and Doubt. FUD is (apparently) widely believed to be an effective marketing technique, especially when it comes to security, privacy, or scarcity.

But the FUD often falls flat. Scarcity, in particular, is rare on the internet—even rarer than privacy or security. There’s constant FUD about scarcity of bandwidth, but the pipes get upgraded. Attempts to impose artificial scarcity through paywalls or other devices inevitably fail in the face of free alternatives. Even the scarcity of IPv4 addresses, which have indeed run out at the top, hasn’t affected end users at the bottom yet—and probably won’t, for a long time.

Saying that there aren’t any more IPv4 addresses is, quite simply, FUD. We all know it’s FUD because our computers can still connect to the internet. Repeating FUD simply dilutes the message, and often results in reporting which is just laughably wrong.

What’s actually happened is that ICANN, which assigns large ranges of IPv4 addresses to regional registries, has run out of ranges to assign. The regional registries, which in turn assign large blocks of IPv4 addresses to network providers in their region, have for the most part not run out—yet. But they will, eventually, and that’s forcing the network providers to be more cautious about assigning IPv4 ranges to their customers—including the access providers and hosting companies who in turn assign smaller ranges and individual IPs to mail, web, and other servers, and to end users.

What will have to happen between now and then is fairly clear.

First, services which rely on using multiple IP addresses to separate traffic will have to change their architecture. This includes many web hosting environments, because for a long time HTTPS required a separate IP address for each site—but that’s changed, it isn’t necessary any more. Multiple HTTPS sites can now share a single IP address.

It also includes ESPs, who tend to assign one or more IPv4 addresses to each customer that they send for in order to ensure that each has a distinct IP reputation, and to participate in Return Path Certification. But now, we’ve got domain reputation built on DKIM—you can have an effectively infinite number of different signing (d=) domains sent from a single IPv4 or IPv6 address. The big mailbox providers and MTA and filtering vendors have all been getting ready for this, but they can’t bring domain reputation to the forefront and deprioritize IPv4 reputation until the majority of legitimate, wanted mail is signed with DKIM. Similarly, Return Path can’t move our Certified program entirely to domains until both the senders and the receivers are ready for it—which is part of why we’re now requiring DKIM even for IP-based Certification. So, in effect, the ESPs and other large-scale senders have to switch to domains first.

(Many of us in the email industry expect that mail will continue to be transferred from system to system over IPv4 for the foreseeable future, but it’ll get tightened down over time.)

At the same time, customer premise equipment (CPE)—the routers and modems that connect end user networks to their access provider—need to be updated to use IPv6 correctly. Comcast, in particular, has been pushing CPE vendors to make this possible and running lots of tests. If you’re interested, we could cover this in a future article.

And finally, after all of that, we can start talking about deprovisioning the IPv4 addresses which are already out there in favor of moving everything to IPv6, rather than running both networks in parallel.

But, what will convince all of these companies—especially ESPs and hosting firms—to actually make this investment in their future? Maybe that’s where the FUD comes in—maybe they have to be scared into making the right decision. But I’d rather think that they’ll have the foresight to do it calmly, intelligently, all on their own—perhaps after this free training from MAAWG.

And if not, well…sometimes FUD comes true.

(This article was originally published on Return Path’s Received: blog.)