IPv6 deployment for hosting and developers: Difference between revisions

From Rixort Wiki
Jump to navigation Jump to search
No edit summary
 
(20 intermediate revisions by the same user not shown)
Line 11: Line 11:
* BBC iPlayer?
* BBC iPlayer?
* [https://blog.apnic.net/2020/08/26/netflix-over-ipv6-a-longitudinal-study/ Netflix]
* [https://blog.apnic.net/2020/08/26/netflix-over-ipv6-a-longitudinal-study/ Netflix]
* Digital Ocean - IPv6 but not on load balancers?
* Big CDNs?
== Topics ==
* What's the current state of play
* Competition issues
* What are some of the problems deploying v6
* How to avoid the problems


== Problems ==
== Problems ==


* Why is IPv6 deployment so slow?
* Why is IPv6 deployment so slow? It has been around for 20+ years.
* Adding AAAA records 'breaks' SSH.
* Adding AAAA records 'breaks' SSH - interactive stopped working, so did automatic deployments, SSH wouldn't listen on v6 because of firewall, add <code>AddressFamily inet</code> to <code>.ssh/config</code>
* 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).
* 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 <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>
* 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.
* 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.
Line 23: Line 33:
* IPv6 deployment can and does break things.
* IPv6 deployment can and does break things.
* Benefits are vague and in future.
* 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.
* 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.
* 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).
* 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
* Firewall solutions and edge routers might not support it - expensive to replace
* 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 (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 ==
== Competition concerns ==
Line 34: Line 47:
* [https://www.ripe.net/publications/docs/ripe-733 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."
* [https://www.ripe.net/publications/docs/ripe-733 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.
* 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:
# Setup monitoring for v6
# Add v6 addresses to interfaces
# Make services listen on v6
# Add DNS entries one at a time, check off each monitoring that goes red to green


== Takeaways ==
== Takeaways ==


* Deploying IPv6 at the hosting end can be a lot of work
* Deploying IPv6 at the hosting end can be a lot of work
* You will break something
* But you should still do it
* But you should still do it
* Deploy gradually and in the right order (everything else before DNS)
* Forget starting a hosting provider
* Forget starting a hosting provider
* 'Buy IPv4 addresses, they're not making them anymore'
* 'Buy IPv4 addresses, they're not making them anymore'
Line 46: Line 71:
* [https://www.netweaver.uk/ipv6-use-2019/ Netweaver: IPv6 use in 2019]
* [https://www.netweaver.uk/ipv6-use-2019/ Netweaver: IPv6 use in 2019]
* [https://www.mythic-beasts.com/ipv6/health-check Mythic Beasts IPv6 health check] - phpdeveloper.org.uk gets 11/11
* [https://www.mythic-beasts.com/ipv6/health-check Mythic Beasts IPv6 health check] - phpdeveloper.org.uk gets 11/11
* [https://www.youtube.com/watch?v=91hN3PvYUrc UKNOF34 - IPv6 Only Hosting]
* [https://www.youtube.com/watch?v=-qbTWlG5VI4 UKNOF36 - Single Stack IPv6 Hosting for the masses]
* [https://www.youtube.com/watch?v=GK6vl5z-8NY UKNOF43 - Psychology of IPv6]
* [https://www.youtube.com/watch?v=ZJhIeiWx1xg UKNOF36 - IPv6-only Hosting Panel Discussion]
* [https://tv.theiet.org/?videoid=9485 BBC IPv6 update]


[[Category:Talks]]
[[Category:Talks]]

Latest revision as of 13:32, 26 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
  • Digital Ocean - IPv6 but not on load balancers?
  • Big CDNs?

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