I have been invited by the Internet Society Hong Kong (ISOC-HK) as a guest speaker for the "Kickstart IPv6! Seminar on World IPv6 Day (8 Jun)” which will be held in Cyberport on World IPv6 Day. I will share about my experience of deploying IPv6 in our department, from interim tunneling arrangement to native IPv6 connection. Hey, I don’t mind telling the audiences that I made a big mistake in selecting solution for our interim IPv6 web server. In Jan 2010, I had to decided to use 6in4 or 6to4 tunnel for the web server. 6in4 is offered free by a tunnel broker service provider. It requires login account name and password to set up the tunnel and on Windows server, there must be a start up script to fire up the v6 interface whenever bootup. 6to4 is easier and everything is automatic. If anyone has to choose between 6in4 and 6to4, 6to4 is definitely attractive. One thing that I hate is that Mircrosoft uses a risky 6to4 address format which maps the IPv4 address 202.81.93.74 to 2002:ca51:5d4a::ca51:5d4a (202 dec= ca hex). The 3rd – 6th octets matching 13th – 16th octets tells people that we are using Microsoft OS and hackers can then initiate attacks targeted at Windows OS and IIS. We had to change the 13th – 16th octets to other arbitrary hexadecimal number like 2002:ca51:5d4a::aaaa:ffff.
Everything seemed ok and it was a pretty smart choice at a first glance. Eventually, I discovered that I was wrong to use 6to4 address. It is because web server with 6to4 address can not attract traffic from dual-stack hosts with native IPv6 connection. Over 95 % of visiting addresses were 6to4 addresses and obviously they were Windows 7 hosts running PPPoE or Metro-Ethernet without NAT and their 6to4 tunnels were automatically set up. In that scenario, 6to4 hosts will visit 6to4 servers as they are on the same 6to4 network. However, dual-stack hosts will only use native IPv4 if a web server has native IPv4 address and 6to4 address. 6to4 path will be abandoned while native IPv4 path is selected because 6to4 is less reliable than native 6to4. I applaud that Microsoft do the right thing.
The addresses of 6in4 come from a native IPv6 service providers. All OSes can not tell if these addresses are native IPv6 or 6in4. Hence, if we had use 6in4 in the first place, our interim web server should have attracted a high traffic. Though we discovered that weakness, we did not want to switch back to 6in4 as we will use native IPv6 connection very soon.
This is a painful experience. I hope other network administrators will take my advice to use 6in4 tunnel as opposed to 6to4 tunnel when considering interim IPv6 solution.
2 comments:
Thanks Warren...interesting and helpful
6to4 has no service guarantee. In the past I have tried 6to4. Sometimes I had nearly 100% packet loss, othertimes it worked almost as well as 6in4. The thing is I never had 6to4 work better than 6in4. For that reason alone I suggest 6in4 any day of the week over 6to4. The real question comes in when selecting between 6rd and 6in4. Generally you do have a service level guarantee for 6rd. Since 6rd is implemented by your local ISP, you may get better performance than 6in4. The primary advantage of 6in4 is you can bring your IPv6 prefix with you. It won't change just because you change service providers... If you need that, then 6in4 is the clear winner, otherwise 6rd is probably the winner.
Post a Comment