If you’ve been playing long enough with IPv6, you have probably heard about various transition mechanisms, one of them being 6to4.
I will try to explain what is it all about and what it can and what it can’t do for you as a service provider.
I’ve recently set up a such a relay to serve our customers. The setup is pretty simple, and if you have proper network design, it is simply a matter of 5 minutes.
The only prerequisite is that your 6to4 relay has access to both IPv4 and IPv6 internet.
It is suffice to say though that if you would like to setup a private 6to4 relay to serve your 6to4 able customers without their intervention, you would need a 6to4 relay config with anycast support as bellow (Cisco):
ipv6 unicast-routing interface Loopback2002 description 6to4 Private Relay ip address 184.108.40.206 255.255.255.0 secondary ip address 220.127.116.11 255.255.255.255 ipv6 address 2002:ac01:0203::1/128 interface Tunnel2002 description 6to4 Private Relay no ip address no ip redirects ipv6 address 2002:C058:6301::/128 anycast ipv6 unnumbered Loopback2002 tunnel source Loopback2002 tunnel mode ipv6ip 6to4 tunnel path-mtu-discovery ipv6 route 2002::/16 Tunnel2002
Where 18.104.22.168 255.255.255.255 is your public IP and 2002:ac01:0203::1/128 is your 6to4 IP derived by formula 2002:IPv4inHEX::1/128, and 22.214.171.124 255.255.255.0 is the reserved anycast prefix, 2002:C058:6301::/128 being the IPv6 6to4 equivalent. You need to use the anycast prefixes in order to automatically drive the tunnels of your 6to4 customers towards your relay without their intervention.
You do not need to advertise this prefixes to the outside world using BGP if you want to serve your customers only.
If you are targeting a private relay for routers, rather than end OSes, then you can use any prefix you wish.
So what a 6to4 relay can do for you? Less than some would like it to. The main benefit is observed for the IPv4 only clients that would set automatic 6to4 tunnels to your relay reducing considerably the delay of their tunneled IPv6 connection. Also, if you have any public IPv6 only services, it will be possible for your clients to access them without exiting your network and going through external relays.
What a 6to4 relay will not do? Well, first of all, it will not substitute the native IPv6 deployment. It is more of a end customer feature to get basic IPv6 connectivity today. The major drawback of the 6to4 is the need of a public IPv4 address.
To make things even worse, the traffic withing 6to4 is asymmetric as a result of using anycast (corrected with 6rd). The picture bellow shows how things work for both inbound and outbound.
Hence the destination of the client from the perspective of the content server is within the 2002::/16 prefix, the content server will choose the closest advertising router to it’s location. The advertising router will encapsulate the IPv6 packet in IPv4 and will sent it to the clients IPv4 address where it will be back decapsulated to IPv6.
As a result, on your private 6to4 relay, all the traffic passing through the tunnel will be only the uplink traffic of your clients unless they use some of your internal IPv6 services. This leads to the fact that obvious client support is rather impossible as you never know where the traffic is coming from.
To conclude, the setup of a 6to4 relay can be done in a matter of minutes assuming you already have native IPv6 connection. But really, if you are a service provider you will soon realize that the 6to4 relay is more of a desperate way to offer some badly needed IPv6 connectivity. The native IPv6 is the only way to achieve real service.