ly configured tunnels [2], maybe the most significant tools for automatically tunneling of IPv6 over IPv4 were, and to some extent still are, Connection of IPv6 domains via IPv4 clouds (6to4) [3], IPv6 over IPv4 without explicit tunnels (6over4) [4], IPv6 Rapid Deployment on IPv4 infrastructures (6RD) [5], Intra- Site Automatic Tunnel Addressing Protocol (ISATAP) [6], and Tunneling IPv6 over UDP through NATs (Teredo) [7]. We want to emphasize that there really are large numbers of other mechanisms, but these are the most famous. Advances in Tool Development As time passed and IPv4 addresses grew short, but no IPv6-only killer application had emerged, it started to be clear that there is not that much need for connecting hosts to IPv6 clouds via tunnels. Furthermore, it was widely understood that tunneling IPv6 over IPv4 does nothing to alleviate the IPv4 address shortage. This situation made people interested in actually replacing IPv4 with IPv6 in the access networks. Since the world is still mostly IPv4, it also meant that a need arose for connecting to the IPv4 Internet over IPv6 networks. A harbinger of the coming IPv4-over-IPv6 transition tools work was perhaps the Dual Stack Transition Mechanism (DSTM) proposal by Laurent Toutain, Hossam Afifi, and Jim Bound in 1999 (documented in an expired Internet-Draft "draft-toutain-ngtrans-dstm- 00.txt'). These gentlemen saw the need for IPv4 connectivity over IPv6-only access networks, and they proposed a tool where a host could ask for a temporary allocation of an IPv4 address, and then tunnel the IPv4 packets over IPv6. Almost a decade after the introduction of DSTM, the work really started flying, and after lots of discussions the Internet Engineering Task Force (IETF) ended up specifying Dual-Stack Lite [8] and the IETF has also additional tools in the pipeline. Maybe No Tunneling for Hosts After All At the start of the IPv6 transition, as of the writing of this book, it began to seem that perhaps it is not necessarily a good idea to deploy host-based transition 