La version actuelle, la 4, du protocole IP avait eu bien de la chance, d'être déployée dans un environnement quasi-vierge. IP version 6 doit au contraire se frayer un passage dans un monde où tout est en IPv4. D'où l'importance des mécanismes de transition, dont ce RFC décrit deux exemples.

Cette transition est un des principaux défis auquel doit faire face IPv6. Il est même possible que sa difficulté soit la cause principale de ses problèmes, plus que ses qualités ou défauts intrinsèques.

Mettant à jour le , notre RFC décrit deux mécanismes (il en existe de nombreux autres, plus exotiques) pour assurer la transition : la "double pile" qui consiste pour une machine à avoir les deux protocoles (et donc les deux compétences pour son administrateur) et le tunnel configuré pour faire passer de l'IPv6 dans un Internet très majoritairement IPv4.

Dans le premier cas, la machine a les deux protocoles et, parfaitement bilingue, peut parler avec n'importe quelle autre machine, que cette dernière soit v4 ou bien v6. Mais cela empêche d'abandonner IPv4 et sa pénurie d'adresses. Et cela ne résout pas tous les problèmes comme par exemple "Quelle adresse choisir si la machine avec laquelle je veux parler est également double pile ?" (très partiellement discuté dans la section DNS du RFC).

Le tunnel traite un problème un peu différent : une des extrémités du tunnel met les paquets IPv6 dans un paquet IPv4, les envoie à l'autre extrémité du tunnel, où on décapsule le paquet IPv6. La technique étant relativement complexe dans ses détails, elle forme l'essentiel de notre RFC.

Pour plusieurs raisons, comme le problème de MTU que notre RFC discute en profondeur, les performances sont alors moins bonnes.

Dans le cas du tunnel, deux machines qui n'ont qu'IPv6 peuvent se parler au travers de l'Internet actuel (peu d'opérateurs routent la v6). Mais cela ne résout pas le problème de parler aux machines purement v4 (comme l'est, aujourd'hui, www.bortzmeyer.org).