{"id":1136,"date":"2011-03-29T18:15:26","date_gmt":"2011-03-29T22:15:26","guid":{"rendered":"http:\/\/cd34.com\/blog\/?p=1136"},"modified":"2011-03-29T18:15:26","modified_gmt":"2011-03-29T22:15:26","slug":"the-path-to-ipv6-from-a-webhosting-perspective","status":"publish","type":"post","link":"https:\/\/cd34.com\/blog\/infrastructure\/the-path-to-ipv6-from-a-webhosting-perspective\/","title":{"rendered":"The Path to IPv6 from a webhosting perspective"},"content":{"rendered":"

My goal in June 2010 was to be completely IPv4\/IPv6 dual stack by the end of 2010. This started a long, arduous process that required reworking portions of our network, upgrading the software on our border routers, increasing the memory on our border routers for the larger BGP table, removing a provider that refused to handle IPv6 in the data center we were located in, adding a separate provider so that we could have redundant IPv6 feeds and a number of other issues. In the last 7 days since we turned up IPv6 and started announcing two \/48s, We’ve gotten 25% of our network configured for IPv6 and expect to be able to transition the remaining 75% in the next 15 days.<\/p>\n

Of course, with IPv6 comes a new kernel as the existing kernel we’ve used didn’t have IPv6. 2.6.38 comes with Automatic Process Grouping<\/a> which in early testing has had a positive impact on several machines with different workloads. So, we have an additional reason to deploy kernels on every machine.<\/p>\n

Some of the issues we ran into:<\/p>\n

* Router
\n** Initial problem with IPv6 and the OS on the router
\n** Current minor issue with OSPF3
\n* Route Performance Control Box
\n** appears to ignore IPv6 traffic
\n* Aggregate Network
\n** OSPF3 support, altered network design to reflatten it (this from unflattening it a few years back)
\n* Nameservers
\n** Currently using bind9, no issues, switching to PowerDNS for other reasons
\n** Glue records at register required manual entry (webform didn’t accept : in an IP address)
\n* MX Servers
\n** Postfix, no issues, added inet_protocols=ipv4, ipv6, restarted
\n** Some anti-spam software that depended on IP addressing acts a little odd
\n** Antivirus daemon appears to only listen on IPv4 socket, but, since that is an internal milter, it doesn’t cause any real problems now.
\n** First 7 days, 247k emails processed, 2 from IPv6
\n* Webservers
\n* Load Balancers
\n** very odd issue with the new kernel, udev, and the SSD drives, not network\/ipv6 related
\n* Cluster
\n** No issues, GFS, DRBD, Apache, Dovecot, etc all recognized IPv6
\n* General Machine issues
\n** Firewall software on each machine requires separate rulesets for IPv6. Not a huge problem, but, one to consider.
\n* Client applications
\n** char(15) in mysql to store IP addresses
\n** parsing of Apache CLF doesn’t understand IP addresses<\/p>\n

One person that was testing with a Teredo tunnel wasn’t able to access the site via IPv6, but, was able to ping. After reading through a number of pages on the web:<\/p>\n

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\Dnscache\\Parameters<\/p>\n

and add a DWORD value:
\nAddrConfigControl = 0<\/code><\/p>\n

fixed the issue. For my home connection, I used TunnelBroker<\/a> along with the script mentioned on the page Enable IPv6 on Mac OS X, the tunnelbroker.net way<\/a>.<\/p>\n

After receiving this tweet<\/a>, I decided that running this site with a separate hostname for IPv6 was probably not a great test and put the AAAA records in DNS. So far, one person has mentioned that they had difficulties reaching the site, but, that was a problem with their ISP and transit. Their ISP appears to be blocking protocol 41 packets. Switching to a tunnel fixed that problem.<\/p>\n

All in all, most of the issues are very minor from a networking standpoint, but, web applications are going to have the most trouble.<\/p>\n

We’re working hard to make sure everything is dual-stack enabled by IPv6 Jump Day<\/a> (June 8, 2011) but I suspect it won’t be until 2020-2030 before we can deploy IPv6 only services.<\/p>\n

\n
<\/div>\n<\/fb:like>\n<\/div>
<\/div>","protected":false},"excerpt":{"rendered":"

My goal in June 2010 was to be completely IPv4\/IPv6 dual stack by the end of 2010. This started a long, arduous process that required reworking portions of our network, upgrading the software on our border routers, increasing the memory on our border routers for the larger BGP table, removing a provider that refused to […]<\/p>\n

\n
<\/div>\n<\/fb:like>\n<\/div>
<\/div>","protected":false},"author":15,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[167],"class_list":["post-1136","post","type-post","status-publish","format-standard","hentry","category-infrastructure","tag-ipv6"],"_links":{"self":[{"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/posts\/1136","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/comments?post=1136"}],"version-history":[{"count":1,"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/posts\/1136\/revisions"}],"predecessor-version":[{"id":1137,"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/posts\/1136\/revisions\/1137"}],"wp:attachment":[{"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/media?parent=1136"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/categories?post=1136"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cd34.com\/blog\/wp-json\/wp\/v2\/tags?post=1136"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}