Summary

  • Microsoft's Azure IPv6 documentation states, in its limitations section, that IPv6-only virtual machines and IPv6-only virtual machine scale sets are not supported, and that each network interface must include at least one IPv4 IP configuration.
  • The same documentation says public IPv6 addresses and prefixes carry no charge, while public IPv4 addresses carry a nominal charge.
  • The requirement binds at the network interface rather than at the workload, so it travels with every virtual machine and scale set in the documented path and scales with interface count, not with how much IPv6 an application speaks.
  • No Microsoft statement explaining the rationale, timeline or intended end state of the rule was located. This article declines to invent one.

The sentence that decides everything

In the limitations section of Microsoft's IPv6 overview for Azure Virtual Network, one sentence carries more weight than anything on the feature page: "IPv6-only Virtual Machines or Virtual Machines Scale Sets aren't supported. Each NIC must include at least one IPv4 IP configuration" (Azure Virtual Network IPv6 overview).

That is the argument in one line. Not a deprecation notice, not a roadmap slip, not a policy memo that leaked. A limitation, filed where limitations go, on the same page that explains how to add IPv6 to a virtual network.

The same page states that there is no charge to use public IPv6 addresses or public IPv6 prefixes, and that associated resources and bandwidth are charged at the same rates as IPv4. Azure's public IP address page repeats both halves of the arrangement: public IPv4 addresses have a nominal charge, public IPv6 addresses have no charge, and IPv6-only virtual machines and scale sets are not supported because each network interface must include at least one IPv4 IP configuration in a dual-stack setup (Azure public IP addresses).

Set the two statements side by side and the hierarchy becomes legible. The address family Microsoft gives away is the one it will not let a customer rely on alone. The address family it charges for is the one it will not let a customer drop. Nobody hid this. It is simply filed as a limit rather than as a decision.

What the documentation actually says

Scope matters here, because the honest version of this story is narrower than the inflammatory version.

Azure does not refuse IPv6. It offers dual-stack virtual networks, and it frames them as a way for Azure-hosted applications to reach both the existing IPv4 internet and new IPv6 devices and networks — as a way to work with IPv4 exhaustion rather than replace IPv4. Microsoft's Windows Server guidance on the transition takes the same posture: coexistence and transition mechanisms between the two families, not the abandonment of one (IPv6 transition technologies).

The prohibition is specific to the documented virtual machine and virtual machine scale set path. It is not a statement about every Azure service, and it is not a statement about Microsoft's network as a whole. Anyone reading it as proof that Azure is an IPv4-only platform has overreached. So has anyone reading it as evidence that Microsoft has no IPv6 address ranges.

The defensible claim is narrower and more useful: in the documented compute path, IPv6 is offered as an addition. It is never offered as a substitute. Azure supports IPv6; it does not support IPv6 instead.

Why the network interface is the load-bearing detail

The rule is written at the level of the network interface. Not the subscription. Not the workload. Not the application. That choice of layer is what gives the constraint its reach.

A constraint written at the application layer would be a statement about what software speaks. A constraint written at the interface is a statement about what a deployment must be built out of. Every virtual machine gets at least one network interface, so every virtual machine inherits the requirement, whatever the software stack above it happens to do. A deployment that provisions a hundred interfaces carries the requirement a hundred times over, without a single line of application code changing.

The interface is also the exact layer where a customer asks the platform for addresses. That is the point in the request path where an address family stops being a matter of taste and becomes a matter of what the platform will allocate. Put the requirement there and it travels with the deployment for as long as the deployment exists, through rescaling, redeployment and redeployment again.

There is a second-order effect worth stating precisely, because loose versions of it circulate widely. Whether the required IPv4 configuration must be public, private, shared or translated is not something the documentation establishes, and this article does not assert it. The rule therefore says nothing about how many scarce public IPv4 addresses any given workload consumes. What it says is that the deployment cannot truthfully be described as IPv6-only, and that Azure's own provisioning path will not let an operator construct one anyway.

That is a power relationship expressed as a schema detail, and it is a good deal more consequential than a pricing page.

Free IPv6, charged IPv4, and a price signal that goes nowhere

Azure prices the two families in opposite directions. Public IPv6 addresses and prefixes: no charge. Public IPv4 addresses: a nominal charge (Azure public IP addresses).

Taken alone, that is a price signal aimed at IPv6. Price signals are supposed to move behaviour; that is the entire theory behind them. This one collides with a configuration rule that mandates the other family, and the collision produces something odder than a contradiction. The commercial signal and the technical requirement do not cancel each other out. They do not reinforce each other either. They run on parallel tracks and never meet.

A customer trying to cut cost is told, accurately, that IPv6 is free. A customer who tries to act on that discovers the free family cannot be the only one present on the interface. The saving is real but bounded: it applies to the IPv6 side of the configuration, and the IPv4 side stays exactly where it was.

This is not hypocrisy, and it is not evidence of a hidden agenda. It is an ordering. The price signal is a commercial preference. The interface rule is a technical requirement enforced at provisioning time. When the two disagree, the requirement wins, because the requirement is the one the gate checks. A free address family sitting next to a mandatory one is not a contradiction in Microsoft's accounting; it is a description of which decision the platform actually enforces.

The published record is not the network

