IPv4 is an ex­pen­sive re­source. How­ever, many con­tent providers are still IPv4-only. The most com­mon rea­son is that IPv4 is here to stay and IPv6 is an ad­di­tional com­plex­ity.¹ This mind­set may seem self­ish, but there are com­pelling rea­sons for a con­tent provider to en­able IPv6, even when they have enough IPv4 ad­dresses avail­able for their needs.

Why do ISPs need IPv6?#

Pro­vid­ing a pub­lic IPv4 ad­dress to each cus­tomer is quite costly when each IP ad­dress costs US$40 on the mar­ket. For fixed ac­cess, some con­sumer ISPs are still pro­vid­ing one IPv4 ad­dress per cus­tomer.² Other ISPs pro­vide, by de­fault, an IPv4 ad­dress shared among sev­eral cus­tomers. For mo­bile ac­cess, most ISPs dis­trib­ute a shared IPv4 address.

There are sev­eral meth­ods to share an IPv4 address:³

NAT44

The cus­tomer de­vice is given a pri­vate IPv4 ad­dress, which is trans­lated to a pub­lic one by a ser­vice provider de­vice. This de­vice needs to main­tain a state for each translation.

464XLAT and DS-Lite

The cus­tomer de­vice trans­lates the pri­vate IPv4 ad­dress to an IPv6 ad­dress or en­cap­su­lates IPv4 traf­fic in IPv6 pack­ets. The provider de­vice then trans­lates the IPv6 ad­dress to a pub­lic IPv4 ad­dress. It needs to main­tain a state for the NAT64 trans­la­tion. For 464XLAT, adding DNS64 to the mix re­moves the need for state­less NAT46 in most cases.

Light­weight IPv4 over IPv6, MAP-E, and MAP-T

The cus­tomer de­vice en­cap­su­lates IPv4 in IPv6 pack­ets or per­forms a state­less NAT46 trans­la­tion. The provider de­vice uses a bind­ing ta­ble or an al­go­rith­mic rule to map IPv6 tun­nels to IPv4 ad­dresses and ports. It does not need to main­tain a state.

All these so­lu­tions re­quire a trans­la­tion de­vice in the ISP’s net­work. This de­vice rep­re­sents a non-neg­li­gi­ble cost in terms of money and re­li­a­bil­ity. As half of the top 1000 web­sites sup­port IPv6 and the big­gest play­ers can de­liver most of their traf­fic us­ing IPv6,⁴ ISPs have a clear path to re­duce the cost of trans­la­tion de­vices: pro­vide IPv6 by de­fault to their customers.

Why do content providers need IPv6?#

Con­tent providers should ex­pose their ser­vices over IPv6 pri­mar­ily to avoid go­ing through the ISP’s trans­la­tion de­vices. This does not help users who do not have IPv6 or users with a non-shared IPv4 ad­dress, but it pro­vides a bet­ter ser­vice for all the others.

Why would the ser­vice be bet­ter de­liv­ered over IPv6 than over IPv4 when a trans­la­tion de­vice is in the path? There are two main rea­sons for that:⁵

1. Trans­la­tion de­vices in­tro­duce ad­di­tional la­tency due to their ge­o­graph­i­cal place­ment in­side the net­work: it is eas­ier and cheaper to only in­stall these de­vices at a few points in the net­work in­stead of putting them close to the users.

2. Trans­la­tion de­vices are an ad­di­tional point of fail­ure in the path be­tween the user and the con­tent. They can be­come over­loaded or mal­func­tion. More­over, as they are not used for the five most vis­ited web­sites, which serve their traf­fic over IPv6, the ISPs may not be in­cen­tivized to en­sure they per­form as well as the na­tive IPv6 path.⁶

Look­ing at Google sta­tis­tics, half of the users reach Google over IPv6. More­over, their la­tency is lower.⁷ In the US, all the na­tion­wide mo­bile providers have IPv6 enabled.

For France, we can re­fer to the an­nual ARCEP re­port: in 2022, 72% of fixed users and 60% of mo­bile users had IPv6 en­abled, with pro­jec­tions of 94% and 88% for 2025. Start­ing from this pro­jec­tion, since all mo­bile users go through a net­work trans­la­tion de­vice, con­tent providers can de­liver a bet­ter ser­vice for 88% of them by ex­pos­ing their ser­vices over IPv6. If we ex­clude Or­ange, which has 40% of the mar­ket share on con­sumer fixed ac­cess, en­abling IPv6 should pos­i­tively im­pact more than 55% of fixed ac­cess users.

---

In con­clu­sion, con­tent providers aim­ing for the best user ex­pe­ri­ence should ex­pose their ser­vices over IPv6. By avoid­ing trans­la­tion de­vices, they can en­sure fast and re­li­able con­tent de­liv­ery. This is cru­cial for la­tency-sen­si­tive ap­pli­ca­tions, like live stream­ing, but also for web­sites in com­pet­i­tive mar­kets, where even slight de­lays can lead to user dis­en­gagement.