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.