4in6 Tunnel

A 4in6 tunnel is pretty much the same idea as a 6in4 tunnel, except it is "upside down". In this case, the underlying transport is IPv6, not IPv4, and the tunneled packets are IPv4, not IPv6. Currently there is not a great need for 4in6 tunneling, as we live in a mostly IPv4 "ocean" for now. Over time, as the IPv6 "islands" grow, overlap and start to merge, and the IPv4 "ocean" continues to shrink, it will flip over to an IPv6 "ocean" with shrinking islands of IPv4. At that time, most of us will have native IPv6 service from our ISPs. It is expensive and difficult to provide both IPv4 and IPv6 in native form, so ISPs will elect to provide IPv4 only tunneled. There might even be free sources of tunneled IPv4, as there are free sources of tunneled IPv6 today, for those who still need access to what remains of the IPv4 Internet.

There is no accurate way to predict when this "flip over" to an IPv6 ocean will happen. Probably not until 2020 or so, to pull a number out of the air. At the current time, 4in6 is more of a research topic than a practical transition mechanism.

A 6in4 tunnel adds 20 bytes of overhead (the size of the prepended IPv4 Packet Header) to each packet, which is bad enough. A 4in6 tunnel adds at least 40 bytes of overhead (the size of prepended basic IPv6 Packet Header), and potentially more (from extension headers), to each packet.

4in6 tunnels are specified in the same RFC as 6in4 tunnels (and described in the article on tunnels). See RFC 2437, "Generic Packet Tunneling in IPv6", December 1998.

Like 6in4 tunnels, 4in6 tunnels must be manually created. There is currently no variant of 4in6 tunneling that does automatic tunnel creation, although there is no real problem with creating such a thing. There just isn't currently much need for it. A variant will probably be specified when the need is there.

Unlike 6in4 tunnels, there is no need to have variants that can work behind a NAT gateway (like Teredo), because NAT does not exist in IPv6 and there is no justification whatever to introduce it.

The primary place that 4in6 tunnels have been used is in Dual Stack Lite (DS-Lite) specification. This involves providing native IPv6 to the customer, with IPv4 provided via a 4in6 tunnel over the native IPv6. In this case, the IPv4 addresses are generated by Carrier Grade NAT (CGN), but tagged with the customer's IPv6 address to eliminate many of the really serious issues with CGN done in an IPv4-only context.

As vendors produce Customer Premises Equipment (CPE) boxes that support native IPv6, or ISP side infrastructure to supply native IPv6 to those boxes, they should be sure to include support for DS-Lite, as that will solve ISP's IPv4 address space problem for good, even with essentially no new public IPv4 addresses available from RIRs (which is the case now in over half of the world). DS-Lite will also save ISPs the additional cost of providing native IPv4 alongside the native IPv6. DS-Lite will almost certainly require a replacement of the existing CPE boxes, rather than a simple firmware upgrade, or addition of a new internal box. The cost of this replacement is one of the things holding back deployment, but in my opinion, users will be willing to pay for the new CPE box in order to get far better ISP service, and native access to IPv6.

Currently there are only two sources of free 4in6 tunneled service (6fei in China and gogo6/Freennet6 in the US). In comparison, there are many sources of free 6in4 tunneled service (as well as other variants of this).

 

The Future of Telephony: LTE Advanced

Currently we are in the third generation of telephony (3G). Even the "4G" services being advertised and deployed are not "real" 4G yet. LTE (Long Term Evolution) is really "3.9G". It is still based on the traditional telco protocols and architecture, it just supports faster Internet over telco link (HSDPA+, etc.) Also, it is still pretty much IPv4-only.

Real 4G telephony (LTE Advanced) is just beginning to appear in a few places. It is a major break from all prior telco protocols and architectures. It is the first telco scheme to move completely to IP. Data will use conventional Internet protocols and infrastructure, voice will be VoIP. Phone numbers will be SIP URIs (e.g. sip:This email address is being protected from spambots. You need JavaScript enabled to view it.). The ENUM system will provide translation from ITU numeric string phone numbers (e.g. +63-123-456-7890) to SIP URIs. We will no longer have the "hub and spoke" architecture of traditional telephony - everything will be End-to-End (flat address space). In fact, landlines and wireless will merge into a single system, rather than being separate. Your landline phone will plug into your Internet service, not a traditional phone line. Any 4G phone will be able to directly call any other 4G phone in the world. Guess what IP family can't handle this because of its depleted address space and NAT! 4G telephony requires, and has been designed to work with, IPv6. The long delayed implementation of IPv6 is the primary reason we don't have real 4G telephony yet. IPv6 is a hard prerequisite for LTE Advanced.

Note that because the ITU buckled to pressure from telco vendors and let them call their 3.9G products "4G", the ITU has now introduced a new term, IMT Advanced (International Mobile Telecommunications-Advanced) for "real" 4G.

The reason that real 4G telephony is relevant here is that it will be an IPv6-only platform. But when it first comes out, many sites that people will want to use are still IPv4-only. Therefore there will have to be a transition technology that allows that. The two choices are 4in6 tunneling and v6v4 translation (e.g. NAT64/DNS64). Actually DS-Lite may well find its first home in 4G telephones. Many telcos are planning to use NAT64/DNS64, but this technology has many serious issues, and will be suitable only for the simplest kinds of connections. There may not be solutions for the issues with NAT64/DNS64.

An alternative to NAT64/DNS64 layer 3 translation is layer 7 proxy translation, which has none of the issues of NAT64/DNS64. The problem is that every protocol (web, email, SIP, etc) requires its own proxy. For an example of a working Layer 7 translating proxy (currently only for web), see the SolidProxy product.