IPv6 deployment for hosting and developers

From Rixort Wiki
Jump to navigation Jump to search

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

Topics

  • What's the current state of play
  • Competition issues
  • What are some of the problems deploying v6
  • How to avoid the problems

Problems

  • Why is IPv6 deployment so slow? It has been around for 20+ years.
  • 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).
  • Harder to manage things like IP reputation and IP ACLs (where IPv4 limited address space is an advantage in many ways). Enabling v6 and using the wrong prefix = locked out of my Nextcloud instance.
  • 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). IPv6 only is not practical for a lot of use cases.
  • 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 (e.g. www.example.com CNAME host.myhost.com, add AAAA to host.myhost.com, www.example.com also gets AAAA)
  • To date has mostly been an ISP problem, e.g. no big hosting providers represented on the IPv6 Council organisation
  • Capturing IP address data and passing it on to third parties who might not have heard of v6

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.
  • Do we need regulation to force ISPs to deploy v6 (yes) - would allow v6-only hosting providers

Advice

Deployment in order:

  1. Setup monitoring for v6
  2. Add v6 addresses to interfaces
  3. Make services listen on v6
  4. Add DNS entries one at a time, check off each monitoring that goes red to green

Takeaways

  • Deploying IPv6 at the hosting end can be a lot of work
  • You will break something
  • 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=964’