|
|
| Line 1: |
Line 1: |
| − | =<div id="DeployerIPv6">Activer IPV6 dans son infrastructure </div>=
| |
| − | <!-- ----------------------------------------- -->
| |
| | | | |
| − | Successfully Deploying IPv6
| |
| − | https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf
| |
| − |
| |
| − | == Obtenir un préfixe IPv6 ==
| |
| − |
| |
| − |
| |
| − | ==<div id="double pile">Installation en double pile</div>==
| |
| − |
| |
| − |
| |
| − | Le mécanisme de double pile IP présenté par le RFC 4213 consiste à doter chaque équipement du réseau d'une double pile protocolaire (''Dual Stack'') et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau.
| |
| − | Les noeuds sont capables de communiquer dans les deux versions du protocole IP. Ceci demande clairement un double travail, tout doit être fait en double. Tous les segments d'un réseau sont en double pile. En contrepartie, ce mécanisme ne prend pas en compte les problèmes de pénurie d'adresses IPv4. En effet, la double pile ne règle pas le problème de l'épuisement du plan d'adressage d'IPv4. Car chaque machine IPv6 a besoin d'une adresse IPv4.
| |
| − |
| |
| − |
| |
| − | Tous les équipementiers de coeur de réseaux supportent ce mécanisme, qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Le déploiement de ce mécanisme peut être progressif et ne concerner qu'une partie du coeur de réseau dans un premier temps. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé. Dans ce cas en effet, l'activation de fonctions permettant de gérer plusieurs topologies peut s'avérer nécessaire (cf. [[ISIS]]).
| |
| − |
| |
| − | Pour les équipements terminaux, ce mécanisme de transition a été défini et a été très largement employé dès le début de la standardisation d'IPv6. De la même manière, il consiste à doter chaque équipement d'une double pile protocolaire et d'affecter une adresse IPv4 et/ou IPv6 à chaque inteface réseau. Cela ne résoud pas le problème de la pénurie d'adresses IPv4, mais permet dans un premier temps d'acheminer indifférement du trafic IPv4 ou IPv6 sur un équipement donné (station, routeur).
| |
| − |
| |
| − |
| |
| − | La figure Compatibilité grâce à la double pile illustre ce principe. La station B peut parler en IPv4 avec la station A et en IPv6 avec la station C. Le listing suivant donne un exemple de configuration d'une double pile dans un environnement Unix.
| |
| − |
| |
| − | [[image:CS175.gif]]
| |
| − |
| |
| − | xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
| |
| − | inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255
| |
| − | inet6 3ffe:305:1002:1:2b0:d0ff:fe5c:4aee/64
| |
| − | inet6 fe80::2b0:d0ff:fe5c:4aee/64
| |
| − | ether 00:b0:d0:5c:4a:ee
| |
| − | media: 10baseT/UTP <half-duplex>
| |
| − | supported media: autoselect 100baseTX
| |
| − |
| |
| − |
| |
| − | <!-- Socket avec adress IPv4 mapped -->
| |
| − |
| |
| − | QUelque soit la version de protocole utilisée au niveau de l'application cela ne doit rien changé. Il faut cependant que l'application puisse exprimer l'adresse de son correspondant que ce soit en IPv4 ou en IPv6. Pour cela, les adresses doivent être codées sur 128 bits. Un type d'adresse IPv6 a été défini à cet usage à savoir comporter l'adresse IPv4 d'une communication IPv4. L'adresse IPv4 est imbriquée dans une adresse IPv6. Au niveau de l'interface pour la communication, l'application peut recevoir une connexion aussi bien en IPv4 ou en IPv6. Le format des adresses IPv4 mapped est ::FFFF:<ipv4 address> comme par exemple ::FFFF:1.2.3.4
| |
| − |
| |
| − |
| |
| − | Reste le problème des applications. Une application écrite avec l'API socket IPv6 ([[L'interface de programmation "socket" IPv6]]), utilisant en particulier des <tt>struct sockaddr_storage</tt> et la fonction <tt>getaddrinfo</tt>, peut dialoguer indifférement en IPv4 et en IPv6. Simplement, pour un serveur, deux sockets sont nécessaires, l'une pour IPv4 et l'autre pour IPv6. La station B devrait, dans l'exemple de la figure ci-dessus, posséder des serveurs pour chacune des versions de IP, ou au moins des serveurs écoutant sur plusieurs ports en parallèle. Cela peut être évité en utilisant des [[Autres types d'adresses#mappee|adresses mappées]], qui permettent à une application de voir l'espace d'adresses IPv4 comme une partie de l'espace d'adressage IPv6.
| |
| − |
| |
| − | Comme le montre la figure Adresse IPv4 mappée, l'adresse IPv4 est contenue dans l'adresse IPv6.
| |
| − |
| |
| − | [[image:CS176.gif]]
| |
| − |
| |
| − | Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application s'est enregistrée via une socket IPv6 (famille de protocoles <tt>PF_INET6</tt>), les adresses IPv4 mappée source et destination sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement quand une application IPv6 émet des paquets avec une adresse IPv4 mappée, ceux-ci sont aiguillés vers la pile IPv4.
| |
| − |
| |
| − | L'exemple suivant illustre ce fonctionnement. Le client telnet, compilé en IPv6 peut contacter les équipements IPv4 en utilisant l'adresse mappée.
| |
| − |
| |
| − | >'''telnet rhadamanthe'''
| |
| − | Trying 3ffe:305:1002:1:2b0:d0ff:fe5c:4aee...
| |
| − | Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr.
| |
| − | Escape character is '^]'.
| |
| − |
| |
| − | FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3)
| |
| − |
| |
| − | login:^D
| |
| − | >'''telnet bloodmoney'''
| |
| − | Trying ::ffff:193.52.74.211...
| |
| − | Connected to bloodmoney.rennes.enst-bretagne.fr.
| |
| − | Escape character is '^]'.
| |
| − |
| |
| − |
| |
| − | SunOS UNIX (bloodmoney)
| |
| − |
| |
| − | login:
| |
| − |
| |
| − | Le mécanisme de double pile permet de résoudre tous les problèmes d'interopérabilité liés à l'introduction de la pile IPv6. Quand cela est possible, la communication se fait en utilisant la nouvelle version du protocole. Dès qu'un des éléments n'est pas compatible (réseau, système d'exploitation, application), le protocole IPv4 est utilisé. Le principal intérêt vient du fait qu'il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes. Pourtant ce mécanisme n'est pas suffisant :
| |
| − |
| |
| − | * Il ne résout pas le problème de la pénurie d'adresses puisque chaque machine doit disposer d'une adresse IPv4 et d'une adresse IPv6. Cela complique aussi les mécanismes de configuration automatique.
| |
| − | * Il implique que tous les routeurs soient aussi configurés pour router les deux types de paquets.
| |
| − | * Les applications doivent être compilées pour IPv6, ce qui implique la disponibilité du code source et un "effort" de reprogrammation.
| |
| − |
| |
| − | Les applications recompilées avec l'API IPv6 ne fonctionnent que sur des équipements pourvus d'un système récent (et d'une pile IPv6 si on utilise les adresses IPv4 mappées), ce qui peut poser des problèmes de compatibilité entre les différentes versions d'un système.
| |
| − |
| |
| − | ===Implications au niveau du DNS===
| |
| − |
| |
| − | A résumer
| |
| − | The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map
| |
| − | between hostnames and IP addresses. A new resource record type named
| |
| − | "AAAA" has been defined for IPv6 addresses [RFC3596]. Since
| |
| − | IPv6/IPv4 nodes must be able to interoperate directly with both IPv4
| |
| − | and IPv6 nodes, they must provide resolver libraries capable of
| |
| − | dealing with IPv4 "A" records as well as IPv6 "AAAA" records. Note
| |
| − | that the lookup of A versus AAAA records is independent of whether
| |
| − | the DNS packets are carried in IPv4 or IPv6 packets and that there is
| |
| − | no assumption that the DNS servers know the IPv4/IPv6 capabilities of
| |
| − | the requesting node.
| |
| − |
| |
| − | The issues and operational guidelines for using IPv6 with DNS are
| |
| − | described at more length in other documents, e.g., [DNSOPV6].
| |
| − |
| |
| − | DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
| |
| − | both AAAA and A records. However, when a query locates an AAAA
| |
| − | record holding an IPv6 address, and an A record holding an IPv4
| |
| − | address, the resolver library MAY order the results returned to the
| |
| − | application in order to influence the version of IP packets used to
| |
| − | communicate with that specific node -- IPv6 first, or IPv4 first.
| |
| − |
| |
| − | The applications SHOULD be able to specify whether they want IPv4,
| |
| − | IPv6, or both records [RFC3493]. That defines which address families
| |
| − | the resolver looks up. If there is not an application choice, or if
| |
| − | the application has requested both, the resolver library MUST NOT
| |
| − | filter out any records.
| |
| − |
| |
| − | Since most applications try the addresses in the order they are
| |
| − | returned by the resolver, this can affect the IP version "preference"
| |
| − | of applications.
| |
| − |
| |
| − | The actual ordering mechanisms are out of scope of this memo.
| |
| − | Address selection is described at more length in [RFC3484].
| |
| − |
| |
| − |
| |
| − | ===Précaution: Eviter led pbs pour les "eye balls" ===
| |
| − |
| |
| − | [[http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4) ]]
| |
| − |
| |
| − | RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts http://www.bortzmeyer.org/6555.html
| |
| − |
| |
| − |
| |
| − | <!-- ----------------------------------------- -->
| |