Microsoft publishes a downloadable file of Azure IP ranges and service tags for customers who need machine-readable data about the address space Azure services use (Azure IP ranges and service tags).

The existence and stated purpose of that file are established facts. Its current schema version, its prefix-family coverage and its publication cadence were not read as text in this research, so this article makes no claim that it omits IPv6 prefixes, and no claim about how quickly it is refreshed.

That caution is the point, not an evasion. The tempting move — and it is everywhere in commentary about cloud networking — is to treat a machine-readable range file as a mirror held up to the network. It is not a mirror. It is a publication artifact, with a scope someone chose and a schedule someone keeps. The same is true of service tags, which are a naming layer over address sets rather than a live route table.

Which leads to the general rule that governs this whole subject. Registry records, published range files and enforced platform requirements are three different artifacts, produced by three different processes, on three different clocks. When they disagree, the first question is not which one is lying. It is which one covers what, and when each was last written.

What the registry record can and cannot tell you

The ARIN RDAP organisation record under the handle MSFT is the registry endpoint for Microsoft Corporation's organisation registration and its linked internet number resources (ARIN RDAP entity MSFT).

That establishes identity. It does not establish a total. The record body and its complete linked-resource set were not read as text during this research, so no holdings figure, prefix list or inventory is derived here — and readers should treat any dramatic Microsoft IPv4 total, presented without the underlying record, as a claim in search of evidence rather than a fact in hand.

What the registry does establish clearly is the machinery. ARIN maintains a public IPv4 transfer framework and registry trail through which registered address space moves between organisations, including transfers recorded after the central IPv4 pool was depleted (ARIN IPv4 transfer policy). Address space is transferable, registerable and traceable. That is the market's structure. What any single company holds inside that structure is a separate question requiring a separate reading.

The 2011 Nortel purchase, and why it is not the explanation

In April 2011, reporting carried by BBC News and Ars Technica described Microsoft acquiring 666,624 IPv4 addresses from Nortel in a transaction valued at about $7.5 million, inside Nortel's bankruptcy-related asset disposition (BBC News; Ars Technica).

The arithmetic that follows — roughly $11.25 per address — is arithmetic performed on reported figures. It is not an ARIN-set price, and it should never be quoted as one. The reporting is also reporting: neither article body was read as text in this research, and the address count and the price both come from the reported account and the Ars Technica headline rather than from a registry or court record.

This is where the transaction belongs: as historical context for the market value of address space in 2011, when a company planning for cloud growth was willing to pay for a large block. It is not evidence about the current Azure interface rule, and it is emphatically not a motive. A 2011 acquisition offered as the reason for a 2020s configuration requirement is a story with a satisfying shape and nothing behind it. The purchase explains what address space was worth. It does not explain what Azure's provisioning gate enforces today.

Where the migration actually stands

Stated as plainly as the documentation allows: Azure supports IPv6, supports dual-stack, does not support IPv6-only virtual machines or scale sets, and requires at least one IPv4 configuration on every network interface in that path. Public IPv6 addresses and prefixes are free. Public IPv4 addresses are charged. Microsoft's transition guidance describes coexistence, not replacement.

The most useful thing about that list is that it is incomplete, and that Microsoft published the incompleteness. The limitations section is where a platform puts what it cannot yet do; the fact that this one is written in a single blunt sentence suggests an engineering organisation that knows exactly where its boundary is and has no interest in dressing it up.

Incomplete is not the same as temporary, and the difference matters for anyone making a five-year plan. No date, no milestone and no end state were located that would allow a reasonable person to say when the IPv4-on-every-interface requirement might be lifted. Calling it transitional would be an invention, and an expensive one for anybody who sizes a network around it.

What the record also does not contain is a reason. No Microsoft statement explaining the rationale, timeline or intended end state of the rule turned up in this research. The motive is unknown. The rule is convenient for a company that holds a great deal of IPv4, and convenience is not evidence that convenience is why the rule exists. A compatibility guarantee for services still assuming IPv4, a support cost that has not yet been retired, a deliberate choice about how migrations should be sequenced — all of these fit the published sentence equally well, and none of them can be confirmed from it.

Anyone who wants the underlying context on Microsoft's network-resource position, rather than the argument about it, can start with the BTW directory entry for Microsoft Corporation.

What would change this reading

Three things.

A Microsoft statement of rationale. If the interface requirement exists to guarantee compatibility for services that still assume IPv4, that is a different article, and a more sympathetic one. If it reflects a commercial judgement about the value of address space, that is also a different article. Either would be worth publishing the moment it exists.

A dated plan. If IPv6-only virtual machines and scale sets appear on a published roadmap with a milestone attached, the constraint stops being a boundary and becomes a schedule. Nothing in the current documentation supplies that.

A measurement. If someone demonstrates that Azure's published range data and observed network state diverge by more than the stated publication windows can explain, that is a testing question with a testing answer. No BGP, endpoint or customer measurement was performed for this article, so no such finding is claimed here.

Until one of those arrives, the honest reading is the one the documentation itself supports. The hierarchy is public: free IPv6, charged IPv4, and a mandatory IPv4 configuration on every interface in the documented compute path. The reasoning behind it is not public, and the gap between those two facts is where an entire industry's IPv6 migration currently lives — announced at the top of the page, constrained in its footnotes, priced on a different page entirely.