IPv6 deployment for hosting and developers: Difference between revisions
Jump to navigation
Jump to search
Line 15: | Line 15: | ||
* Why is IPv6 deployment so slow? | * Why is IPv6 deployment so slow? | ||
* Adding AAAA records 'breaks' SSH | * Adding AAAA records 'breaks' SSH (interactive and automatic deployments) | ||
* Mail over IPv6 without SPF and DKIM stops delivery to large mail providers (e.g. Google). | * Mail over IPv6 without SPF and DKIM stops delivery to large mail providers (e.g. Google). | ||
* Apache <code>VirtualHost *:80</code> includes v4 and v6, whereas nginx requires you to use <code>listen 80</code> and <code>listen [::]:80</code> | * Apache <code>VirtualHost *:80</code> includes v4 and v6, whereas nginx requires you to use <code>listen 80</code> and <code>listen [::]:80</code> |
Revision as of 11:21, 19 September 2020
Talk on the implications of deploying IPv6 for hosting platforms and developers.
Rough notes
- Stats on incoming traffic from hosting providers
- Stats on outgoing traffic from ISPs(?)
- Percentage of sites running IPv6
- Percentage of other services running IPv6
- Example: Russell Group universities with AAAA for their main website.
- Some very big news sites
- BBC iPlayer?
- Netflix
Problems
- Why is IPv6 deployment so slow?
- Adding AAAA records 'breaks' SSH (interactive and automatic deployments)
- Mail over IPv6 without SPF and DKIM stops delivery to large mail providers (e.g. Google).
- Apache
VirtualHost *:80
includes v4 and v6, whereas nginx requires you to uselisten 80
andlisten [::]:80
- If multiple protocols are available, which should be preferred? Linux seems to go for IPv6 first, but any which prefer IPv4 will never see the v6 service.
- What is the benefit for hosting platform customers?
- What is the incentive for incumbent providers?
- IPv6 deployment can and does break things.
- Benefits are vague and in future.
- IPv6 is like PHP 7 - yes you should do it but there's limited immediate quantifiable benefit to the customer.
- IPv4 works. The only problem is a lack of addresses, but you can hack around that, and it doesn't matter to incumbents.
- Double the number of connectivity tests to run and services to monitor (assuming dual-stack).
- Firewall solutions and edge routers might not support it - expensive to replace
- Getting v6 addresses is a faff compared to v4
- More customer co-operation required (c.f. ISP where you can often switch it on silently, especially if you manage their equipment or can push out updates)
Competition concerns
- RIPE 733: "The size of the allocation made will be exactly one /24.", "The sum of all allocations made to a single LIR by the RIPE NCC is limited to a maximum of 256 IPv4 addresses (a single /24). If this allocation limit has been reached or exceeded, an LIR cannot request an IPv4 allocation under this policy."
- Who regulates RIPE et al? They have power to allocate a scarce and valuable resource.
Takeaways
- Deploying IPv6 at the hosting end can be a lot of work
- But you should still do it
- Forget starting a hosting provider
- 'Buy IPv4 addresses, they're not making them anymore'
Links
- Netweaver: IPv6 use in 2019
- Mythic Beasts IPv6 health check - phpdeveloper.org.uk gets 11/11