<?xml version="1.0" encoding="utf-8" ?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Fun with ones and zeros - ipv6</title>
<subtitle>Barry&#039;s notes on computer software and hardware</subtitle>
<link href="/blog/tags/ipv6"></link>
<updated>2026-05-08T21:49:06-07:00</updated>
<id>urn:uuid:9a385411-b595-78cb-c994-a2ff89d6ec5a</id>
<entry>
<title>IPv6 World Launch Day</title>
<link href="/blog/entries/ipv6-world-launch-day"></link>
<id>urn:uuid:5e0fcd22-cd65-97c3-767f-741c960041e9</id>
<updated>2012-04-08T15:36:00-07:00</updated>
<author><name>Barry Pederson</name>
<email>bp@barryp.org</email>
</author>
<content type="html">&lt;img src=&quot;/assets/7/18/World_IPv6_launch_banner_256.png&quot; alt=&quot;IPv6 Logo&quot; style=&quot;float:left; margin-right: 2em;&quot; width=&quot;106&quot; height=&quot;226&quot;/&gt;
&lt;p&gt;I&#039;ve been working on getting this website up and running under IPv6, and it turned out to be somewhat involved.
Firstly, I signed up with Hurricane Electric&#039;s &lt;a href=&quot;http://tunnelbroker.net&quot;&gt;tunnelbroker.net&lt;/a&gt;, to get IPv6 connectivity, because my ISP
doesn&#039;t offer it yet.  Setup my own DNS servers running &lt;a href=&quot;http://www.nlnetlabs.nl/projects/nsd/&quot;&gt;nsd&lt;/a&gt;, which was a bit of a learning curve, but in the long
run I think it&#039;ll be better than working with goofy DNS managers like you&#039;d find on registrar or hosting websites.&lt;br /&gt;
NameCheap is now letting you setup IPv6 glue records right on their website (previously you had to file a support
ticket), so that made things easier.&lt;/p&gt;
&lt;p&gt;The only big glitch I ran into is that on FreeBSD, using simply&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;listen [::]:80;&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;to listen to both IPv4 and IPv6 didn&#039;t work.  When trying that, I found that any request coming in as IPv4 would give
weird 403 or 404 (I don&#039;t remember which) errors, where it seemed nginx just didn&#039;t know what virtual host to go to.&lt;br /&gt;
Linux doesn&#039;t seem to have that problem. Ended up using separate listen statements, as in:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;listen 80 default_server;
listen [::]:80 default_server ipv6only=on;&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;for the main site, but VERY IMPORTANTLY, the remaining sites could not have the &lt;code&gt;ipv6only=on&lt;/code&gt; directive, they just
simply say &lt;/p&gt;
&lt;pre&gt;&lt;code&gt;listen  80;
listen [::]:80;&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;(found that trick in this &lt;a href=&quot;http://serverfault.com/questions/277653/nginx-name-based-virtual-hosts-on-ipv6&quot;&gt;ServerFault page&lt;/a&gt;).  This also has the advantage of showing proper IPv4 IP addresses in
the logs, instead of IPv4-mapped IPv6 addresses such as &lt;code&gt;::ffff:11.22.33.44&lt;/code&gt;, so I ended up doing the same thing on a
Linux box even though it handled dual-stack by default just fine.&lt;/p&gt;
&lt;p&gt;I also for testing purposes, made aliases&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&quot;http://ipv4.barryp.org/blog/&quot;&gt;http://ipv4.barryp.org/blog/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;http://ipv6.barryp.org/blog/&quot;&gt;http://ipv6.barryp.org/blog/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;To force one protocol or the other.  When you use &lt;a href=&quot;http://barryp.org/blog/&quot;&gt;http://barryp.org/blog/&lt;/a&gt;, it&#039;s not obvious which you&#039;re
using.&lt;/p&gt;</content>
</entry>
</feed>