IPv6 deployment for hosting and developers: Difference between revisions

From Rixort Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Line 29: Line 29:
* Getting v6 addresses is a faff compared to v4
* 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)
* 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)
* DNS - if someone has a CNAME which points at one of your hostnames and you add AAAA records to that hostname, all the CNAMEs get it too


== Competition concerns ==
== Competition concerns ==

Revision as of 11:28, 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 stopped working, so did automatic deployments, SSH wouldn't listen on v6 because of firewall, add AddressFamily inet to .ssh/config
  • 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 use listen 80 and listen [::]: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, combined with a risk of breaking things.
  • 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)
  • DNS - if someone has a CNAME which points at one of your hostnames and you add AAAA records to that hostname, all the CNAMEs get it too

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
  • Deploy gradually and in the right order (everything else before DNS)
  • Forget starting a hosting provider
  • 'Buy IPv4 addresses, they're not making them anymore'

Links

Retrieved from ‘https://wiki.rixort.com/index.php?title=IPv6_deployment_for_hosting_and_developers&oldid=949’